Bug 242227 - upsd fails to connect after nut-2.0.5 upgrade
Summary: upsd fails to connect after nut-2.0.5 upgrade
Alias: None
Product: Fedora
Classification: Fedora
Component: nut (Show other bugs)
(Show other bugs)
Version: 7
Hardware: All Linux
Target Milestone: ---
Assignee: Tomas Smetana
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-02 11:39 UTC by Jon Burgess
Modified: 2008-02-06 09:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-06 09:13:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Workaround for /etc/init.d/ups (292 bytes, patch)
2007-06-02 11:56 UTC, Jon Burgess
no flags Details | Diff

Description Jon Burgess 2007-06-02 11:39:34 UTC
Description of problem:
Existing setup with nut-2.0.4 fails on upgrade to nut-2.0.5

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Have the following in /etc/sysconfig/ups


2. /etc/ups/ups.conf
        driver = newhidups
        port = auto
        vendor = Belkin
        desc = "Giga, Asus, LCD"

3. service ups start
Actual results:
# service ups start
Starting newhidups: Network UPS Tools: 0.28 USB communication driver 0.28 - core
0.30 (2.0.5)

Detected a UPS: Belkin /UPS
Using subdriver: Belkin HID 0.1
                                                           [  OK  ]
Starting upsd: Network UPS Tools upsd 2.0.5
Can't connect to UPS [auto] (auto): No such file or directory
                                                           [  OK  ]

Expected results:
* after changing /etc/sysconfig/ups to:

# service ups start
Starting upsdrvctl: Network UPS Tools - UPS driver controller 2.0.5
Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.0.5)

Detected a UPS: Belkin /UPS
Using subdriver: Belkin HID 0.1
                                                           [  OK  ]
Starting upsd: Network UPS Tools upsd 2.0.5
Connected to UPS [auto]: auto
                                                           [  OK  ]

Additional info:
Looks like the nut team made an incompatible change to the socket names in 2.0.5
which means that using the MODEL=<dirver> method in /etc/sysconfig/ups is now
broken and upsdrvctl must now always be used even for a single UPS.

See: http://lists.alioth.debian.org/pipermail/nut-upsuser/2007-May/002777.html

Comment 1 Jon Burgess 2007-06-02 11:56:44 UTC
Created attachment 155975 [details]
Workaround for /etc/init.d/ups

Attached is a slightly hackish solution which enables my existing nut-2.0.4
config to carry on working in nut-2.0.5. I've no idea whether this is preferred
over using upsdrvctl unconditionally.

Comment 2 Allan Engelhardt 2007-06-08 14:28:39 UTC
I have the same problem.  The issue is squarely with the rc.d / init/d scrips or
upsdrvctl : I can start all the components manually just fine using the commands

  $ apcsmart -u nut -a 'home'
  $ upsd -u nut -f
  $ upsmon -u nut

gives me the same error (except for the name of the ups):

  Can't connect to UPS [home] (home): No such file or directory

I am using nut-2.0.5-3 on Fedora 7 x86_64.

Comment 3 Allan Engelhardt 2007-06-08 14:35:05 UTC
The proposed patch does not completely work for me: While it does get rid of the
immediate error message, upsmon is unable to monitor the device when started
from the (patched) script, but (seems to?) work fine when started from the
command line as above.

[My config files worked reliably in fc6.]

Comment 4 Jon Burgess 2007-06-08 19:59:20 UTC
Can you try changing /etc/sysconfig/ups to:

and see if this works any better?

Comment 5 Allan Engelhardt 2007-06-09 08:21:29 UTC
Thank you, Jon.  Changing the MODEL in /etc/sysconfig/ups


does indeed appear to have fixed both problems! :-)  No error messages and upsc
is reporting reasonable-looking values.

Comment 6 Michal Jaegermann 2007-07-04 03:36:16 UTC
I got into troubles after an update from nut-2.0.3 to nut-2.0.5 on F7.
Proposed in comment #1 

    ln -sf /var/run/nut/$MODEL-$DEVICE /var/run/nut/$DEVICE

made things only worse as MODEL in my case was "bestups" and
DEVICE was "/dev/ttyS0" which happened to work just fine so far
but was clearly leading to a disaster here.

Observing results maybe "PatriotPro750" was expected.  This did
not matter in startup as /sbin/bestups does not accept any extra
options. :-)

Changing to MODEL=upsdrvctl indeed made all of this to work.
With one excepion, though:

# service ups status
Network UPS Tools - UPS driver controller 2.0.5
/sbin/upsdrvctl: invalid option -- v
Starts and stops UPS drivers via ups.conf.

usage: /sbin/upsdrvctl [OPTIONS] (start | stop | shutdown) [<ups>]

  -h                    display this help
  -r <path>             drivers will chroot to <path>
  -t                    testing mode - prints actions without doing them
  -u <user>             drivers started will switch from root to <user>
  -D                    raise debugging level
  start                 start all UPS drivers in ups.conf
  start <ups>           only start driver for UPS <ups>
  stop                  stop all UPS drivers in ups.conf
  stop <ups>            only stop driver for UPS <ups>
  shutdown              shutdown all UPS drivers in ups.conf
  shutdown <ups>        only shutdown UPS <ups>
upsd (pid 17702) is running...
upsmon (pid 17706 17705) is running...


Comment 7 Michal Jaegermann 2007-07-04 07:20:00 UTC
There is yet another problem in a startup. UPS processes are running
with "nut:nut" ownership but they have to be able to access a serial
port to which a UPS monitor cable is connected.  Without an ownership
change on a required serial port there is no way to access udev
created devices (unless you want to make that port "rw" for all which
I would rather not) and UPS processes do start but they are not
doing anything useful.

Comment 8 Allan Engelhardt 2007-07-04 07:26:47 UTC
I do not understand Michal's Comment #7 : if it is a permission issue, why does
changing the backend to upsdrvctl work for everybody?

But to confirm Comment #6 : I see the same ‘service ups status’ issue.

Comment 9 Michal Jaegermann 2007-07-04 14:59:47 UTC
> why does changing the backend to upsdrvctl work for everybody?

This "everybody" definitely does not cover a machine I was working
on yesterday and for which 'upsc' shows, among other things,

driver.name: bestups
driver.parameter.port: /dev/ttyS0
driver.version: 2.0.5
driver.version.internal: 1.03

Before I added to my startup script 'chown "nut:nut" /dev/ttyS0'
I was getting OK from 'service ups start' with upsdrvctl,
upsd.pid and upsmon.pid were in /var/run/nut/ and corresponding
processes were in a process table, but there was neither
/var/run/nut/bestups-PatriotPro750.pid nor
/var/run/nut/PatriotPro750 and attempts to communicate with UPS
were failing.  After that 'chown' everything started to work.

Sure, I can try to add in /etc/security/console.perms.d/ some
specific rules but tweaking a startup script was easier. :-)

This particular setup was doing just fine for at least six
years although it required some configuration tweaks in time
of a change from nut-1.x.x to nut-2.y.y.

Comment 10 Tomas Smetana 2008-01-30 10:54:47 UTC
I'm sorry I neglected this bug for such a long time...  The problem is that
2.0.5 is a backport of a development version that uses only one supported
backend (upsdrvctl).  The other problems with init scripts should be fixed in
the recent nut packages.  Does anybody experience problems with nut-2.0.5-7? 

Comment 11 Tomas Smetana 2008-02-06 09:13:06 UTC
I'm closing the bug.  Feel free to reopen if problems persist/reappear.

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