Red Hat Bugzilla – Bug 242227
upsd fails to connect after nut-2.0.5 upgrade
Last modified: 2008-02-06 04:13:06 EST
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): nut-2.0.5-3 How reproducible: Every time Steps to Reproduce: 1. Have the following in /etc/sysconfig/ups MODEL=newhidups DEVICE=auto 2. /etc/ups/ups.conf [auto] 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: MODEL=upsdrvctl # 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
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.
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.
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.]
Can you try changing /etc/sysconfig/ups to: MODEL=upsdrvctl and see if this works any better?
Thank you, Jon. Changing the MODEL in /etc/sysconfig/ups #MODEL=apcsmart MODEL=upsdrvctl does indeed appear to have fixed both problems! :-) No error messages and upsc is reporting reasonable-looking values.
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... Oops!
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.
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.
> 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.
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?
I'm closing the bug. Feel free to reopen if problems persist/reappear.