Issue #15017 has been updated by fxn (Xavier Noria). I have another use case. Resque sends SIGTERM to terminate jobs (which run by default in a child process). That raises `Resque::TermException` in the child, and you can configure Resque to wait a certain amount of seconds before it does that. That allows graceful exits. On the other hand, Heroku sends SIGTERM to all processes in a dyno being shut down. Therefore, when you run Resque in Heroku, the child process gets SIGTERM from Heroku and raises. The orderly termination logic provided by Resque gets lost. There is a gem that monkey patches Resque to install a signal handler that ignores the first SIGTERM. However, that is a partial solution only becasue Heroku documents that dynos may receive **multiple** SIGTERMs. And I confirm, it does happen. So, you cannot assume the second SIGTERM comes from the Resque worker, the parent process. What would be really robust would be to check if the signal came from the parent process, and ignore anything else. The comment from @Eric Wong says this could be tricky, so I am not suggesting to reconsider. I'll find an alternative way to address this, only wanted to add a use case to the discussion that does not depend on the operating system. ---------------------------------------- Feature #15017: Provide extended information about Signal https://bugs.ruby-lang.org/issues/15017#change-102845 * Author: jreidinger (Josef Reidinger) * Status: Open * Priority: Normal ---------------------------------------- Hi, I see that ruby already use sigaction for signal handling on linux. It would be really nice to extend it to provide also signal details in siginfo_t and then provide such details in ruby via Signal module (as additional param beside signal number for block). Use case is quite simple. Our ruby application is killed by sigint and we do not know who send this signal. We already catching signal and logging as much as possible, but without siginfo we are very limited. We do not know ff it is OOMKiller due to low memory, systemd or something else. This additional info in siginfo allows us to log a much more details when such signal appear and inspect process that send us this signal. This is useful especially on customer side where we do not have direct control and we get only logs from failed run. If you need more info or help with example usage, do not hesitate to ask. Thanks Josef -- https://bugs.ruby-lang.org/