Issue #15017 has been updated by ioquatix (Samuel Williams). With a passing interest, since I've worked in the guts of this code, I believe the situation you are describing sounds like buggy behaviour on the part of Heroku. In any case, I don't think there should be an issue to expose more details if they are available in the signal handler, but it might be a tricky interface to be compatible across all systems and the implementation might be difficult, i.e. not all signals are always generated from signal handlers (thinking of signalfd etc). ---------------------------------------- Feature #15017: Provide extended information about Signal https://bugs.ruby-lang.org/issues/15017#change-102861 * 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/