On 24.02.2020 02:53, Laurent Bercot wrote:
s6 should also catch SIGWINCH (keyboard request) and let the user handle
it via a hook executable if the signal exists btw. dunno if it
already does so.
Both SIGPWR and SIGWINCH are caught in the latest s6 git head.
Release coming whenever real li
have you ever used s6 as process #1 on any other platform than Linux ?
i bet you have not even tried to do so on any of the BSDs.
The BSDs are a different kind of beast: they're much more tightly
integrated than your run-of-the-mill Linux distro, and you can't
easily switch out one of the compon
s6 should also catch SIGWINCH (keyboard request) and let the user handle
it via a hook executable if the signal exists btw. dunno if it already does so.
Both SIGPWR and SIGWINCH are caught in the latest s6 git head.
Release coming whenever real life stop throwing things at me and I
can act
18.02.2020, 10:39, "Laurent Bercot" :
> you're telling me that s6-svscan needs to understand SIGPWR in case the
> kernel wants to signal a power failure, you actually have a good point,
> and yes, I should implement SIGPWR support when this signal exists.
BTW:
have you ever used s6 as process #1
18.02.2020, 10:39, "Laurent Bercot" :
> An additional reason is that signaling init is not a casual operation;
> instead it's part of a very limited API between the kernel and user
> space, to be used in very controlled, exhaustively listed, situations.
right.
> Now, *as a separate conversation*,
> Most init systems allow the SIGPWR behavior to be configured.
> This includes Upstart, systemd, and my own "little init":
>
> https://gitlab.com/chinstrap/linit#configuration
>
> I provide a guide for using linit with runit here, but the process is
> experimental:
>
> https://gitlab.com/chinstrap
