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.