On Fri, 22 May 2015, Rob Groner wrote:
So I'm pursuing the strategy of issuing the "upsdrvctl shutdown" command
script when the OS (Porteus, in this case) is shutting down. I so far
can't get it to do it, but I'm sure I'll overcome it, but I realized
something else might be a problem.
Won't that script execute every time Linux is shutting down, including
rebooting? So, if I choose to reboot my system, I would most likely see
the UPS shutoff and then turn back on, somewhere in the middle of my
system booting back up.
Hello Robert, The command /sbin/shutdown -r used to reboot the box is
incompatible with a UPS which receives a delayed shutdown order. If you
have offdelay = 30 in /etc/ups/ups.conf, then 30 seconds after the
upsdrvctl shutdown, when the box has now probably restarted, the UPS will
shutdown with total loss of power to the box. Not good.
I can think of a couple solutions: 1) Have the script verify that the
UPS is actually in a OB state before giving the shutdown command. That
should prevent unintended UPS power cycles when simply rebooting the
system. 2) Have the UPS itself not respect any "load.off.delay" or
similar commands when it is online.
This adds complexity, and in a critical system component simplicity is a
virtue. To reboot my box, I turn off the wall power and wait until I hear
the "clunk" as the shutdown relay operates in the UPS. I then turn the
wall power back on.
Looking over UPS documentation and various helps, it seems most people
would expect their UPS to turn the load off and then back on, even if it
has wall power the entire time. That would facilitate testing at a
minimum. So I'm guessing option #2 isn't a good one.
If you have decided to use a UPS capable of shutting down and restarting
when wall power comes back, then you have to respect the UPS cycle. You
can't pretend it isn't there.
Best regards, Roger
_______________________________________________
Nut-upsuser mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
