[systemd-devel] question about system reboot and shutdown

[Tilman Baumann]

DL;DR
UPS shutdowns are tricky. Clean file-systems are not the only concern.
But if you can make assumptions about your storage backend you might be
able to cut corners safely.

In my experience, the only place where you can hook in a non racy way is
in the kernel.

https://unix.stackexchange.com/questions/122557/how-does-the-system-shutdown-of-a-linux-kernel-work-internally

Because this is the hook which a lot of RAID systems and storage
back-ends use to signal a clean poweroff.
If you just halt your system very late in shutdown in userspace and
switch the lights off, the kernel will never run this code.
The result is that for example RAID unclean flags are still set.

UPS kernel drivers generally solve this problem by setting a 'powerfail'
flag before they initiate a shutdown.
The driver is hooked in the shutdown notifier and initiates the poweroff
through the UPS.

Another race condition is, that during the shutdown, the power could
have come back. THE UPS needs to recognize that and still power off the
system to ensure a reboot and then switch it back on.

But I think in your case, using a time based approach is quite valid.
Late in shutdown, set the powerfail flag in the UPS and set a poweroff
timer. While that timer is ticking in the UPS, your system will continue
shutting down safely and halt. And when the timer ran out the UPS will
switch the lights off.
That is by nature racy. But in a well defined system I suppose the risk
is manageable.


Mind you, my exposure tho this stuff is 10 years old or so. A lot might
have happened since then.
Back then I was fighting with a APC UPS which did not support timer
based poweroff and in combination with a 3ware RAID controller lead to
degraded volumes after powerfail.
The shutdown was done in userspace and the UPS did not know timer based
shutdowns. Hence the kernel hook never ran.

BTW. if you don't want to reinvent the wheel. networkupstools (NUT) was
back then the only really sensible software stack that did in practice
most things right.
As I said. My experience is 10 years dated. And I don't know if NUT
works well with systemd. And of course a network based system is
overkill. But perhaps you can have a look at it for some 'best practices'


On 09.08.2017 11:02, Marek Floriańczyk wrote:
> Dnia środa, 9 sierpnia 2017 10:29:37 CEST Lennart Poettering pisze:
>> On Di, 08.08.17 16:03, Marek Floriańczyk (marek.florianczyk at gmail.com) wrote:
>>> Hi all,
>>>
>>> I have a small device MicroUPS which helps me to shutdown my system on
>>> embedded devices, it is controlled by script /etc/init.d/microups and in
>>> this script I need to know whether system is going down for reboot or for
>>> halt, because in case of halt I need to send small data over RS232 to
>>> MicroUPS device to cut the power off.
>>
>> Note that this is necessarily racy: you can't really know how long the
>> system will actually take to shut down, hence if you trigger your
>> hardware for shutdown at an early phase of the shutdown process you
>> now start racing the remaining shutdown phase against the hardware turning
>> off power...
>>
>> If you want to fix this properly, and remove this race entirely the
>> only fully correct way out I see is to use an initrd for booting, and
>> doing the RS232 thing from that. Note that if you use a properly
>> prepared initrd, systemd will actually transition back to it at
>> shutdown, and while doing so it will permit unmounting the root file
>> system properly at shutdown. And only if you start the RS232 thing
>> after the point where the root fs is unmounted you can fully remove
>> the race in the generic case, since only at that point everything is
>> fully synced to disk, all complex storage is disassembled and so on.
>>
>> Now, adding this to the initrd is not the easiest thing in the world,
>> and in particular in embedded devices avoiding an initrd might be a
>> good thing. As long as you have no complex storage (i.e. no DM, no
>> LVM, no LUKS, no RAID, no iscsi, yaddayadda) you can instead cut a
>> corner and just drop in a shutdown script to