Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 248263 - nut with upsdrvctl for a driver breaks "restart" of an init script
nut with upsdrvctl for a driver breaks "restart" of an init script
Status: CLOSED DUPLICATE of bug 193058
Product: Fedora
Classification: Fedora
Component: nut (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Tomas Smetana
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-07-14 13:50 EDT by Michal Jaegermann
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-15 07:45:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2007-07-14 13:50:11 EDT
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

'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):

How reproducible:
Comment 1 Tomas Smetana 2007-08-15 07:45:16 EDT

*** This bug has been marked as a duplicate of 193058 ***

Note You need to log in before you can comment on or make changes to this bug.