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
coexist with other signal handlers #4991
coexist with other signal handlers #4991
Conversation
I've found that this code changes so little and is so hard to test that I typically manually test it. Should we be concerned at all with the old handler raising errors? |
Good thinking, I pushed up a commit to accommodate this. This is probably definitely the behavior wanted for signals like INT and TERM. For other signals, there are theoretically cases where errors should maybe cause the server to shut down instead of for sidekiq to go forward witih its business. But even in these cases, the person catching the signals will know what they are doing, and if they think sidekiq should shut down in the case of error they should code that themselves. For less experienced people, the base behavior that sidekiq will log the error and carry forward is I think what they will be happy with, and the best behavior for avoiding support load for you. n.b. most of the time if someone knows what they are doing they will use If an error is raised in config/initializers/sidekiq.rbSidekiq.configure_server do |config|
at_exit do
raise "error raised in at_exit"
end
end
|
thoughts on semver: If someone is using a library that has signal handling code and they aren't aware of it, and that code now becomes problematic, then this change will start to cause problems for them. So they might do a tiny or minor sidekiq version update and find their code having problems. I think it's very uncommon, probably approaching the never category, for libraries which aren't themselves servers to have signal handling code, so this can probably be ignored. Slightly more common, but also very uncommon, is people who have signal handling code in their own app, which they want run in the context of their app running on the web, and now that code will suddenly start running in sidekiq as well. I'm thinking this is also uncommon enough to be ignored, and hey, people should be reading the changelog before updating anyway. |
Signal handlers can’t use a Logger but I’m not sure if that includes |
I believe that's only because the rails logger (and maybe also stdlib Logger, not sure) use a mutex. some googling seems to confirm this (and brought me to your ticket from 8 years ago :-D https://bugs.ruby-lang.org/issues/7917 ) I just did some quick tests with a custom signal handler, |
thanks! |
Using a technique I learned from the fantastic Working With Unix Processes, this allows other signal handlers to coexist with sidekiq. Simple example:
config/initializers/sidekiq.rb
Before this PR, this will never run. With the PR, this will run before the sidekiq behavior runs.
I tried writing a test in test_cli.rb and spent longer than I'd care to admit before I realized the tests there don't send signals, they just invoke the method.
Are there any other tests in the suite which do run processes and send signals? If so I'll try to put something in there.
Let me know what you think!