[Nut-upsuser] NUT stopped working after an upgrade

Bill Gee bgee at campercaver.net
Wed Nov 13 12:55:36 GMT 2024


Hmmm ....  It is not a big deal since everything else is running fine.

Here is what rpm reports about the version of NUT that I have:

================
[root at mythtv ~]# rpm -qi nut
Name        : nut
Version     : 2.8.2
Release     : 1.fc40
Architecture: x86_64
Install Date: Sat 04 May 2024 04:03:09 PM CDT
Group       : Unspecified
Size        : 12792564
License     : GPL-2.0-or-later AND GPL-3.0-or-later
Signature   : RSA/SHA256, Mon 15 Apr 2024 10:15:03 AM CDT, Key ID 
0727707ea15b79cc
Source RPM  : nut-2.8.2-1.fc40.src.rpm
Build Date  : Wed 03 Apr 2024 05:50:48 AM CDT
===============

I am going to upgrade this system to Fedora 41 today.  When that is done 
and back to stable, I will report back.

===============
Bill Gee

On 11/10/24 16:11, Jim Klimov wrote:
> Great!
> 
> Regarding libusb and nut-scanner, I think the *.so (exact) symlinks are 
> part of *-devel packages.
> 
> This was solved in NUT recently (maybe after 2.8.2 release already) by 
> detecting and stashing the basename of realpath of the library present 
> during build, so the exact *.so.X.Y.Z would be also tried.
> 
> Also, nut-scanner now (in 2.8.2 IIRC) should not suggest the volatile 
> bus/busport/device numbers by default.
> 
> Jim
> 
> 
> On Sun, Nov 10, 2024 at 7:42 PM Bill Gee <bgee at campercaver.net 
> <mailto:bgee at campercaver.net>> wrote:
> 
>     Thanks for the tip, Jim.  I just figured out what is going on.  The
>     system is now working.  ==> This one is on me.  <==
> 
>     The root cause was the specification of the bus number in the ups.conf
>     file.  Here is what it looks like now:
> 
>     ============
>     [cyberpower]
>               driver = "usbhid-ups"
>               port = "auto"
>               vendorid = "0764"
>               productid = "0501"
>               product = "UPS CP1000AVRLCD"
>               vendor = "CPS"
>     #        bus = "006"
>     ================
> 
>     It had been running with the bus= line uncommented.  I don't remember
>     why that was needed, but sometime in the dark past I added it.
>     Commenting it out and restarting both nut-server and nut-monitor
>     brought
>     everything to life.
> 
>     Charles' reply below had the seed of the answer when he mentioned how
>     the UPS will appear in the /dev/ directory.  I had been looking at
>     every
>     other file except ups.conf and so the bus number was not top of mind.
> 
>     The documentation linked by Jim says that the DEBUG_MIN setting is
>     supported in all of the .conf files.  I changed it in upsd.conf, then
>     went looking in other files.  That is when I noticed the bus number in
>     ups.conf.  A very big DOH slap was promptly administered!
> 
>     I think the messages about permissions were the result of not having
>     bus
>     number 6 at all.  There was no /dev device to connect to and that was
>     interpreted as lack of permissions.
> 
>     As for the messages about missing libusb ...  I am still puzzled over
>     that.  nut-scanner still complains about it.  It is hard to argue with
>     success, though, so that question is now sort of moot. "upsc
>     cyberpower"
>     returns valid information and nut-monitor is no longer attempting
>     restart once per minute.
> 
>     Thanks everyone for the help.
> 
>     ===============
>     Bill Gee
> 
>     On 11/10/24 11:45, Jim Klimov wrote:
>      > Can you try starting the driver with higher debug verbosity to
>     see more
>      > details, e.g. add `debug_min = 6` to the `ups.conf` section, or
>     stop the
>      > auto-starting driver attempts and run the driver program with CLI
>     options?
>      >
>      > * https://github.com/networkupstools/nut/wiki/Changing-NUT-
>     daemon-debug- <https://github.com/networkupstools/nut/wiki/Changing-
>     NUT-daemon-debug->
>      > verbosity <https://github.com/networkupstools/nut/wiki/Changing-
>     NUT- <https://github.com/networkupstools/nut/wiki/Changing-NUT->
>      > daemon-debug-verbosity>
>      >
>      > With `upsdrvctl` driven attempts, you may also be in conflict with a
>      > generated `nut-driver at cyberpower.service` instance (although this
>     is not
>      > the only problem, as the unit seems to fail starting for you
>     too), more
>      > details about such units at:
>      >
>      > * https://github.com/networkupstools/nut/wiki/ <https://
>     github.com/networkupstools/nut/wiki/>
>      > nut%E2%80%90driver%E2%80%90enumerator-(NDE) <https://github.com/
>     <https://github.com/>
>      > networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)>
>      >
>      > Jim
>      >
>      >
>      > On Sun, Nov 10, 2024 at 4:47 PM Bill Gee <bgee at campercaver.net
>     <mailto:bgee at campercaver.net>
>      > <mailto:bgee at campercaver.net <mailto:bgee at campercaver.net>>> wrote:
>      >
>      >     I also am wondering if the message about libusb driver
>     missing might be
>      >     the real problem.
>      >
>      >     Checking my system, I see this:
>      >
>      >     ===================
>      >     [root at mythtv dev]# ll /dev/bus/usb/001
>      >     total 0
>      >     crw-rw-r--+ 1 root root    189, 0 Nov  9 08:21 001
>      >     crw-rw-r--+ 1 root root    189, 1 Nov  9 08:21 002
>      >     crw-rw-r--+ 1 root root    189, 2 Nov  9 08:21 003
>      >     crw-rw-r--+ 1 root dialout 189, 3 Nov 10 09:43 004
>      >     ==================
>      >
>      >     That looks to me like the udev rule worked.
>      >
>      >     ===============
>      >     Bill Gee
>      >
>      >     On 11/10/24 08:38, Charles Lepple via Nut-upsuser wrote:
>      >      > On Nov 9, 2024, at 8:09 PM, Tim Dawson
>     <tadawson at tpcsvc.com <mailto:tadawson at tpcsvc.com>
>      >     <mailto:tadawson at tpcsvc.com <mailto:tadawson at tpcsvc.com>>> wrote:
>      >      >>
>      >      >> Check /dev/hidraw6, as noted in your dmesg output (and
>     any other
>      >     *hid*
>      >      >> devices under /dev). User nut has almost zero privs to
>     devices
>      >     unless
>      >      >> a udev rule changes the perms on the dev for nut . . .
>      >      >
>      >      > I admit I am not fully tracking the latest NUT
>     developments, but
>      >     I don't
>      >      > think the current drivers use /dev/hidraw*, especially
>     when the
>      >     drivers
>      >      > mention libusb. (Once the libusb-based drivers start, they
>     should
>      >     detach
>      >      > the kernel's HID drivers such that the corresponding /dev/
>     hidraw*
>      >     device
>      >      > disappears.)
>      >      >
>      >      > You are correct that the udev rules need to change
>     permissions on
>      >     one of
>      >      > the UPS /dev nodes, though.
>      >      >
>      >      >  From Bill's lsusb output:
>      >      >
>      >      > [root at mythtv ups]# lsusb
>      >      > ...
>      >      > Bus 001 Device 004: ID 0764:0501 Cyber Power System, Inc.
>     CP1500
>      >     AVR UPS
>      >      >
>      >      > The libusb path for this UPS would typically be /dev/bus/
>     usb/001/004
>      >      >
>      >      > --
>      >      > Charles Lepple
>      >      > clepple at gmail
>      >      >
>      >      >
>      >      >> _______________________________________________
>      >      >> Nut-upsuser mailing list
>      >      >> Nut-upsuser at alioth-lists.debian.net <mailto:Nut-
>     upsuser at alioth-lists.debian.net> <mailto:Nut-upsuser at alioth-
>     <mailto:Nut-upsuser at alioth->
>      > lists.debian.net <http://lists.debian.net>>
>      >      >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
>     nut- <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut->
>      >     upsuser <https://alioth-lists.debian.net/cgi-bin/mailman/
>     listinfo/ <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/>
>      >     nut-upsuser>
>      >      >
>      >      >
>      >      > _______________________________________________
>      >      > Nut-upsuser mailing list
>      >      > Nut-upsuser at alioth-lists.debian.net <mailto:Nut-
>     upsuser at alioth-lists.debian.net> <mailto:Nut-upsuser at alioth-
>     <mailto:Nut-upsuser at alioth->
>      > lists.debian.net <http://lists.debian.net>>
>      >      > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
>     nut- <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut->
>      >     upsuser <https://alioth-lists.debian.net/cgi-bin/mailman/
>     listinfo/ <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/>
>      >     nut-upsuser>
>      >
>      >
>      >     _______________________________________________
>      >     Nut-upsuser mailing list
>      > Nut-upsuser at alioth-lists.debian.net <mailto:Nut-upsuser at alioth-
>     lists.debian.net> <mailto:Nut-upsuser at alioth- <mailto:Nut-
>     upsuser at alioth->
>      > lists.debian.net <http://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>
>      >     <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 <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>
> 




More information about the Nut-upsuser mailing list