Citeren Michal Hlavinka <[email protected]>:
Hi,
one user found problem with restarting nut. upsdrvctl does not wait for
drivers being really terminated. In init scripts we have following:
killproc upsmon
killproc upsd
upsdrvctl stop
and then
upsdrvctl start
upsd
upsmon
problem is upsdrvctl stop only sends terminating signals but does
not wait for
driver termination.
This is by design. If the battery is low, we don't want to hang around
waiting for a driver that fails to respond immediately. Instead, the
system should proceed shutting down immediately (to deal with systems
where stop scripts are not run concurrently).
This makes driver fail to start sometimes when old driver
is still running because "device is locked by another process".
Known issue, which has been discussed several times in the past as
well. The solution is also well known. If you put a 'sleep 2' between
stopping and starting of upsdrvctl, all sane drivers will have had
plenty of time to notice this. If you find one that doesn't, please
let us know (and we can fix it).
I've prepared
patch cloning stop_driver function to wait_driver_stoped which blocks until
timeout or until /proc/<pid> disappears. This function is called after
send_all_drivers(stop_driver). See attached patch.
Patch is missing, but I very much doubt we would take the risk to do
this anyway. I don't think we want to risk a longer delay at a time
where the battery is critical, versus a minor inconvenience when
restarting NUT (which can be fixed with a small delay).
If you don't want to make this changes I can modify init script restart
function instead to wait until all processes with pid in /var/run/nut/*.pid
files are dead, but I find this quite ugly.
It's not needed. Any driver that fails to respond to a signal to stop
within two seconds, is not listening anymore. So if after waiting for
two seconds the driver has not stopped, it never will. I doubt that
adding a two second delay in a restart script is noticeable.
Best regards, Arjen
--
Please keep list traffic on the list
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
