[Nut-upsdev] problem with restarting nut

[Arjen de Korte]

Citeren Michal Hlavinka <mhlavink op redhat.com>:

> 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