Now that systemd manages the shutdown procedure, I don't know if it's
possible to achieve the same behaviour (and thus make NUT work with
systemd).


As already mentioned, it is ouside of scope of OS actually. How you did
it before systemd?

It was actually a feature of NUT - and a default and recommended feature
at some moment.
See this, from their FAQ:
http://networkupstools.org/docs/FAQ.html#_i_8217_m_facing_a_power_race
And this - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835634
(there is a link to an old discussion about implementing this feature).
Now it doesn't work anymore, and I'm trying to find a new solution...

So you do not even bother to describe how it worked before so others may
suggest how it can be (re-)implemented using systemd? Oh, well ...

No, that's not what I meant! Instead of trying to describe it myself, I've posted a link to their website where they describe the procedure first-hand! Basically, there is a "shutdown script" (though I'm not exactly sure where is it), which is apparently executed right before halting, so you can put "sleep" and "reboot" there. I was wondering if there is a similar thing in systemd.


systemd supports switching back to initramfs instead of directly halting
system. This allows you to implement your logic there after everything
is completely shut down and unmounted (you probably need to unmount old
root manually though). You can even monitor UPS from initramfs and only
reboot when it reports power is back to make it safe.

This may be the best idea without touching the kernel. But it still
can't go through the "proper" halt procedure with syncing and unloading
the drives, correct?..

I have no idea what "unloading the drives" means.

That's why I've posted the second link: in that bug discussion, one person is explaining why this is a bad idea. In general, only the kernel can do "proper" halt, which among other things includes unloading the heads from the hard drive so that it is ready to be powered off (and apparently "hdparm -y" does not cut it somehow).


--
darkpenguin
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to