[Nut-upsuser] NUT stopped working after an upgrade

[Bill Gee]

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- 
> verbosity <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/ 
> nut%E2%80%90driver%E2%80%90enumerator-(NDE) <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>> 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>> 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>
>      >> 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>
> 
> 
>     _______________________________________________
>     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>
>