Thanks, Charles.  I pulled your change and it fixed my segmentation

I discovered the following code at line 571 in usbhid-ups.c.  This is
part of the "checking for alternatives" code:

                if (!strcasecmp(cmdname, "shutdown.return")) {
                        int     ret;

                        /* Ensure "" is set to "yes", if 
supported */
                        if (dstate_getinfo("")) {
                                setvar("", "yes");

                        ret = instcmd("load.on.delay", 
                        if (ret != STAT_INSTCMD_HANDLED) {
                                return ret;

                        return instcmd("", 

My understanding of this code is that it attempts to set the
load.on.delay control.  If that works, it then uses to
schedule a shutdown.  My unit has nothing that maps into load.on.delay,
so that command fails, and then it does not use  Instead
it fails, and the calling code goes on to try shutdown.reboot, which in
my case has the completely wrong functionality.

However, seems to be the right thing to use for me.
Without any other setting, it shuts off the UPS after the delay and
reboots it when the power returns.  I don't know what functionality
load.on.delay is supposed to represent.  Is it trying to avoid the race
where the power comes on before the command has reached
the UPS, which then never restarts the load?

Since this race seems fairly unlikely to cause trouble and with the code
above my UPS is unusable, I modified my copy of the code to remove the
check for the return value from load.on.delay.  This indeed causes it to
shut down the UPS as it should.

I'm sure this is not the right fix in general, but I don't understand
the situation well enough to know what would be better.  Among other
things I don't know is whether my real problem is with this logic or
whether it is with the mapping of things like
UPS.OutletSystem.Outlet.DelayBeforeShutdown to things like


Nut-upsuser mailing list

Reply via email to