On Sat, 31 Jul 2021, David Ka?erek via Nut-upsuser wrote:> On Saturday, 31 July 2021 10:43:23 CEST, Roger Price wrote: >> Hello David, Does "systemctl hibernate" work correctly without any NUT >> function enabled? > > Yes, I can run it multiple times subsequently and it always works. When > checking the status of nut-[driver|server|monitor] services they all keep > reporting "active (running)" after waking up from hibernation.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. * 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 ;; In /opt/upssched-cmd-custom it would be very useful to have calls to logger in each clause to show in the journal what is happening. 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?>> What does command ls -alF /lib/systemd/system-sleep/ report? > > david at atronach-opensuse:~> LANG=c ls -alF /lib/systemd/system-sleep/ > ls: cannot access '/lib/systemd/system-sleep/': No such file or directory > david at atronach-opensuse:~> LANG=c sudo ls -alF /lib/systemd/system-sleep/ > ls: cannot access '/lib/systemd/system-sleep/': No such file or directory > >> Do you have something like nut-delayed-ups-shutdown.service which calls for >> the UPS to shutdown its outlets after N seconds? For hibernation to work, >> you should disable this service. I'm assuming you want the UPS to go on >> feeding the machine throughout the hibernation. (And to go on beeping.) > > No, I don't have the service created. But I don't mind the UPS killing of > power - hibernation (=suspend to disk) doesn't require power after all unlike > suspend to RAM.I assume that you rely on /lib/systemd/system-shutdown/nutshutdown which executes /sbin/upsmon -K >/dev/null 2>&1 && /sbin/upsdrvctl shutdown It seems to me that systemd's nutshutdown should have a call to logger to record an important system decision, but it may be too late in the shutdown process for logger to be effective. That's why I always comment out systemd's nutshutdown and use nut-delated-ups-shutdown.service which is executed early enough for the logger to work.> nut-report output: > https://hastebin.com/hoqabilobu > > nut-journal output: > https://hastebin.com/oluwisonuyThanks. 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 <users at lists.opensuse.org> might find the right systemd expertise. Roger
On Sun, 1 Aug 2021, Roger Price wrote:> * 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 > ;; > > If you shut down because of this clause, when does "systemctl hibernate" get > executed?To answer my own question I went to 2.7.4 /clients/upsmon.c where I see line 1875: case 'c': if (!strncmp(optarg, "fsd", strlen(optarg))) cmd = SIGCMD_FSD; I followed SIGCMD_FSD and I find in upsmon.c line 1363: sa.sa_handler = user_fsd; sigaction(SIGCMD_FSD, &sa, NULL); I followed user_fsd and I find in upsmon.c line 1324: static void user_fsd(int sig) { upslogx(LOG_INFO, "Signal %d: User requested FSD", sig); userfsd = 1; } I followed userfsd and I find in upsmon.c line 2002: /* check flags from signal handlers */ if (userfsd) forceshutdown(); I followed forceshutdown and I find on upsmon.c line 639: /* time expired or all the slaves are gone, so shutdown */ doshutdown(); I followed doshutdown and I find on upsmon.c line 445 ret = system(shutdowncmd); I followed shutdowncmd and I find in upsmon.c line 1063 that shutdowncommand is whatever has been declared with the keyword SHUTDOWNCMD. So the answer to my question is that David's /opt/upssched-cmd-custom shutdown-timer) clause with command "upsmon -c fsd" effectively executes the command specified by the upsmon.conf declaration SHUTDOWNCMD "systemctl hibernate", and that the NUT shutdown is clearly a NUT induced hibernation. It might be useful in a future revision of man 8 upsmon.conf to explain that in -c _command_ Send the command _command_ to the existing upsmon process. Valid commands are: fsd shutdown all master UPSes (use with caution) the "use with caution" means execution of whatever has been declared in upsmon.conf SHUTDOWNCMD. It might also be useful to complete the SHUTDOWNCMD declaration with something like: SHUTDOWNCMD "logger -t upssched-cmd-custom \"Calling upsmon -c fsd which calls\ SHUTDOWNCMD systemctl hibernate\"; systemctl hibernate" Roger
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 <users at lists.opensuse.org> 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.