search

networkupstools / nut

The Network UPS Tools repository. UPS management protocol Informational RFC 9271 published by IETF at https://www.rfc-editor.org/info/rfc9271 Please star NUT on GitHub, this helps with sponsorships!
https://networkupstools.org/
Other
1.99k stars 349 forks source link

Network UPS Tools (NUT) "Can't connect to UPS" - Tripp Lite SMART500RT1U #1851

Open Jsalas424 opened 1 year ago

Jsalas424 commented 1 year ago

I'm running a bare bones NUT configuration to monitor a single UPS that is stated to be compatible on the website - I can't get it to work.

This is a Tripp Lite SMART500RT1U connected via USB cable.

My syslog says it's there:

Feb 14 16:54:36 Server kernel: usb 2-6: new low-speed USB device number 4 using xhci_hcd
Feb 14 16:54:36 Server kernel: usb 2-6: New USB device found, idVendor=09ae, idProduct=0001, bcdDevice= 0.0a
Feb 14 16:54:36 Server kernel: usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb 14 16:54:36 Server kernel: usb 2-6: Product: TRIPP LITE SMART500RT1U 
Feb 14 16:54:36 Server kernel: usb 2-6: Manufacturer: Tripp Lite 
Feb 14 16:54:36 Server kernel: hid-generic 0003:09AE:0001.0003: hiddev0,hidraw2: USB HID v1.10 Device [Tripp Lite  TRIPP LITE SMART500RT1U ] on usb-0000:00:14.0-6/input0

root@Server:~# lsusb
...
Bus 002 Device 004: ID 09ae:0001 Tripp Lite TRIPP LITE SMART500RT1U

Here's my nut config:

/etc/nut/ups.conf

[UPS]
        driver = tripplite_usb
        port = auto
        vendorid = 09ae
        productid = 0001

/etc/nut/nut.conf

MODE=standalone

:(

root@Server:~# systemctl restart nut-server
root@Server:~# systemctl status nut-server
● nut-server.service - Network UPS Tools - power devices information server
     Loaded: loaded (/lib/systemd/system/nut-server.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-02-14 17:11:38 EST; 3s ago
    Process: 1417620 ExecStart=/sbin/upsd (code=exited, status=0/SUCCESS)
   Main PID: 1417621 (upsd)
      Tasks: 1 (limit: 38378)
     Memory: 680.0K
        CPU: 4ms
     CGroup: /system.slice/nut-server.service
             └─1417621 /lib/nut/upsd

Feb 14 17:11:38 Server systemd[1]: Starting Network UPS Tools - power devices information server...
Feb 14 17:11:38 Server upsd[1417620]: fopen /run/nut/upsd.pid: No such file or directory
Feb 14 17:11:38 Server upsd[1417620]: listening on 127.0.0.1 port 3493
Feb 14 17:11:38 Server upsd[1417620]: listening on ::1 port 3493
Feb 14 17:11:38 Server upsd[1417620]: listening on 127.0.0.1 port 3493
Feb 14 17:11:38 Server upsd[1417620]: listening on ::1 port 3493
Feb 14 17:11:38 Server upsd[1417620]: Can't connect to UPS [UPS] (tripplite_usb-UPS): No such file >
Feb 14 17:11:38 Server upsd[1417620]: Can't connect to UPS [UPS] (tripplite_usb-UPS): No such file >
Feb 14 17:11:38 Server upsd[1417621]: Startup successful
Feb 14 17:11:38 Server systemd[1]: Started Network UPS Tools - power devices information server.

NUT v2.7.4-13

jimklimov commented 1 year ago

Can't see from the posted logs - did you start the nut-driver for the device? did that fail?

FWIW might also try usbhid-ups in case the device (also?) talks the standard protocol...

Jsalas424 commented 1 year ago

@jimklimov Well this seems like a stupid question, but how do I start the driver? I thought that using systemctl to start nut-server was all I needed to do after configuring. It's been a while since I configured NUT.

jimklimov commented 1 year ago

Depends on distribution you use and if e.g. "mode" is a concept there. Also on NUT base version.

2.7.4 and some before it had a common systemctl start nut-driver for all devices as one unit.

2.8.0/master have a nut-driver-enumerator script and units to generate a nut-driver@<NAME>.service instances for each device separately.

Generally the 3-layer architecture is in play, so there's also the nut-monitor to run in most cases.

Jsalas424 commented 1 year ago

This is NUT v2.7.4-13 and I'm on Proxmox (fancy debian). I have NUT running on with other UPS' on these machines as well.

Failed with the usbhid-ups driver

root@Server:~# journalctl -xe
Feb 16 07:20:07 Server upsdrvctl[3770664]: Network UPS Tools - UPS driver controller 2.7.4
Feb 16 07:20:07 Server upsdrvctl[3770666]: Can't open /run/nut/usbhid-ups-auto.pid: No such file or>
Feb 16 07:20:07 Server upsdrvctl[3770666]: Network UPS Tools - UPS driver controller 2.7.4
Feb 16 07:20:07 Server systemd[1]: nut-driver.service: Control process exited, code=exited, status=>
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ An ExecStop= process belonging to unit nut-driver.service has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 1.
Feb 16 07:20:07 Server systemd[1]: nut-driver.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ The unit nut-driver.service has entered the 'failed' state with result 'exit-code'.
Feb 16 07:20:07 Server systemd[1]: Failed to start Network UPS Tools - power device driver controll>
░░ Subject: A start job for unit nut-driver.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ A start job for unit nut-driver.service has finished with a failure.
░░ 
░░ The job identifier is 822887 and the job result is failed.

And with the tripplite_usb driver:

Feb 16 07:22:18 Server upsdrvctl[3772973]: Network UPS Tools - UPS driver controller 2.7.4
Feb 16 07:22:18 Server upsdrvctl[3772975]: Can't open /run/nut/tripplite_usb-auto.pid: No such file>
Feb 16 07:22:18 Server upsdrvctl[3772975]: Network UPS Tools - UPS driver controller 2.7.4
Feb 16 07:22:18 Server systemd[1]: nut-driver.service: Control process exited, code=exited, status=>
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ An ExecStop= process belonging to unit nut-driver.service has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 1.
Feb 16 07:22:18 Server systemd[1]: nut-driver.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ The unit nut-driver.service has entered the 'failed' state with result 'exit-code'.
Feb 16 07:22:18 Server systemd[1]: Failed to start Network UPS Tools - power device driver controll>
░░ Subject: A start job for unit nut-driver.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ A start job for unit nut-driver.service has finished with a failure.
░░ 
░░ The job identifier is 822948 and the job result is failed.
jimklimov commented 1 year ago

Can you try to manually start it in command-line with boosted debug level? e.g. try a data dump with

/lib/nut/usbhid-ups -a UPS -u root -DDDDDD -d1

to see what it complains about when trying to match the device etc.

Maybe also cross-check with a custom build from master branch (see wiki for "inplace" mode as a quick shot)

Jsalas424 commented 1 year ago

@jimklimov thanks for that, here's the output:

Adapted your code to use the tripplite_usb driver

root@Server:~# /lib/nut/tripplite_usb -a UPS -u root -DDDDDD -d1
Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.29 (2.7.4)
Warning: This is an experimental driver.
Some features may not function correctly.

/lib/nut/tripplite_usb: invalid option -- 'd'
   0.000000     Error: unknown option -?. Try -h for help.

Next, I attempted with the usbhid-ups driver and got a Fatal error:

root@Server:~# /lib/nut/usbhid-ups -a UPS -u root -DDDDDD -d1
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33

Fatal error: 'maxretry' is not a valid variable name for this driver.

Look in the man page or call this driver with -h for a list of
valid variable names and flags.

Okay, so just remove that variable and try again:

root@Server:~# /lib/nut/usbhid-ups -a UPS -u root -DDDDDD -d1
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
/lib/nut/usbhid-ups: invalid option -- 'd'
   0.000000     Error: unknown option -?. Try -h for help.

Well that's the same error for both drivers. Not sure what that "invalid option -- 'd'" thing means.

Okay so tried without the -d1 flag and got this debug data:

root@Server:~# /lib/nut/tripplite_usb -a UPS -u root -DDDDDD 
Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.29 (2.7.4)
Warning: This is an experimental driver.
Some features may not function correctly.

   0.000000     debug level is '6'
   0.163725     Checking device (8087/8000) (003/002)
   0.231885     - VendorID: 8087
   0.231900     - ProductID: 8000
   0.231902     - Manufacturer: unknown
   0.231906     - Product: unknown
   0.231920     - Serial Number: unknown
   0.231923     - Bus: 003
   0.231926     - Device release number: 0004
   0.231935     Trying to match device
   0.231940     Device does not match - skipping
   0.231955     Checking device (1D6B/0002) (003/001)
   0.232131     - VendorID: 1d6b
   0.232137     - ProductID: 0002
   0.232141     - Manufacturer: Linux 5.15.74-1-pve ehci_hcd
   0.232145     - Product: EHCI Host Controller
   0.232149     - Serial Number: 0000:00:1d.0
   0.232154     - Bus: 003
   0.232158     - Device release number: 0515
   0.232162     Trying to match device
   0.232167     Device does not match - skipping
   0.232176     Checking device (1D6B/0003) (004/001)
   0.258749     - VendorID: 1d6b
   0.258764     - ProductID: 0003
   0.258769     - Manufacturer: Linux 5.15.74-1-pve xhci-hcd
   0.258773     - Product: xHCI Host Controller
   0.258778     - Serial Number: 0000:00:14.0
   0.258787     - Bus: 004
   0.258792     - Device release number: 0515
   0.258796     Trying to match device
   0.258802     Device does not match - skipping
   0.258905     Checking device (09AE/0001) (002/004)
   0.262509     - VendorID: 09ae
   0.262516     - ProductID: 0001
   0.262518     - Manufacturer: Tripp Lite 
   0.262521     - Product: TRIPP LITE SMART500RT1U 
   0.262524     - Serial Number: unknown
   0.262526     - Bus: 002
   0.262530     - Device release number: 000a
   0.262533     Trying to match device
   0.262536     Device matches
   0.262550     nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0)
   0.262554     Detected a UPS: Tripp Lite /TRIPP LITE SMART500RT1U 
   0.262561     send_to_all: SETINFO ups.vendorid "09ae"
   0.262565     send_to_all: SETINFO ups.productid "0001"
   0.262570     send_to_all: SETINFO device.type "ups"
   0.262574     send_to_all: SETINFO driver.version "2.7.4"
   0.262579     send_to_all: SETINFO driver.version.internal "0.29"
   0.262583     send_to_all: SETINFO driver.name "tripplite_usb"
   0.262587     send_cmd(msg_len=2, type='
   0.262591     send_cmd: sending  3a 00 ff 0d 00 00 00 00 '........'
   0.262596     send_cmd send_try 1
   0.370531     send_cmd: received 00 30 05 58 58 58 58 0d '.0.XXXX.' (OK)
   0.370566     send_cmd: send_try = 1, recv_try = 1

   0.370569     Using binary SMART protocol (3005)
   0.370579     send_to_all: SETINFO ups.firmware.aux "protocol 3005"
   0.370596     send_cmd(msg_len=3, type='W')
   0.370600     send_cmd: sending  3a 57 00 a8 0d 00 00 00 '.W......'
   0.370604     send_cmd send_try 1
   0.474503     send_cmd: received 57 00 0d 00 00 00 00 00 'W.......' (OK)
   0.474517     send_cmd: send_try = 1, recv_try = 1

   0.474520     send_cmd(msg_len=2, type='S')
   0.474523     send_cmd: sending  3a 53 ac 0d 00 00 00 00 '.S......'
   0.474526     send_cmd send_try 1
   0.578479     send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
   0.578496     send_cmd: send_try = 1, recv_try = 1

   0.578504     send_to_all: SETINFO ups.mfr "Tripp Lite"
   0.578507     send_cmd(msg_len=2, type='P')
   0.578510     send_cmd: sending  3a 50 af 0d 00 00 00 00 '.P......'
   0.578512     send_cmd send_try 1
   0.682483     send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
   0.682499     send_cmd: send_try = 1, recv_try = 1

   0.682507     send_to_all: SETINFO ups.model "TRIPP LITE SMART500RT1U"
   0.682511     send_to_all: SETINFO ups.power.nominal "500"
   0.682515     send_cmd(msg_len=2, type='F')
   0.682520     send_cmd: sending  3a 46 b9 0d 00 00 00 00 '.F......'
   0.682523     send_cmd send_try 1
   0.786595     send_cmd: received 46 32 39 41 46 20 42 0d 'F29AF.B.' (OK)
   0.786629     send_cmd: send_try = 1, recv_try = 1

   0.786643     send_to_all: SETINFO ups.firmware "F29AF.B"
   0.786653     send_cmd(msg_len=2, type='V')
   0.786660     send_cmd: sending  3a 56 a9 0d 00 00 00 00 '.V......'
   0.786664     send_cmd send_try 1
   0.890489     send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
   0.890503     send_cmd: send_try = 1, recv_try = 1

   0.890508     Switchable load banks: 1
   0.890512     send_cmd(msg_len=2, type='V')
   0.890516     send_cmd: sending  3a 56 a9 0d 00 00 00 00 '.V......'
   0.890519     send_cmd send_try 1
   0.994495     send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
   0.994510     send_cmd: send_try = 1, recv_try = 1

   0.994519     send_to_all: SETINFO ups.debug.V "02 00 0c 01 58 58 0d '....XX.'"
   0.994523     send_to_all: SETINFO outlet.1.id "1"
   0.994527     send_to_all: SETINFO outlet.1.desc "Load 1"
   0.994532     send_to_all: SETINFO outlet.1.switchable "1"
   0.994545     send_to_all: SETINFO outlet.1.switch "1"
   0.994551     send_to_all: SETFLAGS outlet.1.switch RW STRING
   0.994554     send_to_all: SETAUX outlet.1.switch 3
   0.994558     send_to_all: SETINFO outlet.2.id "2"
   0.994562     send_to_all: SETINFO outlet.2.desc "Load 2"
   0.994566     send_to_all: SETINFO outlet.2.switchable "0"
   0.994570     send_to_all: ADDCMD load.on
   0.994573     send_to_all: ADDCMD load.off
   0.994576     send_cmd(msg_len=2, type='U')
   0.994581     send_cmd: sending  3a 55 aa 0d 00 00 00 00 '.U......'
   0.994584     send_cmd send_try 1
   1.098496     send_cmd: received 55 ff ff 0d 00 00 00 00 'U.......' (OK)
   1.098514     send_cmd: send_try = 1, recv_try = 1

   1.098526     send_to_all: SETINFO ups.id "65535"
   1.098543     send_to_all: SETFLAGS ups.id RW STRING
   1.098559     send_to_all: SETAUX ups.id 5
   1.098563     Unit ID: 65535
   1.098569     send_to_all: SETINFO input.voltage.nominal "120"
   1.098574     send_to_all: SETINFO battery.voltage.nominal "12"
   1.098580     send_to_all: SETINFO ups.debug.load_banks "1"
   1.098586     send_to_all: SETINFO ups.delay.shutdown "64"
   1.098600     send_to_all: SETFLAGS ups.delay.shutdown RW STRING
   1.098622     send_to_all: SETAUX ups.delay.shutdown 3
   1.098628     send_to_all: ADDCMD test.battery.start
   1.098637     send_to_all: ADDCMD reset.input.minmax
   1.098641     send_to_all: ADDCMD shutdown.return
Attached to Tripp Lite TRIPP LITE SMART500RT1U
   1.098659     send_cmd(msg_len=2, type='S')
   1.098665     send_cmd: sending  3a 53 ac 0d 00 00 00 00 '.S......'
   1.098669     send_cmd send_try 1
   1.202567     send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
   1.202583     send_cmd: send_try = 1, recv_try = 1

   1.202593     send_to_all: SETINFO ups.debug.S "01 04 00 00 64 00 0d '....d..'"
   1.202598     send_to_all: SETINFO ups.status "OL"
   1.202602     send_cmd(msg_len=2, type='D')
   1.202625     send_cmd: sending  3a 44 bb 0d 00 00 00 00 '.D......'
   1.202630     send_cmd send_try 1
   1.306538     send_cmd: received 44 00 74 00 89 0d 00 00 'D.t.....' (OK)
   1.306554     send_cmd: send_try = 1, recv_try = 1

   1.306564     send_to_all: SETINFO input.voltage "116"
   1.306571     send_to_all: SETINFO battery.voltage "13.70"
   1.306577     send_cmd(msg_len=2, type='M')
   1.306585     send_cmd: sending  3a 4d b2 0d 00 00 00 00 '.M......'
   1.306591     send_cmd send_try 1
   1.410488     send_cmd: received 4d 00 70 00 7b 0d 00 00 'M.p.....' (OK)
   1.410505     send_cmd: send_try = 1, recv_try = 1

   1.410517     send_to_all: SETINFO input.voltage.minimum "112"
   1.410521     send_to_all: SETINFO input.voltage.maximum "123"
   1.410524     send_cmd(msg_len=2, type='T')
   1.410527     send_cmd: sending  3a 54 ab 0d 00 00 00 00 '.T......'
   1.410530     send_cmd send_try 1
   1.514510     send_cmd: received 54 1f 00 02 57 01 58 0d 'T...W.X.' (OK)
   1.514531     send_cmd: send_try = 1, recv_try = 1

   1.514551     send_to_all: SETINFO ups.debug.T "1f 00 02 57 01 58 0d '...W.X.'"
   1.514557     send_to_all: SETINFO ups.temperature "0"
   1.514570     send_cmd(msg_len=2, type='L')
   1.514574     send_cmd: sending  3a 4c b3 0d 00 00 00 00 '.L......'
   1.514577     send_cmd send_try 1
Jsalas424 commented 1 year ago

Reattempted with the other driver:

root@Server:~# /lib/nut/usbhid-ups -a UPS -u root -DDDDDD

....

  0.261067     Trying to match device
   0.261073     This Tripp Lite device (09ae/0001) is not supported by usbhid-ups.
Please use the tripplite_usb driver instead.

   0.261080     Device does not match - skipping
   0.261089     Checking device (09EB/0131) (002/003)
   0.262981     - VendorID: 09eb
   0.262985     - ProductID: 0131
   0.262988     - Manufacturer: Generic
   0.262992     - Product: USB
   0.262996     - Serial Number: unknown
   0.263001     - Bus: 002
   0.263006     - Device release number: 0110
jimklimov commented 1 year ago

The -d1 option is for dump mode (collect data in one cycle, print it and exit the driver) which is less sensitive to permissions (no PID file needed) etc. Seems your packaged NUT version predates that :\

jimklimov commented 1 year ago

The tripplite_usb apparently sees the device with meaningful data, so the problem boils down to getting the driver started in normal conditions. That would likely be about permissions - e.g. would it still see the data if started without -u root option?

If not, check if the NUT package provided udev.rules file includes the VID:PID pair for this device so its devfs node would be accessible to nut runtime user? Alternately, the user = root can be specified in ups.conf section (but not recommended if easy to avoid).

rknichols commented 1 year ago

I'm having the same problem in Rocky Linux 8 and also in Fedora 37. Those distros do provide 62-nut-usbups.rules file containing a matching idVendor and idProduct pair for each of my UPSs:

ATTR{idVendor}=="0764", ATTR{idProduct}=="0501", MODE="664", GROUP="dialout"
ATTR{idVendor}=="0764", ATTR{idProduct}=="0601", MODE="664", GROUP="dialout"

and the appropriate devices are created in /dev:

crw-rw-r--. 1 root dialout 189, 2 2023-02-19 14:11:41 /dev/bus/usb/001/003
crw-rw-r--. 1 root dialout 189, 2 2023-02-19 14:11:41 /dev/bus/usb/001/004

Group "dialout" looks strange, but user "nut" is indeed a member of the "dialout" group.

If I manually run usbdrvctl with either "-u root" or "-u nut", it will find the devices successfully. It's not apparent to me how to get that option passed in the course of a normal systemd startup.

noloader commented 1 year ago

Group "dialout" looks strange, but user "nut" is indeed a member of the "dialout" group.

dialout is for modems. I suppose dialout is Ok if the program and device are communicating with AT commands, but it would not be my first choice.

I thought a different group was used for UPS, like user ups and group ups. How was the package configured? Did it use something like --with-user=ups --with-group=ups?

jimklimov commented 1 year ago

My guess is that with NUT's history with serial-port UPSes (same media as modems), many distros went with allowing NUT processes to look at all serial ports in search of a device. Then it persisted with udev and similar tools to dynamically assign permissions to filesystem nodes of certain connections.

A packaged NUT should run as nut user by default. There are also RUN_AS_USER or user=... keywords for some of the config files involved, see docs including comments in sample config files.

A custom built NUT without configure --with-user=... options will likely run as nobody. May say so in the report after config script runs.

rknichols commented 1 year ago

I'm not the builder, but I downloaded the .src.rpm file, and the SPEC file contains     --with-group=dialout     --with-user=%(name) Looks like "dialout" was to fix https://bugzilla.redhat.com/show_bug.cgi?id=494020,     "nut do not provide any mechanism to grant access to /dev/ttyS0"

rknichols commented 1 year ago

The RUN_AS_USER setting is in upsmon.conf, and appears to affect only the monitor program, not the upsdrvctl program, which is the one having a problem. I tried changing that setting -- no effect.

jimklimov commented 1 year ago

For drivers there's ups.conf with its optional user=nut (or root) that you can add in a device section.

rknichols commented 1 year ago

I tried with both "user=nut" and "user=root", both in the global part of ups.conf and in the individual sections for my devices. There was no change.

noloader commented 1 year ago

That "user=root" fails makes me suspect SELinux. ls -AlZ will show SELinux context on a filesystem object. Unfortunately, I don't know enough about SELinux to say what the policy should look like.

Maybe you can rule-out SELinux by editing /etc/selinux/config, and change from SELINUX=enforcing to SELINUX=permissive or SELINUX=disabled. Permissive should report policy violations without stopping the action or behavior.

Reboot after the change.

rknichols commented 1 year ago

No SELinux AVCs were reported, and I've also tried this in permissive mode. Again, no difference, and note that the error message does not mention permissions:

upsd[138823]: Can't connect to UPS [Cyber-2] (usbhid-ups-Cyber-2): No such file or direcory upsd[138823]: Can't connect to UPS [Cyber-1] (usbhid-ups-Cyber-1): No such file or direcory

Those "usbhid-ups-Cyber-[12]" devices are supposed appear as sockets in /run/nut

The only time I see SELinux AVCs is after I run "usbdrvctl start" manually (as root). That finds the UPSs successfully, but the socket that gets created in /run/nut inherits the SELinux type "unconfined_t" from the calling root shell, and a process running as nut_upsd_t would not be allowed to connect to that in enforcing mode.

jimklimov commented 1 year ago

Wait, those latter messages from data server upsd say it can't talk to the driver(s). Where are messages about failing to start the drivers, e.g. nut-driver unit?

rknichols commented 1 year ago

I put a wrapper around every nut executable in /usr/sbin to record its arguments and privileges. Here is the output after "systemctl start nut.target" (running in Fedora 37 with just one UPS device configured, permissive mode, "user=root" in ups.conf):

08:26:31 /usr/sbin/upsd -F
    Permissive uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:nut_upsd_t:s0
08:26:31 /usr/sbin/upsmon -F
    Permissive uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:nut_upsmon_t:s0

I presume there is something missing???

rknichols commented 1 year ago

It doesn't appear to me that anything tries to start nut-driver.service. Here is the unit file for nut.target:

[Unit]
Description=Network UPS Tools - target for power device drivers, data server and monitoring client (if enabled) on this system
After=local-fs.target nut-driver.target nut-server.service nut-monitor.service
Wants=local-fs.target nut-driver.target nut-server.service nut-monitor.service
# network.target

[Install]
WantedBy=multi-user.target

and the unit file for nut-driver.target:

[Unit]
Description=Network UPS Tools - target for power device drivers on this system
After=local-fs.target
# network.target
PartOf=nut.target

[Install]
WantedBy=nut.target

I'm a "noobe" with systemd, but that second unit file doesn't appear to do anything.

jimklimov commented 1 year ago

Targets are umbrellas for service mgmt. What does their nut-driver.service look like (or nut-driver@.service if NUT 2.8.0+)?

Earlier posts implied 2.7.4, but Fedora 37 had issue reports about broken packaging of 2.8.0 :)

rknichols commented 1 year ago

It seems I am stuck with broken 2.8.0 packages, 2.8.0-3 in Rocky 8, and 2.8.0-8 in Fedora 37.

nut-driver.target seems to be an umbrella with nothing under it. For example, nut.target includes Wants=local-fs.target nut-driver.target nut-server.service nut-monitor.service but nut-driver.target doesn't seem to "Want" anything.

I've attached the nut-driver@.service file (with a .txt extension added so that bugzilla will accept it). It looks fine, but I can't find anything that instantiates it. nut-driver@.service.txt

jimklimov commented 1 year ago

For most settings describing relations between units, systemd (and SMF) allow either of them to speak up.

In case of NUT 2.8.0+, an unspecified amount of nut-driver@UPSNAME.service instances each say they are WantedBy=nut-driver.target which is more viable than listing them in a pre-packaged file :) Such instances should be generated by nut-driver-enumerator (script that you may run, and service calling it).

The breakage in Fedora (not sure if fixed now) involved typos in systemd-tmpfiles config, IIRC, so working directories were not made/owned well for NUT daemons.

rknichols commented 1 year ago

Finally, it's working.

Now, If you would kindly indicate which document I should have read to tell me that I specifically need to enable "nut-driver-enumerator.service" in addition to "nut.target", I would appreciate it. The supplied "nut.target" does "Want" nut-driver.target, but as noted above, there is no further "Want" and nothing happens. The nut.target unit doesn't "Want" or "Exec" anything at all.

If I do run "systemctl enable nut-driver-enumerator.service", then a link in /etc/systemd/nut.target.wants is created, and the enumerator starts as expected whenever nut.target is started. Without that manual step, the enumerator simply does not get run.

None of the documents in /usr/share/doc/nut/docs suggest that anything needs to be done to make the enumerator run.

jimklimov commented 1 year ago

Thanks for the report, probably that's a flaw on Fedora packaging side, for their bug tracker (at least the practical part, PR to improve the docs visible to user after installation to at least mention this well is welcome here) :\

Just one note, "target" units by systemd design do not Exec anything, don't have a syntactic section for that. They just glue run-time mass-enablement requests (or completed start-up milestones) together.

rknichols commented 1 year ago

Just one note, "target" units by systemd design do not Exec anything, don't have a syntactic section for that. They just glue run-time mass-enablement requests (or completed start-up milestones) together.

That being true, they do have "Wants", either in the unit file itself or dropped into a /etc/systemd/system/{name}.target.wants/ directory. In a new installation, nut-driver.target has neither.

I'll have to take a look at the source RPM and see if I can figure out where the problem might have originated. Thanks for your time, though.

jimklimov commented 1 year ago

FYI: the https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests also touches on this, and was recently added into INSTALL.nut document.

rknichols commented 1 year ago

https://bugzilla.redhat.com/show_bug.cgi?id=2173121 has been submitted.

jimklimov commented 1 year ago

Actually the solution to propose was rather about docs update or making sure NDE service runs on start (enable it via package postinstall).

I don't think world-wide packaging defaulta should enable monitoring of a particular UPS ;) More so, it is not a "netserver" by default since many hosts with NUT only run upsmon, and talk to their neighbor in control of the UPS itself (who has the drivers and data server, and may have upsmon if fed by the same UPS or watches another).

The "wants" links appear when both target/service units involved are being enabled (or disabled/enabled if a definition was updated on-disk).

rknichols commented 1 year ago

That .patch file was just a sample setup to demonstrate the problem. Without that, the first response would be, "You must have a mistake in your configuration. Show your configuration files."

Yes, the "Wants" links are created when/if the enumerator is run, accent on the "if".

Jsalas424 commented 1 year ago

I'm on version 2.7.4-13

The tripplite_usb apparently sees the device with meaningful data, so the problem boils down to getting the driver started in normal conditions. That would likely be about permissions - e.g. would it still see the data if started without -u root option?

Yes it does:

root@Server:~# /lib/nut/tripplite_usb -a UPS  -DDDDDD 
Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.29 (2.7.4)
Warning: This is an experimental driver.
Some features may not function correctly.

   0.000000     debug level is '6'
   0.164130     Checking device (8087/8000) (003/002)
   0.232322     - VendorID: 8087
   0.232337     - ProductID: 8000
   0.232341     - Manufacturer: unknown
   0.232344     - Product: unknown
   0.232347     - Serial Number: unknown
   0.232349     - Bus: 003
   0.232352     - Device release number: 0004
   0.232355     Trying to match device
   0.232359     Device does not match - skipping
   0.232376     Checking device (1D6B/0002) (003/001)
   0.232533     - VendorID: 1d6b
   0.232538     - ProductID: 0002
   0.232540     - Manufacturer: Linux 5.15.85-1-pve ehci_hcd
   0.232543     - Product: EHCI Host Controller
   0.232545     - Serial Number: 0000:00:1d.0
   0.232547     - Bus: 003
   0.232550     - Device release number: 0515
   0.232552     Trying to match device
   0.232555     Device does not match - skipping
   0.232562     Checking device (1D6B/0003) (004/001)
   0.259662     - VendorID: 1d6b
   0.259677     - ProductID: 0003
   0.259680     - Manufacturer: Linux 5.15.85-1-pve xhci-hcd
   0.259682     - Product: xHCI Host Controller
   0.259685     - Serial Number: 0000:00:14.0
   0.259687     - Bus: 004
   0.259690     - Device release number: 0515
   0.259693     Trying to match device
   0.259698     Device does not match - skipping
   0.259803     Checking device (09AE/0001) (002/003)
   0.263365     - VendorID: 09ae
   0.263372     - ProductID: 0001
   0.263374     - Manufacturer: Tripp Lite 
   0.263377     - Product: TRIPP LITE SMART500RT1U 
   0.263379     - Serial Number: unknown
   0.263382     - Bus: 002
   0.263384     - Device release number: 000a
   0.263387     Trying to match device
   0.263391     Device matches
   0.263411     failed to claim USB device: could not claim interface 0: Device or resource busy
   0.263610     detached kernel driver from USB device...
   0.263627     nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0)
   0.263632     Detected a UPS: Tripp Lite /TRIPP LITE SMART500RT1U 
   0.263639     send_to_all: SETINFO ups.vendorid "09ae"
   0.263645     send_to_all: SETINFO ups.productid "0001"
   0.263658     send_to_all: SETINFO device.type "ups"
   0.263664     send_to_all: SETINFO driver.version "2.7.4"
   0.263669     send_to_all: SETINFO driver.version.internal "0.29"
   0.263674     send_to_all: SETINFO driver.name "tripplite_usb"
   0.263678     send_cmd(msg_len=2, type='
   0.263684     send_cmd: sending  3a 00 ff 0d 00 00 00 00 '........'
   0.263689     send_cmd send_try 1
   0.371188     send_cmd: received 00 30 05 58 58 58 58 0d '.0.XXXX.' (OK)
   0.371205     send_cmd: send_try = 1, recv_try = 1

   0.371208     Using binary SMART protocol (3005)
   0.371215     send_to_all: SETINFO ups.firmware.aux "protocol 3005"
   0.371219     send_cmd(msg_len=3, type='W')
   0.371222     send_cmd: sending  3a 57 00 a8 0d 00 00 00 '.W......'
   0.371226     send_cmd send_try 1
   0.475202     send_cmd: received 57 00 0d 00 00 00 00 00 'W.......' (OK)
   0.475217     send_cmd: send_try = 1, recv_try = 1

   0.475230     send_cmd(msg_len=2, type='S')
   0.475233     send_cmd: sending  3a 53 ac 0d 00 00 00 00 '.S......'
   0.475235     send_cmd send_try 1
^C

If not, check if the NUT package provided udev.rules file includes the VID:PID pair for this device so its devfs node would be accessible to nut runtime user? Alternately, the user = root can be specified in ups.conf section (but not recommended if easy to avoid).

Adding user = root didn't help