New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HUP doesn't restore the arguments properly because of the use of $0 #34
Comments
I have an example of how to reproduce this: |
Note that this may or may not work with procfs because of the way Net::Server works. A quick test shows that there's no issue with Mac OS X. |
I keep failing to reproduce this bug on Mac, and also hear issues from linux users (I think). Can someone specify 100% reproducible simple step to replicate this bug? I do have a linux environment to test and fix if there's any. |
OK i could reproduce now - is it correct that it only happens on a) linux, b) when you use PSGI file other than app.psgi and c) when you use --preload-app. |
Sort of related, Net::Server does this:
which means if you run starman using just 'perl', relying on your $PATH configured correctly, then sending HUP could potentially run the process again from a wrong path. This is issue number one. |
I think restarting the server with http://unicorn.bogomips.org/SIGNALS.html handles HUP to restart config files, then restart all workers. It will pick up code changes unless the preload_app is used, which we could replicate in Starman as well. If you use |
0.29_01 is shipped to CPAN. Test it. |
I have tested version 0.29_90 and it works exactly as you have described above and in the documentation. A HUP signal now successfully restarts the workers. Thanks for sorting this out. |
Closing. |
With Plack 0.9971's $0 change, the HUP signal handling is broken, and the way Net::Server retrieves the original command line args.
See also: https://github.com/miyagawa/Plack/issues/243
The text was updated successfully, but these errors were encountered: