12.02.2020, 22:54, "Colin Booth" <colin_at_heliocat.net>:
> I wasn't trying to be hostile, apologies if it came across that way. As
> far as I know SIGPWR is a Linux-specific signal so services that are
this is a SysV signal that is sent in case of power suply problems.
it has no special meaning per se and can be (ab)used for everything
the coder sees fit.
is the abuse of SIGTSP in BSD init "POSIX-compliant" or even necessary ?
certainly not.
> aiming for portability will either need to have special handling for
> that in the linux case or need to ignore it. Ergo, runit (and all other
> POSIX-compliant inits) currently have no special handling around SIGPWR
> as they don't understand what it is.
what is a "POSIX-compliant init" btw ?
> Is this the right behavior? I don't know.
yes. what should power suply problems mean to container ?
> Something like SIGPWR as an
> alerting mechanism when you're switched to UPS battery is pretty nice in
> a general case but using that as your container shutdown solution
> isolates you into a very SysV-specific world.
BS. Linux provides this signal so you can (ab)use it for anything
you wish.
> Overriding the default via
> lxc.signal.halt will allow you to modify what you send to something that
> is within the POSIX spec and allow you to trigger shutdowns the "right"
> way. It's a little lame but it is portable, and LXC using a non-portable
> signal is a little bit of a bummer.
why "fix" LXC when adding handler code for SIGPWR to runit is not
much of a deal:
#ifdef SIGPWR
/* handle it analogous to SIGTERM or else */
#endif
this is also very portable to systems that do not provide SIGPWR.
not in any way, the signal is portable between Linux and SysV unices.
it is a good idea to use it since it is rarely used for anything, another
solution could be usage of real time signals.
Received on Fri Feb 14 2020 - 10:08:28 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC