17.02.2020, 11:00, "innerspacepilot" <innerspacepi...@gmx.com>: > Just as a thought: You have implemented signal diversion, but limited to > known signals. Why not just pass unknown signals as numbers or something > like (S6SIG55011), so they can be diverted by user? You wouldn't have to > catalogue them.
absolutely right, totally agreed. i also wondered why he refuses to add this. just catch and handle ALL possible signals, including the RT signals and leave it to the user how to react. > We need good, flexible and user-friendly init alternatives for linux. right. >> But even if your containers were using s6, which has a well-defined >> upstream (me) and which does not understand SIGPWR either, I would not >> apply your patch suggestion. Why? Because SIGPWR is not standardized, >> and s6 aims to be portable, it works ootb on other systems than Linux >> and making it use SIGPWR would endanger that. It's the exact kind of >> problems you haven't thought of but run into when you want to patch >> software, and makes patching always more complex than it seems from the >> outside. sorry Laurent, this is absolutely ridicolous. we are talking about using s6 as Linux process #1, so it should catch, handle and react to all possible signals the kernel may send to said process, there might be a good reason for it, same for any other possible platform, be it BSD or SysV unices. this is inherently unportable per se. there exists no POSIX standard describing the signals a kernel may send to notify process #1 about certain events.
