Description of problem: With nut configured to use upsdrvctl every time when I am running service ups restart this causes the following: Stopping UPS monitor: [ OK ] Stopping upsd: [ OK ] Shutting down upsdrvctl: Network UPS Tools - UPS driver controller 2.0.5 Starting upsdrvctl: /dev/ttyS0 is locked by another process Network UPS Tools - Best UPS driver 1.03 (2.0.5) Driver failed to start (exit status=1) Network UPS Tools - UPS driver controller 2.0.5 [FAILED] 'upsd' and 'upsmon' will start and pretty soon I will see in mail: Communications with UPS PatriotPro750@localhost lost followed by a spate of messages UPS PatriotPro750@localhost is unavailable '/dev/ttyS0' happens to be a serial port to which a signalling cable from UPS is attached. The problem is that a communication with UPS hardware takes a considerable time but '/sbin/upsdrvctl stop' does not wait for a confirmation. A subsequent "start" finds a communication line still locked by an old instance of a driver, which will go away "soon", and we are off to la-la land. Experimentally I found that for the setup in question putting "sleep 4" between "stop" and "start" in restart() funtion of /etc/init.d/ups is good enough to prevent the issue. More precisely "sleep 3" would likely be sufficient and "sleep 2" was "hit-or-miss". Definitely more robust would be to wait in a loop for an old driver process (or processes with multiple UPS units) to go away before attempting to start again. Or maybe it is enough to do /sbin/upsdrvctl stop killproc $mymodel where $mymodel is read from /etc/ups/ups.conf. Possibly looping through all models if there are multiple ups units. The current arrangement simply does not work. Version-Release number of selected component (if applicable): nut-2.0.5-3 How reproducible: always
*** This bug has been marked as a duplicate of 193058 ***