Re: runit SIGPWR support

From: Jeff <sysinit_at_yandex.com>
Date: Mon, 17 Feb 2020 16:13:39 +0100

17.02.2020, 11:00, "innerspacepilot" <innerspacepilot_at_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.
Received on Mon Feb 17 2020 - 15:13:39 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC