The problem of NUT not operating after returning from a suspend state is
located in upsd. I figured that I could try to restart each part of the
chain driver->upsd->upsmon separately. Restarting the driver and/or
upsmon didn't solve the problem, bur restarting upsd did. So I have come
to the conclusion that upsd misses a state change and somehow relies on
a cached state. I'm not familiar enough with the code to debug this. If
someone has an idea, I'm willing to try it out however.
In retrospect, I have some doubts that it is a good idea to keep NUT
active when suspend-to-disk is used. It doesn't work right now (at
least, not for me), but I get the feeling that fixing this is not going
to be worth the effort.
At least one type of UPS (the cheapo versions the safenet driver is
intended for) forget all settings once they have powered off. From this
state, you'll have to initialize the communication with the UPS from
scratch to be able to talk to it. But since we have no idea what
happened to the mains during the suspended state, it means you'll have
to do this always. Regardless whether the AC mains was actually lost or
someone at the terminal issued a suspend command.
So since we'll need to restart the driver anyway, shutting it down
cleanly when suspending and starting it again when the power comes back
(or the system wakes up from the suspended state) makes much more sense
and the whole problem becomes a moot issue. You can't keep NUT active on
suspend, because you don't know what happens in the mean time to the UPS.
Regards,
Arjen
PS Attached the (modified) code for the 'safenet' driver used in
testing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: safenet.c
Type: text/x-csrc
Size: 13277 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20060109/3ae6e8ab/safenet-0001.c
