From: shevegen@... Date: 2018-08-21T17:02:16+00:00 Subject: [ruby-core:88597] [Ruby trunk Feature#15017] Provide extended information about Signal Issue #15017 has been updated by shevegen (Robert A. Heiler). Some comments (personal opinion here): 1) I think the described use case is understandable, but if you can, I think it may help matz and the ruby core team decide on; for example, what is the specific API you had in mind? Could you give an example here? You mentioned it here "additional param beside signal number for block" but I think it may help if you could give a specific example in ruby code. 2) I assume you use Linux, like many folks here do; matz uses debian as far as I know. I myself use mostly slackware, but compile literally almost everything from source using ruby scripts. Many other people use Windows, OSX/Mac variant or even less common operating systems (Solaris, the various BSD flavours, HaikuOS and so forth). There are examples where features have been rejected because they may only run on some systems but not others. I do not know whether this is the case in your example; perhaps there are agnostic implementations possible that would work on every platform. That would be best. I mention this in particular because you gave the example of systemd. And I believe if functionality would be only limited to one OS, then it may be better to have it available as a gem. Note that even in this case, I am sure the ruby core team and others may be able to help here, e. g. what may be required to offer the desired functionality. I would suggest to you to provide a bit more context, if you feel like it; for example perhaps you may have an idea how to best implement it too, but probably describing your use case is the single best thing to do; matz and the core team often said that they prioritize on real problems that ruby users have and the corresponding use cases (although you may already have described it enough, I just mention it again because I think it is one of the best ways to get a change into ruby if you have a valid use case - there are various examples in the past where this has helped a lot). And consider adding it for discussion at the next developer meeting: https://bugs.ruby-lang.org/issues/14981 Matz is very busy, coming to europe soon too \o/ so the developer meetings are great to help "get the process going". But of course it is your issue, please feel free to do whatever you want to do. :) ---------------------------------------- Feature #15017: Provide extended information about Signal https://bugs.ruby-lang.org/issues/15017#change-73653 * Author: jreidinger (Josef Reidinger) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- 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/ Unsubscribe: