On 3/3/10 3:53 PM, Arjen de Korte wrote:
Citeren Steave Golson <[email protected]>:
However the driver ignores my setting, and forces UPSD to have a value
of "1" just before issuing the UPPC shutdown command. Removing this
UPSD allows the custom value to be used correctly.
I attempted to fix this, by setting "ups.delay.shutdown=10" and
"ups.delay.reboot=120" when the driver starts monitoring the UPS (in
order to have some sensible defaults). If you restart the driver with
the -k flag (in order to send the shutdown command), this part of the
code will be skipped and the driver will proceed to send the
"shutdown.return" instcmd (twice actually, with a one second delay in
between) with any "ups.delay.shutdown" that may have been set in the
mean time. I agree that it isn't pretty to allow people to set a
shutdown delay and then when the time comes to shutdown, completely
ignore whatever they requested.
That's a good solution.
I think instcmd should be "shutdown.reboot" instead of "shutdown.return". My
UPS does not support UPPF command but does support UPPC. You really want it to
shutdown regardless of the state of line power, then it will come back up
after ups.delay.reboot seconds.
Also I changed the shutdown messages so the ups.delay.* values are
reported.
I fail to see the benefit of that. The filesystems should have been
(re)mounted read-only and we probably don't have network connectivity
anymore at that time, so unless someone is watching the console at that
time, the messages will be lost forever. The reason why we have them
here, is for debugging purposes.
Yes, good point. If necessary I can send those parameters to syslog when the
shutdown process first starts.
Having said that, thanks for your feedback. It's been quite a while
since we've seen someone running this driver and it is good to know that
it still serves a purpose to maintain it. If you have the time to
checkout the latest version from the trunk, I would be grateful.
I will, thanks for the quick action.
-seg
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
