Bug 242227

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.