Fix sockproc possibly inheriting nginx's sockets/file descriptors #75
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.
When we launch the sockproc process from inside nginx, we explicitly try to clear all extra file descriptors, so nginx doesn't inherit the nginx processes sockets. If sockproc does inherit these sockets, then if nginx gets stopped or restarted, sockproc takes over listening on those sockets, which means nginx can't be started again.
However, the existing implementation of clearing these file descriptors could fail under certain circumstances, leading to nginx being unable to restart. It depends on how nginx is started, but this could reliably fail under this scenario:
This was failing due to the
find
command being combined with-exec basename
to find the file descriptors to clear.basename
would fail if the current user didn't have permissions to be in the current directory (even if it was only finding the basename of paths in /proc which it did have permissions to). This led to no file descriptors being cleared. Thefind
command would also generate a warning message after finishing about not being able to restore the initial directory.To fix this:
/
, so any commands that require permissions to be in the current directory should work.basename
command.A test has been added to the test suite to test this behavior. Since the Makefile was getting a little unwieldy (particularly with another test that needed all the "worker perms" environment variables), shift the commands used to run the tests into a wrapper shell script to make things a bit easier to manage.