Nut upsdev - Dec 2013 - Nut (git) upsdrvctl fails without "-u root start <upsname>", upsd fails on state file GID

All,

  I have built and installed nut from git on Archlinux. It uses the usbhid
driver. Beginning a couple of years ago, nut begin failing to run on Archlinux
without 'tweaking' or 'fudging' the install. There are two
primary problems:

  (1) upsdrvctl cannot be launched normally i.e. (/usr/sbin/upsdrvctl start)
without failing to connect:

Dec 14 02:24:39 phoinix systemd[1]: Starting Network UPS Tools - power device
driver controller...
Dec 14 02:24:39 phoinix systemd[1]: nut-driver.service: control process exited,
code=exited status=1
Dec 14 02:24:39 phoinix systemd[1]: Failed to start Network UPS Tools - power
device driver controller.
Dec 14 02:24:39 phoinix systemd[1]: Dependency failed for Network UPS Tools -
power devices information server.
Dec 14 02:24:39 phoinix systemd[1]: Unit nut-driver.service entered failed
state.
Dec 14 02:24:39 phoinix upsdrvctl[28629]: Network UPS Tools - Generic HID driver
0.38 (2.7.1-signed-9-g6fb35b3)
Dec 14 02:24:39 phoinix upsdrvctl[28629]: USB communication driver 0.32
Dec 14 02:24:39 phoinix upsdrvctl[28629]: No matching HID UPS found
Dec 14 02:24:39 phoinix upsdrvctl[28629]: Driver failed to start (exit status=1)

lsusb shows:

Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS

  Fudging the options for upsdrvctl and limiting the start to one ups allows
upsdrvctl to find the ups device and works:

/usr/sbin/upsdrvctl -u root start phoinix_ups

(both -u root and the ups name are required before it will find the device)

  (2) Starting upsdrvctl this way creates a problem with the GID of the files
created in /var/state/ups causing upsd to fail to connect to the ups device (at
least it starts without failing - in 2.6.x it would not start):

[02:47 phoinix:/var/state] # l ups
total 16
-rw-r--r-- 1 root root    6 Dec 14 02:36 upsd.pid
-rw-rw---- 1 root root    0 Dec 14 02:36 usbhid-ups-phoinix_ups
-rw-r--r-- 1 root root    6 Dec 14 02:36 usbhid-ups-phoinix_ups.pid

  However, manually changing group ownership to root:nut and setting the setuid
and setgid bits allows upsd to start normally and preserves the setting across
reboot:

[02:47 phoinix:/var/state] # l ups
total 16
drwsrws--- 2 root nut  4096 Dec 14 02:36 .
drwxr-xr-x 3 root root 4096 Dec 14 02:06 ..
-rw-r--r-- 1 root nut     6 Dec 14 02:36 upsd.pid
srw-rw---- 1 root nut     0 Dec 14 02:36 usbhid-ups-phoinix_ups
-rw-r--r-- 1 root nut     6 Dec 14 02:36 usbhid-ups-phoinix_ups.pid

  But these are still kludges to get nut to start and run properly. Why
doesn't
"upsdrvctl start" allow nut to find the UPS when it can find it
without a
problem with the options "-u root start <upsname>"?  Second why
doesn't nut
create the .pid files and the usbhid file with root:nut ownership?

  These problems have been around a while. I used nut for a long time before
these problems popped up, and I would like to help get them solved. I know the
hotplugging, etc. causes problems, but it is hard to understand how it used to
work just fine and now doesn't. Let me know what else I can send, and
I'm happy
to do it. The configure options used building nut were:

    ./autogen.sh
    ./configure \
         --without-wrap \
         --with-user=ups \
         --with-group=nut \
         --with-usb \
         --with-cgi \
         --prefix=/usr \
         --sbindir=/usr/bin \
         --datadir=/usr/share/ups \
         --with-drvpath=/usr/bin \
         --sysconfdir=/etc/ups \
         --with-udev-dir=/usr/lib/udev \
         --with-systemdsystemunitdir=/lib/systemd/system \
         --with-cgipath=/srv/http/cgi-bin/nut \
         --with-htmlpath=/srv/http/htdocs/nut

  With the "fudges" it works:

03:15 phoinix:~/pkg/bld/network-ups-tools-git> upsc phoinix_ups
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 20
battery.mfr.date: CPS
battery.runtime: 1050
battery.runtime.low: 300
battery.type: PbAcid
battery.voltage: 13.5
battery.voltage.nominal: 12
device.mfr: CPS
device.model: UPS CP1000AVRLCD
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/hiddev0
driver.version: 2.7.1-signed-9-g6fb35b3
driver.version.data: CyberPower HID 0.3
driver.version.internal: 0.38
input.transfer.high: 140
input.transfer.low: 90
input.voltage: 121.0
input.voltage.nominal: 120
output.voltage: 120.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 26
ups.mfr: CPS
ups.model: UPS CP1000AVRLCD
ups.productid: 0501
ups.realpower.nominal: 88
ups.status: OL
ups.test.result: Done and passed
ups.timer.shutdown: -60
ups.timer.start: 0
ups.vendorid: 0764


-- 
David C. Rankin, J.D.,P.E.

On Dec 14, 2013, at 4:19 AM, David C. Rankin wrote:
> lsusb shows:
> 
> Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS

I am guessing that 'ls -l /dev/bus/usb/004/002' shows that the device
node is not owned by the NUT gid?
> Why doesn't
> "upsdrvctl start" allow nut to find the UPS when it can find it
without a
> problem with the options "-u root start <upsname>"?
The NUT USB drivers use libusb, which need read/write access to the /dev node
for the UPS. The "-u root" hack tells the driver not to drop
privileges from root to the 'nut' system user.
> Second why doesn't nut create the .pid files and the usbhid file with
root:nut ownership?
Mostly because the "-u root" option is meant to be a temporary fix
while tracking down permissions issues. Hopefully we can figure out the
underlying permissions issue, and we can table that question.
>  These problems have been around a while. I used nut for a long time before
> these problems popped up, and I would like to help get them solved. I know
the
> hotplugging, etc. causes problems, but it is hard to understand how it used
to
> work just fine and now doesn't. Let me know what else I can send, and
I'm happy
> to do it.
I haven't mapped out all of the combinations, but we've heard similar
issues from people running older versions of NUT (which worked when they were
released) when it comes to hotplug/udev permissions on newer Linux systems.

I'm frustrated as well - all I can think is that there is some subtle change
in how the kernel and udev are creating the device nodes. See:

   http://thread.gmane.org/gmane.comp.monitoring.nut.user/8180

   http://thread.gmane.org/gmane.comp.monitoring.nut.user/8207

Apparently the auto-generated udev rules file does not successfully set the
permissions on the UPS USB device, but simpler hand-written rules often suffice.

If anyone has suggestions on udev debugging techniques (besides sprinkling the
source code with log statements, which I would rather not do on a
"production" system), I'm listening.

-- 
Charles Lepple
clepple at gmail

On 12/14/2013 07:20 AM, Charles Lepple wrote:
> On Dec 14, 2013, at 4:19 AM, David C. Rankin wrote:
> 
>> lsusb shows:
>> 
>> Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR
UPS
> 
> 
> I am guessing that 'ls -l /dev/bus/usb/004/002' shows that the
device node is
> not owned by the NUT gid?
> 
crw-rw-r-- 1 root root 189, 385 Dec 14 12:31 /dev/bus/usb/004/002

It does now.
>> Why doesn't "upsdrvctl start" allow nut to find the UPS
when it can find it
>> without a problem with the options "-u root start
<upsname>"?
> 
> The NUT USB drivers use libusb, which need read/write access to the /dev
node
> for the UPS. The "-u root" hack tells the driver not to drop
privileges from
> root to the 'nut' system user.
> 
That's what I thought was going on, I just didn't know where to fix the
usb dev
node.
>> Second why doesn't nut create the .pid files and the usbhid file
with
>> root:nut ownership?
> 
> Mostly because the "-u root" option is meant to be a temporary
fix while
> tracking down permissions issues. Hopefully we can figure out the
underlying
> permissions issue, and we can table that question.
> 
<snip>

I found another really good article that describes writing the udev files to fix
these issues. The url is:

http://www.kepstin.ca/blog/networkupstoolsnutandsystemd/

I will test with the new ubs dev permission and report back. Thank you for your
help Charles.

-- 
David C. Rankin, J.D.,P.E.