Simon Wilson
2022-Nov-30 07:20 UTC
[Nut-upsuser] NUT no longer works after 2.7 -> 2.8 upgrade
----- Message from Bill Gee <bgee at campercaver.net> ---------
Date: Tue, 29 Nov 2022 19:25:19 -0600
From: Bill Gee <bgee at campercaver.net>
Subject: Re: [Nut-upsuser] NUT no longer works after 2.7 -> 2.8 upgrade
To: Jim Klimov <jimklimov+nut at gmail.com>
Cc: Arnaud Quette via Nut-upsuser <nut-upsuser at
alioth-lists.debian.net>
> I got it to run, but what a mess ...
>
> Yes, I am running systemctl daemon-reload and systemctl restart
> nut-server after each change I make.
>
Hi Bill,
Drivers and upsd share defaults (see 'man nutupsdrv').
Your original error message ("writepid: fopen
/var/run/usbhid-ups-cyberpower.pid: Permission denied") would seem to
indicate, same as the Red Hat bug, that your driver's default pid path
is /var/run.
The driver by default uses STATEPATH (which can be over-ridden in
upsd.conf) to store pid files. The driver .service file is supposed to
make sure that path exists by running the ExecStartPre line, which
gets its instructions from the referenced ".conf" file from
/usr/lib/tmpfiles.d. The .service file then calls 'upsdrvctl start' to
start your usbhid-ups driver, as defined in ups.conf. Those all need
to align...
2 x questions:
1. Without its comments, what are the active lines (as installed,
without any changes) in /usr/lib/systemd/system/nut-driver at .service
(or wherever that service file is located on your system)?
2. in your upsd.conf (also as installed, without any changes), what is
the commented out STATEPATH you later mention uncommenting?
> I created /usr/lib/tmpfiles.d/nut-client.conf The owner is
> root:root and permissions are 0644. The contents are
>
> # State file (e.g. upsd to driver) and pidfile location for NUT:
> D /var/run/nut 0770 root nut - -
> X /var/run/nut
>
> I uncommented the STATEPATH line in /etc/ups/upsd.conf.
>
> I created a directory /var/state/ups, set to 777 permissions.
> Changed the STATEPATH line in upsd.conf. No success.
>
> I looked at /usr/lib/systemd/system/nut-driver at .service but could
> not see any changes to be made. The bug report at RedHat mentions
> that a file identified in ExecStartPre does not exist, but I could
> not duplicate.
>
> I tried running this as root:
>
> NUT_STATEPATH=/var/state/ups NUT_ALTPIDPATH=/var/state/ups
> /usr/sbin/usbhid-ups -u nut -g nut -s cyberpower -x port=auto
>
> And it works. I tried it with only one or the other of the two
> environment variables, but did not work. It has to have both.
>
> ==============> Bill Gee
>
>
> On 11/29/22 17:43, Jim Klimov wrote:
>> As recently noted in the lists, this was tracked
>> down to a Fedora 37 packaging bug:
>> https://bugzilla.redhat.com/show_bug.cgi
>> <https://bugzilla.redhat.com/show_bug.cgi>?id=2127269
>>
>> > The nut user does not have write permissions at /run.
>> Note that /run is linked as /var/run and the nut user DOES have write
>> permissions there.
>>
>> These two statements do not fit together :) Permissions on symlink
>> do not matter, only the ultimate object's rights do (root-owned
>> /run). The packaging error is that (/var)/run/nut should have been
>> used for drivers and upsd, or /var/state/ups as it should also
>> exist and be accessible to these. For a quick fix you can set
>> Environment=NUT_ALTPIDPATH=/var/state/ups for their systemd units
>> or respective custom drop-in files.
>>
>> Jim
>>
>> On Tue, Nov 29, 2022, 14:06 Bill Gee <bgee at campercaver.net
>> <mailto:bgee at campercaver.net>> wrote:
>>
>> Yesterday I upgraded one of my systems from Fedora 36 to Fedora
>> 37. NUT
>> was upgraded to version 2.8.0.? It no longer runs.
>>
>> At first I thought it was because of the XFCE Power Manager program.
>> That program finds the UPS with no problem.? I thought maybe the two
>> programs were competing for the UPS port.? I shut down the XFCE
power
>> manager, but that did not help NUT.
>>
>> Based on the diagnostics given below, I think this is a permissions
>> problem at /run.? The nut user does not have write permissions at
/run.
>> Note that /run is linked as /var/run and the nut user DOES have
write
>> permissions there.
>>
>> How can I correct this?
>>
>> ======================================>> [root at mythtv
ups]# systemctl status nut-server
>> nut-server.service - Network UPS Tools - power devices information
>> server
>> ? ? ? Loaded: loaded (/usr/lib/systemd/system/nut-server.service;
>> enabled; preset: disabled)
>> ? ? ? Active: active (running) since Tue 2022-11-29 06:18:13 CST;
>> 19min ago
>> ? ? Main PID: 11908 (upsd)
>> ? ? ? ?Tasks: 1 (limit: 9482)
>> ? ? ? Memory: 736.0K
>> ? ? ? ? ?CPU: 27ms
>> ? ? ? CGroup: /system.slice/nut-server.service
>> ? ? ? ? ? ? ? ??11908 /usr/sbin/upsd -F
>>
>> Nov 29 06:18:13 mythtv.billgee.local upsd[11908]: Can't connect
to UPS
>> [cyberpower] (usbhid-ups-cyberpower): No such fi>
>> Nov 29 06:18:13 mythtv.billgee.local nut-server[11908]: Can't
>> connect to
>> UPS [cyberpower] (usbhid-ups-cyberpower): No s>
>> Nov 29 06:18:13 mythtv.billgee.local nut-server[11908]: Running as
>> foreground process, not saving a PID file
>> Nov 29 06:18:13 mythtv.billgee.local upsd[11908]: Running as
foreground
>> process, not saving a PID file
>> Nov 29 06:23:13 mythtv.billgee.local nut-server[11908]: Can't
>> connect to
>> UPS [cyberpower] (usbhid-ups-cyberpower): No such file or
directory>
>> Nov 29 06:23:13 mythtv.billgee.local upsd[11908]: Can't connect
to UPS
>> [cyberpower] (usbhid-ups-cyberpower): No such file or directory>
>>
>> [root at mythtv ups]# usbhid-ups -a cyberpower
>> Network UPS Tools - Generic HID driver 0.47 (2.8.0)
>> USB communication driver (libusb 1.0) 0.43
>> writepid: fopen /var/run/usbhid-ups-cyberpower.pid: Permission
denied
>> Using subdriver: CyberPower HID 0.6
>> cps_adjust_battery_scale: battery readings will be scaled by 2/3
>>
>> Fatal error: unable to create listener socket
>>
>> bind /var/run/usbhid-ups-cyberpower failed: Permission denied
>>
>> Exiting.
>>
>> [root at mythtv ups]# ll /var/run/usb*
>> ls: cannot access '/var/run/usb*': No such file or directory
>>
>> [root at mythtv ups]# ll -d /var/run
>> lrwxrwxrwx. 1 root root 6 Aug 31? 2014 /var/run -> ../run
>>
>> [root at mythtv ups]# ll -d /run
>> drwxr-xr-x 55 root root 1500 Nov 28 08:22 /run
>>
>> [root at mythtv ups]# tail /etc/ups/ups.conf
>> [cyberpower]
>> ? ? ? ? ?driver=usbhid-ups
>> ? ? ? ? ?desc="CyberPower CP1500"
>> ? ? ? ? ?port=auto
>> ? ? ? ? ?vendorid=0764
>> =================================================>>
>>
>> Thanks!
>> -- ==============>> Bill Gee
>>
>> _______________________________________________
>> Nut-upsuser mailing list
>> Nut-upsuser at alioth-lists.debian.net
>> <mailto:Nut-upsuser at alioth-lists.debian.net>
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
<https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
>>
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
----- End message from Bill Gee <bgee at campercaver.net> -----
--
Simon Wilson
M: 0400 12 11 16
Jim Klimov
2022-Nov-30 08:05 UTC
[Nut-upsuser] NUT no longer works after 2.7 -> 2.8 upgrade
FWIW, just checked: `git grep nut-client` does not return anything related to systemd, so that typo gotta be Fedora's invention ;) In-source there is only nut-common.tmpfiles handling. Jim On Wed, Nov 30, 2022 at 8:20 AM Simon Wilson via Nut-upsuser < nut-upsuser at alioth-lists.debian.net> wrote:> ----- Message from Bill Gee <bgee at campercaver.net> --------- > Date: Tue, 29 Nov 2022 19:25:19 -0600 > From: Bill Gee <bgee at campercaver.net> > Subject: Re: [Nut-upsuser] NUT no longer works after 2.7 -> 2.8 upgrade > To: Jim Klimov <jimklimov+nut at gmail.com> > Cc: Arnaud Quette via Nut-upsuser < > nut-upsuser at alioth-lists.debian.net> > > > > I got it to run, but what a mess ... > > > > Yes, I am running systemctl daemon-reload and systemctl restart > > nut-server after each change I make. > > > > Hi Bill, > > Drivers and upsd share defaults (see 'man nutupsdrv'). > > Your original error message ("writepid: fopen > /var/run/usbhid-ups-cyberpower.pid: Permission denied") would seem to > indicate, same as the Red Hat bug, that your driver's default pid path > is /var/run. > > The driver by default uses STATEPATH (which can be over-ridden in > upsd.conf) to store pid files. The driver .service file is supposed to > make sure that path exists by running the ExecStartPre line, which > gets its instructions from the referenced ".conf" file from > /usr/lib/tmpfiles.d. The .service file then calls 'upsdrvctl start' to > start your usbhid-ups driver, as defined in ups.conf. Those all need > to align... > > 2 x questions: > > 1. Without its comments, what are the active lines (as installed, > without any changes) in /usr/lib/systemd/system/nut-driver at .service > (or wherever that service file is located on your system)? > 2. in your upsd.conf (also as installed, without any changes), what is > the commented out STATEPATH you later mention uncommenting? > > > I created /usr/lib/tmpfiles.d/nut-client.conf The owner is > > root:root and permissions are 0644. The contents are > > > > # State file (e.g. upsd to driver) and pidfile location for NUT: > > D /var/run/nut 0770 root nut - - > > X /var/run/nut > > > > I uncommented the STATEPATH line in /etc/ups/upsd.conf. > > > > I created a directory /var/state/ups, set to 777 permissions. > > Changed the STATEPATH line in upsd.conf. No success. > > > > I looked at /usr/lib/systemd/system/nut-driver at .service but could > > not see any changes to be made. The bug report at RedHat mentions > > that a file identified in ExecStartPre does not exist, but I could > > not duplicate. > > > > I tried running this as root: > > > > NUT_STATEPATH=/var/state/ups NUT_ALTPIDPATH=/var/state/ups > > /usr/sbin/usbhid-ups -u nut -g nut -s cyberpower -x port=auto > > > > And it works. I tried it with only one or the other of the two > > environment variables, but did not work. It has to have both. > > > > ==============> > Bill Gee > > > > > > On 11/29/22 17:43, Jim Klimov wrote: > >> As recently noted in the lists, this was tracked > >> down to a Fedora 37 packaging bug: > >> https://bugzilla.redhat.com/show_bug.cgi > >> <https://bugzilla.redhat.com/show_bug.cgi>?id=2127269 > >> > >> > The nut user does not have write permissions at /run. > >> Note that /run is linked as /var/run and the nut user DOES have write > >> permissions there. > >> > >> These two statements do not fit together :) Permissions on symlink > >> do not matter, only the ultimate object's rights do (root-owned > >> /run). The packaging error is that (/var)/run/nut should have been > >> used for drivers and upsd, or /var/state/ups as it should also > >> exist and be accessible to these. For a quick fix you can set > >> Environment=NUT_ALTPIDPATH=/var/state/ups for their systemd units > >> or respective custom drop-in files. > >> > >> Jim > >> > >> On Tue, Nov 29, 2022, 14:06 Bill Gee <bgee at campercaver.net > >> <mailto:bgee at campercaver.net>> wrote: > >> > >> Yesterday I upgraded one of my systems from Fedora 36 to Fedora > >> 37. NUT > >> was upgraded to version 2.8.0. It no longer runs. > >> > >> At first I thought it was because of the XFCE Power Manager program. > >> That program finds the UPS with no problem. I thought maybe the two > >> programs were competing for the UPS port. I shut down the XFCE power > >> manager, but that did not help NUT. > >> > >> Based on the diagnostics given below, I think this is a permissions > >> problem at /run. The nut user does not have write permissions at > /run. > >> Note that /run is linked as /var/run and the nut user DOES have write > >> permissions there. > >> > >> How can I correct this? > >> > >> ======================================> >> [root at mythtv ups]# systemctl status nut-server > >> nut-server.service - Network UPS Tools - power devices information > >> server > >> Loaded: loaded (/usr/lib/systemd/system/nut-server.service; > >> enabled; preset: disabled) > >> Active: active (running) since Tue 2022-11-29 06:18:13 CST; > >> 19min ago > >> Main PID: 11908 (upsd) > >> Tasks: 1 (limit: 9482) > >> Memory: 736.0K > >> CPU: 27ms > >> CGroup: /system.slice/nut-server.service > >> ??11908 /usr/sbin/upsd -F > >> > >> Nov 29 06:18:13 mythtv.billgee.local upsd[11908]: Can't connect to > UPS > >> [cyberpower] (usbhid-ups-cyberpower): No such fi> > >> Nov 29 06:18:13 mythtv.billgee.local nut-server[11908]: Can't > >> connect to > >> UPS [cyberpower] (usbhid-ups-cyberpower): No s> > >> Nov 29 06:18:13 mythtv.billgee.local nut-server[11908]: Running as > >> foreground process, not saving a PID file > >> Nov 29 06:18:13 mythtv.billgee.local upsd[11908]: Running as > foreground > >> process, not saving a PID file > >> Nov 29 06:23:13 mythtv.billgee.local nut-server[11908]: Can't > >> connect to > >> UPS [cyberpower] (usbhid-ups-cyberpower): No such file or directory> > >> Nov 29 06:23:13 mythtv.billgee.local upsd[11908]: Can't connect to > UPS > >> [cyberpower] (usbhid-ups-cyberpower): No such file or directory> > >> > >> [root at mythtv ups]# usbhid-ups -a cyberpower > >> Network UPS Tools - Generic HID driver 0.47 (2.8.0) > >> USB communication driver (libusb 1.0) 0.43 > >> writepid: fopen /var/run/usbhid-ups-cyberpower.pid: Permission denied > >> Using subdriver: CyberPower HID 0.6 > >> cps_adjust_battery_scale: battery readings will be scaled by 2/3 > >> > >> Fatal error: unable to create listener socket > >> > >> bind /var/run/usbhid-ups-cyberpower failed: Permission denied > >> > >> Exiting. > >> > >> [root at mythtv ups]# ll /var/run/usb* > >> ls: cannot access '/var/run/usb*': No such file or directory > >> > >> [root at mythtv ups]# ll -d /var/run > >> lrwxrwxrwx. 1 root root 6 Aug 31 2014 /var/run -> ../run > >> > >> [root at mythtv ups]# ll -d /run > >> drwxr-xr-x 55 root root 1500 Nov 28 08:22 /run > >> > >> [root at mythtv ups]# tail /etc/ups/ups.conf > >> [cyberpower] > >> driver=usbhid-ups > >> desc="CyberPower CP1500" > >> port=auto > >> vendorid=0764 > >> =================================================> >> > >> > >> Thanks! > >> -- ==============> >> Bill Gee > >> > >> _______________________________________________ > >> Nut-upsuser mailing list > >> Nut-upsuser at alioth-lists.debian.net > >> <mailto:Nut-upsuser at alioth-lists.debian.net> > >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > >> < > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser> > >> > > > > _______________________________________________ > > Nut-upsuser mailing list > > Nut-upsuser at alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > > > ----- End message from Bill Gee <bgee at campercaver.net> ----- > > > > -- > Simon Wilson > M: 0400 12 11 16 > > > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20221130/95e9381a/attachment-0001.htm>
Hi Simon --
Yes, I am pretty sure this is the RedHat packaging problem. I sure hope
they get it squared away. I have only one system using nut and that is
because all my other systems have APC battery backup and run apcupsd.
Apcupsd may be old, grey and unmaintained, but it Just Works.
You mention that the STATEPATH line in upsd.conf will override other
settings. It does not appear to be the case for me. The only way I
could get the driver to run was by setting NUT_STATEPATH on the command
line. Perhaps that is an issue with the driver and not nut-server?
In answer to your questions:
1) /usr/lib/systemd/system/nut-driver at .service exists. I have made no
changes to it so far. Here are the contents, unfortunately line-wrapped
by Thunderbird.
===============================[root at mythtv system]# grep -v '^#'
nut-driver at .service
[Unit]
Description=Network UPS Tools - device driver for %I
After=local-fs.target
PartOf=nut-driver.target
[Service]
EnvironmentFile=-/etc/ups/nut.conf
SyslogIdentifier=%N
ExecStartPre=-/usr/bin/systemd-tmpfiles --create
/usr/lib/tmpfiles.d/nut-client.conf
ExecStart=/bin/sh -c 'NUTDEV="`/usr/libexec/nut-driver-enumerator.sh
--get-device-for-service %i`" && [ -n "$NUTDEV" ] || {
echo "FATAL:
Could not find a NUT device section for service unit %i" >&2 ; exit
1 ;
} ; /usr/sbin/upsdrvctl start "$NUTDEV"'
ExecStop=/bin/sh -c 'NUTDEV="`/usr/libexec/nut-driver-enumerator.sh
--get-device-for-service %i`" && [ -n "$NUTDEV" ] || {
echo "FATAL:
Could not find a NUT device section for service unit %i" >&2 ; exit
1 ;
} ; /usr/sbin/upsdrvctl stop "$NUTDEV"'
StartLimitInterval=0
Restart=always
RestartSec=15s
Type=forking
[Install]
WantedBy=nut-driver.target
==================================
2) In /etc/ups/upsd.conf, the original STATEPATH line is
STATEPATH /var/run/nut
Right now the original line is commented and I added another line to
point at /var/state/ups.
3) You only asked two questions, but I sense a third might be important.
Originally the system had /usr/lib/tmpfiles.d/nut-common.conf. I have
modified that file and no longer have the original. I copied that file
to nut-client.conf, and both have the same contents:
======================# State file (e.g. upsd to driver) and pidfile location
for NUT:
D /var/run/nut 0770 root nut - -
X /var/run/nut
=======================
4) And one more unasked question! :-) When I look at the environment
variables on the system, I see this:
=======================[root at mythtv tmpfiles.d]# set | grep -i nut
_=/etc/ups/nut.conf
=======================
Bill Gee
On 11/30/22 01:20, Simon Wilson via Nut-upsuser wrote:> ----- Message from Bill Gee <bgee at campercaver.net> ---------
> ?? Date: Tue, 29 Nov 2022 19:25:19 -0600
> ?? From: Bill Gee <bgee at campercaver.net>
> Subject: Re: [Nut-upsuser] NUT no longer works after 2.7 -> 2.8 upgrade
> ???? To: Jim Klimov <jimklimov+nut at gmail.com>
> ???? Cc: Arnaud Quette via Nut-upsuser
> <nut-upsuser at alioth-lists.debian.net>
>
>
>> I got it to run, but what a mess ...
>>
>> Yes, I am running systemctl daemon-reload and systemctl restart
>> nut-server after each change I make.
>>
>
> Hi Bill,
>
> Drivers and upsd share defaults (see 'man nutupsdrv').
>
> Your original error message ("writepid: fopen
> /var/run/usbhid-ups-cyberpower.pid: Permission denied") would seem to
> indicate, same as the Red Hat bug, that your driver's default pid path
> is /var/run.
>
> The driver by default uses STATEPATH (which can be over-ridden in
> upsd.conf) to store pid files. The driver .service file is supposed to
> make sure that path exists by running the ExecStartPre line, which gets
> its instructions from the referenced ".conf" file from
> /usr/lib/tmpfiles.d. The .service file then calls 'upsdrvctl start'
to
> start your usbhid-ups driver, as defined in ups.conf. Those all need to
> align...
>
> 2 x questions:
>
> 1. Without its comments, what are the active lines (as installed,
> without any changes) in /usr/lib/systemd/system/nut-driver at .service (or
> wherever that service file is located on your system)?
> 2. in your upsd.conf (also as installed, without any changes), what is
> the commented out STATEPATH you later mention uncommenting?
>
>> I created /usr/lib/tmpfiles.d/nut-client.conf?? The owner is root:root
>> and permissions are 0644.? The contents are
>>
>> # State file (e.g. upsd to driver) and pidfile location for NUT:
>> D /var/run/nut 0770 root nut - -
>> X /var/run/nut
>>
>> I uncommented the STATEPATH line in /etc/ups/upsd.conf.
>>
>> I created a directory /var/state/ups, set to 777 permissions.? Changed
>> the STATEPATH line in upsd.conf.? No success.
>>
>> I looked at /usr/lib/systemd/system/nut-driver at .service but could
not
>> see any changes to be made.? The bug report at RedHat mentions that a
>> file identified in ExecStartPre does not exist, but I could not
>> duplicate.
>>
>> I tried running this as root:
>>
>> NUT_STATEPATH=/var/state/ups NUT_ALTPIDPATH=/var/state/ups
>> /usr/sbin/usbhid-ups -u nut -g nut -s cyberpower -x port=auto
>>
>> And it works.? I tried it with only one or the other of the two
>> environment variables, but did not work.? It has to have both.
>>
>> ==============>> Bill Gee
>>