Add --no-exit to keep running even after the subprocess exits #64
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A subprocess launched by httptap can "daemonize" itself (fork, detach itself with setsid, then fork again), in which case the subprocess launched by httptap will return, but other processes will still be running in the network namespace. At present, httptap exits when the immediate subprocess exits, leaving other such processes stranded in an isolated network namespace. Those processes will have no network connectivity, and the user won't see HTTP calls they make on the command line. This PR adds a simple workaround: a
--no-exit
flag that simple has httptap wait around until it is killed.A good minimal way to reproduce this phenomenon is:
A python example that illustrates a bit more what syscalls are at play is:
An existing workaround is to put a "sleep infinity" into the command run by httptap:
The above works but is a bit obscure. With this PR this becomes:
The user still has to press ctrl+c at the end.
#63