[Nut-upsdev] Re: Some newhidups questions
arnaud.quette at mgeups.com
arnaud.quette at mgeups.com
Wed Jul 27 08:49:12 UTC 2005
[don't cc me, I'm already driving these list...]
> It would be helpful to get some indication as to which of the above items
> will limit operations the most. I have appended a list of the non-standard
> items that are available with the device, and I would like to ask for your
> guidance as to which items might be of interest to be added to the list of
> currently supported items, for what nut elements, and what tests I might
> perform to get more information about some attractive items.
>
> However, the major issue that I am confronting is that the current item
> for shutdown.return, does not have the effect that I think it should have
> (I am using upsmon -c fsd to attempt the shutdown, with the system not
> using the UPS),
>
> 1) the proper final "Executing automatic power-fail shutdown" messages are
> issued, and the upsmon processes terminate,
this only means that upsmon is exiting for power fail.
it then calls the shutdown command, which by side effect calls
the nut init.d script with the powerdown param. This last call
upsdrvctl shutdown, which calls the driver with "-k" (killpower).
And this last action simply ask the driver to execute the
"upsdrv_shutdown()" function... (see below)
> 2) but even under battery operation, the device does not shed the load,
> 3) the driver stays up, and upsd reports "Host 127.0.0.1 disconnected
> (read failure)", but while the device seems to have disconnected from
> the USB line, the driver is still attached to it,
the hosts disconnexion is about upsmon.
upsdrv_shutdown() has to be completed for APC, according to:
http://cvs.sourceforge.net/viewcvs.py/apcupsd/apcupsd/src/drivers/usb/usb.c?rev=1.6.2.2&view=markup
search for usb_ups_kill_power(), but other things like
s_known_info known_info should be interesting too...
> 4) I presume that if I would let the battery really go to empty, things
> would get cleaned up, and under those conditions, things might start
> cleanly, but that is not what I would like to have happen, and in any
> case, if the power were to come back before the battery is empty, the
> only possible recovery seems to be to kill everything by some other means.
yep, but that's not a good option
> Yes, I know, Arnaud hinted at this, but I wanted to see where I am at,
> and now I can see clearly where I need help!
Another point would be to ask APC for some info about their usage name
(ie what is APC8600?? ...)
When you have studied the above, get back so we can check to
add this in newhidups.
Arnaud
More information about the Nut-upsdev
mailing list