Help with edge cases (UPS coming back online before shutdown is complete)

[rapperskull]

I managed to configure a Vultech UPS1400VA-LFP UPS after some fighting.

However, I discovered that it has some quirks that make it a little bit difficult to use. In particular, shutdown.return and shutdown.stayoff do nothing, so I had to set sdcommands = load.off. This works to shut the load down, and everything will turn on after power is back.

There is a problem, however, if power comes back while the shutdown is in progress, because of two things happening when load.off is executed when the UPS is OL:

1. The load is not actually shut down. This is expected, since the UPS will be in bypass mode, but it means the PC will stay off forever, since power is never cycled.
2. The UPS disables its backup functionality by forcefully staying in bypass mode. If power goes down again, the output will simply shut off. This is the case until the load.on command is executed. Of course this doesn't happen if load.off is executed while OB.

I can probably work around problem 1 somehow (for example using a RPi to WoL the PC when power is back), but problem 2 is an issue.

Is there any way to execute load.on automatically on startup to try and fix that?

Do you have any suggestion on a workaround for problem 1 too?

Thank you.

EDIT: I tried forcing a shutdown and reboot by executing test.battery.start.quick while stuck in forced bypass mode, but the UPS outsmarted me and doesn't execute the command.

[jimklimov]

The default NUT proposal for "problem 1" known as a "power race condition" (see FAQ for several takes on the idea) is https://github.com/networkupstools/nut/blob/master/scripts/systemd/nutshutdown.in to talk to the UPS about shutting it down (if the OS is going down due to a power event), If you set up POWEROFF_WAIT, the computer should stay up sleeping for that time and reboot if still alive. This does drain battery till poweroff (whether a little because the UPS handled the request, or fully emptied away if it did not handle it).

For "problem 2" I can suggest defining a systemd unit which would require a running nut-server.service and perhaps nut-driver@upsname.service (or a late-order init script on other systems), and run-once to upscmd -w upsname load.on.

[rapperskull]

For "problem 2" I can suggest defining a systemd unit which would require a running nut-server.service and perhaps nut-driver@upsname.service (or a late-order init script on other systems), and run-once to upscmd -w upsname load.on.

I will try this approach, but I was hoping there was a built-in feature in nut to automatically send commands on startup. It may be useful also for other stuff, such as disabling the beeper.

[rapperskull]

Ok, I tried to set everything up.

As for problem 2, it worked, but I had to add some seconds of sleep to my systemd unit's ExecStartPre, otherwise it would fail with CMD-NOT-SUPPORTED. Maybe the driver is not ready yet when nut-driver@upsname.service starts?

For problem 1, instead, I got to the "System will sleep for X seconds" message, but instead the PC shut down instead of actually sleeping and rebooting.

[jimklimov]

Maybe the driver is not ready yet when nut-driver@upsname.service starts?

Depends on NUT version and build options. If the driver is Type=notify, it tells systemd when it is ready to work. Otherwise (e.g. in older packages) systemd says the daemon is ready as soon as the child process is forked off from the service manager daemon - then yes, you'd need to wait.

Out of the box

Not quite possible currently, as the drivers process commands passed via data server. One exception is killing power via drivername -k, and with 2.8.3 or later releases you can fiddle with sdcommands option to pass something else (e.g. to test shutdowns with a beeper instead).

[jimklimov]

For problem 1, instead, I got to the "System will sleep for X seconds" message, but instead the PC shut down instead of actually sleeping and rebooting.

How soon? Did the UPS kill it? Alternately, could systemd time out and kill the hook script, and move on with requested shutdown?

[rapperskull]

For problem 1, instead, I got to the "System will sleep for X seconds" message, but instead the PC shut down instead of actually sleeping and rebooting.

How soon? Did the UPS kill it? Alternately, could systemd time out and kill the hook script, and move on with requested shutdown?

No, it was not the UPS. The battery was on 100% and I executed upsmon -c fsd to test it. It shut down after about 1 minute. I think it was systemd timing out, as you suggested.

[rapperskull]

Do you have any idea on how to check if systemd is actually terminating the script?

[jimklimov]

On one hand, journal -x executed as root should show many clues, including if it used a kill due to timeout (or explicit request). On another, usually kills start with SIGTERM (signal number 15) and are seen in exit-code 143 (128+15).