Bug 248263
| Summary: | nut with upsdrvctl for a driver breaks "restart" of an init script | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
| Component: | nut | Assignee: | Tomas Smetana <tsmetana> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-08-15 11:45:16 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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