On Sunday, 1 August 2021 16:45:12 CEST, Roger Price wrote: > A short summary of my understanding: > > * Your NUT installation works correctly with a regular shutdown. > > * Hibernation is hibernate-to-disk: a regular shutdown plus the writing of > a memory image and a process image to swap, and something in grub to have > the memory image and the processes restored on start-up. > > * A manual systemctl hibernate preserves the NUT processes.
Yes, that is probably correct. I don't know exact technicalities behind hibernation but what I know is it saves my workspace to disk and after that the power can be cut off and yet it can successfully restore my workspace after the power has been brought back. It requires to have the "resume=UUID=<UUID>" kernel parameter specified, possibly in the grub config. I also have the resume_offset=</swapfile offset> parameter specified since I use a swap file instead of swap partition. > * In a NUT induced shutdown, is it the /etc/ups/upsmon.conf directive > SHUTDOWNCMD "systemctl hibernate" which causes the system shutdown, or is it > the /opt/upssched-cmd-custom clause > > shutdown-timer) > echo "Power failure hibernation: Calling upsmon -c fsd, $CHMSG" | wall > upsmon -c fsd > ;; As I understand it, upssched-cmd-custom clause calls "upsmon -c fsd", and based on that, upsmon then calls whatever is in the SHUTDOWNCMD directive, which is "systemctl hibernate" in my case. > If you shut down because of this clause, when does "systemctl hibernate" get > executed? > > * In the journalctl extract, a line reports « čec 31 00:15:06 > atronach-opensuse systemd-sleep[2596]: service: no such service > upsd.service ». Why is systemd looking for upsd.service and not > nut-server.service ? Is this just systemd wierdness or is it more serious? I checked the full journalctl log and found a related error there: "[<PID>]: /usr/lib/systemd/system-sleep/nut.sh failed with exit status 1." This doesn't show up in Your filtered nut-journal output since it doesn't have any process name specified, only the process ID. nut.sh came with the nut pkg. More on this bellow. > This is beginning to look like a systemd problem rather than a NUT problem. > Why can't hibernate restore a service such as nut-monitor.service? Perhaps > someone else in this list has deeper a systemd understanding, or maybe a > question in the openSUSE mailing list <[email protected]> might find > the right systemd expertise. By checking "man systemd-sleep", /usr/lib/systemd/system-sleep/nut.sh is supposed to be a script running during hibernation and during waking up. A hack for applications not supporting the "Inhibitor interface". It's contents is: #!/bin/bash # Always stop nut before sleep, but do not initiate powerdown for hybrid-sleep. if [ "$1" = pre ] && ( [ "$2" = hibernate ] || [ "$2" = hybrid-sleep ] ) ; then /sbin/service upsd.service stop fi if [ "$1" = pre ] && [ "$2" = hibernate ] ; then # FIXME: All hibernate quirks are called in parallel. To be on a safest side, we should initiate powerdown grace period when they terminate. sleep 5 if test -n "$POWERDOWNFLAG" -a -f "$POWERDOWNFLAG" ; then export UPSD_POWERDOWN_CONDITION=1 /etc/init.d/upsd try-powerdown fi fi if [ "$1" = post ] && ( [ "$2" = hibernate ] || [ "$2" = hybrid-sleep ] ) ; then /sbin/service upsd.service start fi I tried to post it on hastebin but the site doesn't work for the time being. You can see there is the "upsd.service" specified but such a service file is not installed with the nut pkg. Instead, the new services names are nut-[driver|server|monitor]. I guess the upsd.service used to call the upsd binary so I've rewritten upsd.service to nut-server.service which calls the upsd binary as well. After invoking "upsd -c fsd" (or pulling the plug out of the wall socket), the errors about missing upsd.service and nut.sh failing are not showing up anymore. However, after waking up from the hibernation, nut-monitor.service still reports to be inactive (dead). S I modified the nut.sh script again and bellow the line "/sbin/service nut-server.service start" I've added: "service nut-monitor start" ...and this solved my issue. I can now successfully hibernate with NUT repeatedly. But It's not ideal, as I see it, there are 2 bugs to be reported: 1 bug reported to openSUSE to fix their nut.sh script within their nut package 2. bug reported to the NUT upstream to implement the so called "inhibitor interface" mentioned in the systemd-sleep man page so this nut.sh workaround wouldn't have to exist at all. However I'm not sure it they accept such a solution because of its ties to systemd. There are some Linux distros like Gentoo with their OpenRC init system or maybe other distros still sticking to SysVInit... Anyway, thank You for your effort to help me and for pointing out that missing upsd.service error. Maybe I'll report the bugs later. Regards, David K. _______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
