On 3/30/22 9:24 AM, Roger Heflin wrote:
nut-server seems to connect to the device and tie up its port.
It appears upower only accesses the device every so often and queries it.
So then once nut-server is started upower cannot open the device again.
It comes down to you cannot really have 2 separate software stacks managing any single device as it is rare that anyone writes their specific stack to play nice with others. nut-server is quite old and I know it opens and keeps open the port to the ups, mainly because it manages some old upses with very primitive control cables (not strictly serial connections).
There might be a way to configure upower and/or the applet to query nut-server rather than the ups. Though doing a quick look at upowerd the documentation seems sparse.
Just now I found a clue that suggests that NUT is somewhat aware of upower. There's a UDEV rules file named 95-upower-hid.rules that comes from the NUT project:
https://github.com/networkupstools/nut/blob/master/scripts/upower/95-upower-...
A file of this name is installed on my Fedora 34 systems, but it is packaged with upower:
$ rpm -qf /usr/lib/udev/rules.d/95-upower-hid.rules upower-0.99.13-1.fc34.x86_64
The file begins with this text:
# Uninterruptible Power Supplies with USB HID interfaces # # This file was automatically generated by NUT: # https://github.com/networkupstools/nut/
Also, there's an open NUT issue that relates to upower but it's not been updated since 2018:
https://github.com/networkupstools/nut/issues/526
The reason I'm using NUT, as opposed to apcupsd (which does play nice with upower), is that I have a couple of Synology NASes that have built-in NUT support. These NASes are connected to the same UPS as one of my Linux systems so I have the Linux system acting as NUT server with the NASes acting as NUT clients.
Dave