Re: runit SIGPWR support

[Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>]

Alex Suykov:

> Just for reference, I checked apcupsd sources.
>

That was not nearly enough research, and your conclusion is ill-founded.

The SIGPWR signal, from before Linux even existed, has always meant 
"something has happened with the power".  In AT&T Unix System 5 books it 
is conventionally described as "power fail/restart".  The "something" 
can include *that the power has been restored*.  And indeed, this has 
been its long-time use, on AT&T Unix and on Linux.   Miquel van 
Smoorenbug's original powerd daemon (which later became Tom Webster's 
genpowerd), for just one example, sent a SIGPWR to process 1 and 
beforehand wrote *what that meant* into /etc/powerstatus, which could be 
"LOW", "FAIL", or "OK".  A. B. Prasad's powerh, a trap handler for 
snmptrapd, did the same.  And there are several others over the years.

* https://linuxgazette.net/issue83/prasad.html

(Indeed, on several operating systems, including HP-UX and SunOS, SIGPWR 
sent to a process other than process #1 *only* meant "power has been 
restored", and did not have the power fail meaning at all.  Programs 
were expected to reinitialize after power comes back in their SIGPWR 
handlers.  A full-screen TUI program would re-draw its UI, for example, 
on the assumption that the local terminals had lost power as well and 
were currently showing blank screens.)

It is quite wrongheaded to think that this can be completely changed 
into a "shut down and power off" command, for that reason and others 
besides.  Other reasons include that existing systems *already define 
different signals to mean that*.  There is an existing mechanism 
already.  Several, in fact.  They need more than one signal, too.  
systemd (and the nosh toolset's system-manager which has compatible 
signalling here) uses two of the real-time signals to mean "shut down 
and power off", one to trigger the service changes, and the other to 
finalize the procedure.  There's no convincing case for either the 
systemd authors or me to change, given that SIGPWR has already meant 
something else for a long time and changing it would conflict with 
existing programs that we want to interoperate with.  There's a strongly 
convincing case to *avoid* changing SIGPWR, in fact.

The simple truth is that if you are using SIGPWR to mean only a "power 
failed" event, you aren't using it correctly.  van Smoorenburg init went 
and looked into /etc/powerstatus and acted accordingly, and still does 
so *to this day*, albeit that the file is now located under /var/run.  
(The systemd people and I both provide infrastructure only.  We define a 
target that is activated, but not what services that target invokes; and 
we leave it up to the third-party services to determine what the power 
change event actually is.)  Send a SIGPWR to process 1 without writing 
/run/powerstatus means that you'll get the last power change event set 
by the person that *did* use the signal properly.

Moreover, not only is there an existing mechanism in such programs, 
there are *several* existing mechanisms.  And they don't even all use 
signals.  The program being run could be anything, not just 
system-manager, or runit-init, or systemd, or finit, or even one of the 
several specialized programs designed solely to be process #1 of a 
container.  *Even just those* do not all use signals.

* https://unix.stackexchange.com/a/191875/5132

In the case of van Smoorenburg init and Joachim Nilsson's finit, there 
is a private API for commanding system state changes, idiosyncratic to 
just those softwares (and not compatible even across the twain), 
involving sending messages along a FIFO that process #1 is reading the 
other end of.  Ironically, Karl M. Hegbloom augmented genpowerd back in 
1998 to optionally use this API, which is more expansive than the 
comparatively small signal API that van Smoorenburg init has.  To 
properly use van Smoorenburg init or Nilsson finit in a container, you 
have to configure the container manager to *do something else instead of 
sending signals at all* to send it system management commands such as 
"shut down and halt/restart/poweroff/powercycle", as the API for 
commanding these is not signals.  The right place to handle all of these 
variances is in the container manager's configuration settings.

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=23007#25

If you want to have some sort of "shut down and 
halt/restart/poweroff/powercycle" API between a container manager and 
process #1 inside a container, slightly absurd that the idea is for 
something that isn't a fully-fledged virtual machine with a virtual 
power supply, it is the program that is run that dictates the protocol 
to you, *not* you that dictates to the program being run.  The correct 
course of action is to tailor the container manager to the particular 
program, not try to make all programs, decades after the fact, suddenly 
discard and incompatibly overwrite the long-established, event not 
command, meaning of SIGPWR.