New reboot flag: -c for 'power cycle'

[Warner Losh]

I've worked up a prototype for a new type of reboot. Currently we can halt
the system, reboot (reset) the system, and power off the system. However,
there's no reliable[*] way, however, to power cycle a system from the
command line.

For a variety of reasons, we have the need to power cycle a system on
reboot. That is, to remove power and reapply it a short time later. This
obviously requires special hardware to accomplish, but the number of BMC
equipped servers is interesting. The reasons boil down to 'we did something
to some bit of hardware that requires us to power cycle to restore it to
operational state or for new settings to take effect.'

I've uploaded https://reviews.freebsd.org/D12777 with all the changes.
Briefly, it introduces a new howto flag RB_POWERCYCLE. This flag instructs
capable hardware to cause the system to power cycle at the end of
shutdown_full. A new signal has been added to init (SIGWINCH) which
initiates this. Since init has no controlling terminal, SIGWINCH is useless
to it anyway... It add -c to the shutdown,reboot,halt, etc family of
commands. It tweaks the processing of reboot in a couple of places to treat
RB_POWERCYCLE the same way as we treat RB_POWEROFF as appropriate. Finally,
it registers a shutdown_final handler in IPMI and will power off systems
when howto has the RB_POWERCYCLE bit set and the BMC supports the chassis
device. Failure to implement RB_POWERCYCLE is handled the same way that we
handle RB_POWEROFF: in the event of failure, we either reboot or halt the
machine as instructed.

Code comments should go to the review. Design comments should come here.

Warner

[*] To be fair, one can arrange it so that one halts the system after
arming the watchdog and configuring it to power cycle when it fires, but
that relies on systems finishing their halt sequence before the watchdog
fires, and experience suggests that even with that there's a small (~1%)
failure rate for this method that requires manual intervention.

[Jonathan de Boyne Pollard via freebsd-arch]

Since init has no controlling terminal, SIGWINCH is useless to it

anyway.

This is untrue for two reasons. First, for some years now the nosh
toolset's system manager has been recognizing SIGWINCH on FreeBSD/TrueOS
for Linux compatibility; as on Linux it is sent to process #1 in
response to a kernel virtual terminal attention key sequence. Second,
that argument is fallacious because it would also apply to
controlling-terminal-generated signals such as SIGINT and clearly does
not given that SIGINT is useful to process #1.

So what I am doing in the nosh toolset for the forthcoming version 1.36
is this:

* The compatibility shutdown command now sports a new -c/--powercycle
option.

* The compatibility reboot, halt, and poweroff commands now sport a new
-c/--powercycle option, for the benefits of cruel system administrators.

* There is a new compatibility fastpowercycle/powercycle command, with
all of the same options for cruel system administrators.

* system-manager now treats SIGWINCH differently on non-Linux operating
systems, treading it as a request to invoke a new powercycle service.

SIGRTMIN+6, unused in the systemd system, is the Linux equivalent.

* system-manager now treats SIGRTMIN+16 as the underlying actual
powercycle request, which it translates to either RB_POWERCYCLE if it is
present in the C library headers, or RB_AUTOBOOT if it is not.

* There is now a new system-control powercycle subcommand, which
defaults to sending SIGWINCH/SIGRTMIN+6 or SIGRTMIN+16.

* The system-control init subcommand now sports a new c/C argument, by
analogy to h/H.

This is of course thus reflected automatically in the compatibility
telinit command and the initctl-read server.

[Warner Losh]

On Sat, Oct 28, 2017 at 8:51 AM, Jonathan de Boyne Pollard via freebsd-arch

Post by Jonathan de Boyne Pollard via freebsd-arch

Since init has no controlling terminal, SIGWINCH is useless to it anyway.

This is untrue for two reasons. First, for some years now the nosh
toolset's system manager has been recognizing SIGWINCH on FreeBSD/TrueOS
for Linux compatibility; as on Linux it is sent to process #1 in response
to a kernel virtual terminal attention key sequence. Second, that argument
is fallacious because it would also apply to controlling-terminal-generated
signals such as SIGINT and clearly does not given that SIGINT is useful to
process #1.

It's useless for its intended purpose, which is why it can be appropriated.
I was completely unaware of SIGWINCH being used like this on Linux. It
didn't pop up in the quick research I did before implementing this.

But it would have been nice to know this sooner, but I'm OK with later
since it isn't much later..

Post by Jonathan de Boyne Pollard via freebsd-arch
So what I am doing in the nosh toolset for the forthcoming version 1.36 is

Might want to hold off on this a smidge... See below...

Post by Jonathan de Boyne Pollard via freebsd-arch
* The compatibility shutdown command now sports a new -c/--powercycle
option.
* The compatibility reboot, halt, and poweroff commands now sport a new
-c/--powercycle option, for the benefits of cruel system administrators.
* There is a new compatibility fastpowercycle/powercycle command, with all
of the same options for cruel system administrators.

Hmmm, I like this. I'll have to add it to FreeBSD. I should have thought of
it in the first place.

Post by Jonathan de Boyne Pollard via freebsd-arch
* system-manager now treats SIGWINCH differently on non-Linux operating
systems, treading it as a request to invoke a new powercycle service.
SIGRTMIN+6, unused in the systemd system, is the Linux equivalent.
* system-manager now treats SIGRTMIN+16 as the underlying actual
powercycle request, which it translates to either RB_POWERCYCLE if it is
present in the C library headers, or RB_AUTOBOOT if it is not.
* There is now a new system-control powercycle subcommand, which defaults
to sending SIGWINCH/SIGRTMIN+6 or SIGRTMIN+16.

It looks like all the SIGRT* signals are user defined, and can be used for
any purpose by the application. It could easily be SIGRTMIN+6 as it is
SIGWINCH and we could ditch SIGWINCH on FreeBSD in init as well (since it's
only been in -current for a few days). Would that suffice to address the
compatibility concerns? There's no reason to be gratuitously different here.

Post by Jonathan de Boyne Pollard via freebsd-arch
* The system-control init subcommand now sports a new c/C argument, by
analogy to h/H.
This is of course thus reflected automatically in the compatibility
telinit command and the initctl-read server.

Warner

[Jonathan de Boyne Pollard via freebsd-arch]

Post by Warner Losh
I was completely unaware of SIGWINCH being used like this on Linux. It
didn't pop up in the quick research I did before implementing this.
But it would have been nice to know this sooner, but I'm OK with later
since it isn't much later.

Some sources of information for you, and for anyone else interested:

* The "System event response" section of my system-manager(1).
(http://jdebp.eu./Softwares/nosh/guide/system-manager.html or
file:///usr/local/share/doc/nosh/system-manager.html if you have the
nosh Guide installed)

* The SIGNALS section of Miquel van Smoorenburg's init(8).
(http://svn.savannah.gnu.org/viewvc/sysvinit/sysvinit/trunk/man/init.8)

* The SIGNALS section of Gerrit Pape's runit(8).
(http://smarden.org/runit/runit.8.html)

* The SIGNALS section of systemd(8).
(https://www.freedesktop.org/software/systemd/man/systemd.html)

* The doco for signal handling in Joachim Nilsson's finit.
(https://github.com/troglobit/finit/blob/master/doc/signals.md)

* Felix von Leitner (2004-09). Speeding up the Linux boot process with
minit. https://www.fefe.de/minit/minit-linux-kongress2004.pdf. 11th
Linux Kongress. p. 14.

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

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

* https://www.mail-archive.com/***@list.skarnet.org/msg01344.html

[Jonathan de Boyne Pollard via freebsd-arch]

Post by Jonathan de Boyne Pollard via freebsd-arch
* There is a new compatibility fastpowercycle/powercycle command,
with all of the same options for cruel system administrators.
Hmmm, I like this. I'll have to add it to FreeBSD. I should have
thought of it in the first place.

(-:

If you want further ideas like this, I've proposed adding a -b flag and
boot_bare variable to the kernel and loader for a while, now. Old BSD
init can just treat it as identical to -s, but my softwares can
definitely make good use of it.

* http://jdebp.eu./Softwares/nosh/roadmap.html#Ideas

*
https://freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project

[Jonathan de Boyne Pollard via freebsd-arch]

Post by Jonathan de Boyne Pollard via freebsd-arch
* system-manager now treats SIGWINCH differently on non-Linux
operating systems, treading it as a request to invoke a new
powercycle service.
SIGRTMIN+6, unused in the systemd system, is the Linux equivalent.
* system-manager now treats SIGRTMIN+16 as the underlying actual
powercycle request, which it translates to either RB_POWERCYCLE if
it is present in the C library headers, or RB_AUTOBOOT if it is not.
* There is now a new system-control powercycle subcommand, which
defaults to sending SIGWINCH/SIGRTMIN+6 or SIGRTMIN+16.
It looks like all the SIGRT* signals are user defined, and can be used
for any purpose by the application. It could easily be SIGRTMIN+6 as
it is SIGWINCH and we could ditch SIGWINCH on FreeBSD in init as well
(since it's only been in -current for a few days). Would that suffice
to address the compatibility concerns? There's no reason to be
gratuitously different here.

True, but it's not my softwares that you and I have to worry about. I've
just double checked, and the very thing that my softwares themselves are
being compatible with here has already used SIGRTMIN+16 and SIGRTMIN+6,
so I am going to adjust to +17 and +7 .

I'll let the systemd people know. Let's see what transpires from that.