Re: runit SIGPWR support

[Jeff <sysinit@yandex.com>]

17.02.2020, 11:00, "innerspacepilot" <innerspacepilot@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.