[Nut-upsuser] UPS configuration issue?
Stephen Davies
sdavies at sdc.com.au
Tue May 13 08:12:42 BST 2025
Output from systemctl restart nut-driver at nutdev1 after removing the
directory:
May 13 16:35:08 mustang.sdc.com.au systemd[1]: Starting Network UPS
Tools - device driver for NUT device 'nutdev1'...
May 13 16:35:08 mustang.sdc.com.au nut-driver at nutdev1[16999]: Can't
claim USB device [0001:0000]@0/0: No such file or directory
May 13 16:35:08 mustang.sdc.com.au nut-driver at nutdev1[16999]: Network
UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
May 13 16:35:08 mustang.sdc.com.au nut-driver at nutdev1[16999]: USB
communication driver (libusb 0.1) 0.43
May 13 16:35:08 mustang.sdc.com.au nut-driver at nutdev1[16999]: Driver
failed to start (exit status=1)
[root at mustang system]# lsusb
Bus 001 Device 005: ID 8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth
Bus 001 Device 006: ID 0461:4e70 Primax Electronics, Ltd
Bus 001 Device 003: ID 04ca:007d Lite-On Technology Corp.
Bus 001 Device 002: ID 0438:7900 Advanced Micro Devices, Inc. Root Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 0bda:0153 Realtek Semiconductor Corp. 3-in-1
(SD/SDHC/SDXC) Card Reader
Bus 002 Device 006: ID 0001:0000 Fry's Electronics
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[nutdev1]
driver = "nutdrv_qx"
port = auto
vendorid = 0001
productid = 0000
bus = 002
protocol = hunnox
subdriver = hunnox
Cheers,
Stephen
On 12/5/25 17:27, Jim Klimov wrote:
> Cheers, we're getting to something here :)
>
> Alas, with NUT's long history starting when computers were tools of the
> relatively few engineer nerd types, much of the documentation remains
> "elitist". With a complex ecosystem like UPS devices and ways to connect
> and manage them and not get electrocuted, people were expected to have
> time to read up and understand the design and know their computers. With
> the consumerish age these assumptions are probably no longer fully
> valid... so PRs to update the docs and make them friendlier to new-
> comers with a 5-minute attention span (and little time to invest between
> a million other daily things to be done, I do know this to be a big
> block to lift before starting anything) are quite welcome ;)
>
> Partially due to this, I've started a new manual page (after release
> v2.8.3) so people can get a reasonable overview of the NUT layering and
> some practical caveats by uttering `man nut`. Surprisingly, there was no
> such thing for over the quarter of a century that the project has been
> out there!
>
> > One of the things that the installation did not create is nutdrv_qx-
> nutdev1 ...
>
> A bit of critical thinking is due. A "nutdev1" part in the name is what
> you called the device in your configuration (even if copy-pasted from
> nut-scanner output). How would an inert installer know how to create one
> before it is defined?
>
> * Actually the nut-driver-enumerator (NDE) would do just that, create a
> service instance based on your config, but that is not quite part of
> "installation" usually. Post-install package scripts might call this on
> some platforms though, so the packaged update to an existing NUT
> deployment is ready to roll out immediately with new methodologies applied.
>
> > ...(and I had no documentation to tell me how to create it)
>
> Technically, because you don't, a driver does (the socket file name is
> literally "<driver name>-<ups.conf section name>", with similar patterns
> used for PID files notably.
>
> I think this is the first time I see someone report having made one
> manually :-\ Gotta add some checks for that possibility of file system
> corruption, I guess :)
>
> > ...plus the error said "file/directory not found", so I created it as
> a directory.
>
> The "directory" part of that error text comes from system libraries. On
> the filesystem level, "everything is a file", a directory is just a file
> of structured records that the system knows how to parse and maintain
> consistently.
>
> The "not found" part is, as mentioned in an earlier reply, from start-up
> checks to see whether this instance of the driver is the first of its
> name or if there is another. Part of conflict avoidance/prediction, or
> since NUT v2.8.2 or so, this can be actually used by drivers to send
> commands from a newly started copy to the running daemon better (with
> more context/arguments) than poking via OS signals as done for ages
> before that.
>
> So for some practical suggestions:
>
> * Check if NDE did find and auto-create you a service instance:
>
> # There are several implementations for flexible purposes (e.g. monitor
> ups.conf changes continuously vs. only once at service restart/system
> boot), not all may be enabled at the same time.
> # Here we just check if any of those are enabled:
> :; systemctl -a | grep nut-driver-enumerator
>
> # Check specifically for the expected wrapping instance, whichever way
> of calling NDE might have created it:
> :; systemctl status nut-driver at nutdev1
>
> # If it exists, you can monitor its logs like any other systemd unit
> journal, probably as root though ("-f" to follow the log as it gets
> appended):
> :; journalctl -flu nut-driver at nutdev1
>
> I suppose the tests above would show the service exists, and probably
> fails to start because it can not create the socket file due to the name
> being occupied by a directory. Or worse, that somehow it does start
> despite that (but has no way to talk to the world).
>
> Remove the directory, `systemctl restart nut-driver at nutdev1`, and check
> if it fares better now?
>
> Hope this helps,
> Jim Klimov
>
>
>
> On Mon, May 12, 2025 at 5:00 AM Stephen Davies <sdavies at sdc.com.au
> <mailto:sdavies at sdc.com.au>> wrote:
>
> The key part of your reply is probably the para where you say "not a
> socket/pipe".
> One of the things that the installation did not create is
> nutdrv_qx-nutdev1 (and I had no documentation to tell me how to create
> it) plus the error said "file/directory not found", so I created it
> as a
> directory.
> How is it supposed to be created? One of the services I suppose.
>
> (I think I would like to get this version running before embarking on a
> source build.)
>
> Cheers and thanks,
> Stephen
>
>
>
> On 12/5/25 04:02, Jim Klimov wrote:
> > Hello, and welcome.
> >
> > On one hand, "yes" to what Greg said (there are known issues with
> > RedHat-derived packages, including lack of temporary paths or their
> > permissions, and 2.8.0 is rather old).
> >
> > On another, we still can dig around what's happening there :)
> >
> > * This part is most concerning:
> >
> > 0.008940 [D2] Checking device (0001/0000) (002/006)
> > 0.009034 [D1] Failed to open device (0001/0000), skipping:
> > Permission denied
> >
> > ...It means the driver could not access your UPS due to OS reasons,
> > which may include running as not a user allowed to use that devfs
> node
> > (assigned with an udev rules file on Linux - built by NUT, should be
> > delivered by the package), or potentially that another program
> (maybe
> > another instance of the NUT driver) grabbed it already...
> >
> > * The latter possibility would be consistent with NDE wrapping the
> > driver as a service unit, so you should not run it directly or via
> > upsdrvctl - see 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)>
> > for more details.
> >
> > * However the revelation below that this is not a socket/pipe
> file but a
> > directory seems strange (I assume copy-paste error of some sort?
> or did
> > you/something else create it - and then indeed blocks access to the
> > driver-server socket?)
> >
> > drwxrwx--- 2 nut nut 40 May 11 13:57 nutdrv_qx-nutdev1
> >
> > * Warnings about too-open permissions should nudge you to tighten
> > security as documented :)
> >
> > * Messages about PID files are more meaningful in later NUT
> releases.
> > They mean that an earlier copy of this program is not running, so no
> > conflicts are expected (OR that its PID file got lost and so
> there would
> > be a conflict for some resources but we don't know which other
> PID to
> > signal away to terminate it, or send signals/commands to it).
> >
> > * `pwrstat` is not a NUT program. Seems to be from Cyberpower
> stack? If
> > a NUT driver has grabbed the device, other programs won't see it
> > (probable cause for "Lost Communication")
> >
> > * You can always build newer NUT, see https://github.com/
> <https://github.com/>
> > networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-
> upgrades-or-
> > non%E2%80%90disruptive-tests <https://github.com/networkupstools/
> nut/ <https://github.com/networkupstools/nut/>
> > wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-
> > non%E2%80%90disruptive-tests>
> >
> > Hope this helps,
> > Jim Klimov
> >
> >
> >
> > On Sun, May 11, 2025 at 9:17 AM Stephen Davies via Nut-upsuser <nut-
> > upsuser at alioth-lists.debian.net <mailto:upsuser at alioth-
> lists.debian.net> <mailto:nut-upsuser at alioth- <mailto:nut-
> upsuser at alioth->
> > lists.debian.net <http://lists.debian.net>>> wrote:
> >
> > I installed a new UPS today and after several failed attempts
> with
> > other
> > software, installed Nut version 2.8 on my Centos 7 server
> using yum nut.
> > Several issues followed:
> > 1. When I started nut-server it failed because /run/nut did not
> > exist so
> > I created it by hand.
> >
> > 2. nut-server then started but gave he following in /var/log/
> messages:
> > May 11 13:33:00 mustang systemd: Started Network UPS Tools -
> power
> > devices information server.
> > May 11 13:33:00 mustang nut-server: fopen /run/nut/upsd.pid:
> No such
> > file or directory
> > May 11 13:33:00 mustang nut-server: Could not find PID file
> > '/run/nut/upsd.pid' to see if previous upsd instance is
> already running!
> > May 11 13:33:00 mustang nut-server: listening on 127.0.0.1
> port 3493
> > May 11 13:33:00 mustang upsd[30778]: listening on 127.0.0.1
> port 3493
> > May 11 13:33:00 mustang nut-server: listening on ::1 port 3493
> > May 11 13:33:00 mustang upsd[30778]: listening on ::1 port 3493
> > May 11 13:33:00 mustang nut-server: /run/nut is world readable
> > May 11 13:33:00 mustang upsd[30778]: /run/nut is world readable
> > May 11 13:33:00 mustang nut-server: Can't connect to UPS
> [nutdev1]
> > (nutdrv_qx-nutdev1): No such file or directory
> > May 11 13:33:00 mustang upsd[30778]: Can't connect to UPS
> [nutdev1][nutdev1]
driver = "nutdrv_qx"
port = auto
vendorid = 0001
productid = 0000
bus = 002
protocol = hunnox
subdriver = hunnox
> > (nutdrv_qx-nutdev1): No such file or directory
> > May 11 13:33:00 mustang nut-server: Running as foreground
> process, not
> > saving a PID file
> > May 11 13:33:00 mustang upsd[30778]: Running as foreground
> process, not
> > saving a PID file
> >
> > After a bit of manual tweeking, I now get:
> > May 11 16:30:05 mustang.sdc.com.au <http://
> mustang.sdc.com.au> <http://mustang.sdc.com.au <http://
> mustang.sdc.com.au>> nut-
> > server[11388]: fopen
> > /run/nut/upsd.pid: No such file or directory
> > May 11 16:30:05 mustang.sdc.com.au <http://
> mustang.sdc.com.au> <http://mustang.sdc.com.au <http://
> mustang.sdc.com.au>> nut-
> > server[11388]: Could not find PID
> > file '/run/nut/upsd.pid' to see if previous upsd instance is
> already
> > running!
> > May 11 16:30:05 mustang.sdc.com.au <http://
> mustang.sdc.com.au> <http://mustang.sdc.com.au <http://
> mustang.sdc.com.au>> nut-
> > server[11388]: listening on
> > 127.0.0.1 port 3493
> > May 11 16:30:05 mustang.sdc.com.au <http://
> mustang.sdc.com.au> <http://mustang.sdc.com.au <http://
> mustang.sdc.com.au>>
> > upsd[11388]: listening on 127.0.0.1
> > port 3493
> > May 11 16:30:05 mustang.sdc.com.au <http://
> mustang.sdc.com.au> <http://mustang.sdc.com.au <http://
> mustang.sdc.com.au>> nut-
> > server[11388]: listening on ::1
> > port 3493
> > May 11 16:30:05 mustang.sdc.com.au <http://
> mustang.sdc.com.au> <http://mustang.sdc.com.au <http://
> mustang.sdc.com.au>>
> > upsd[11388]: listening on ::1 port 3493
> > May 11 16:30:05 mustang.sdc.com.au <http://
> mustang.sdc.com.au> <http://mustang.sdc.com.au <http://
> mustang.sdc.com.au>> nut-
> > server[11388]: Can't connect to
> > UPS [nutdev1] (nutdrv_qx-nutdev1): Connection refused
> > May 11 16:30:05 mustang.sdc.com.au <http://
> mustang.sdc.com.au> <http://mustang.sdc.com.au <http://
> mustang.sdc.com.au>>
> > upsd[11388]: Can't connect to UPS
> > [nutdev1] (nutdrv_qx-nutdev1): Connection refused
> > May 11 16:30:05 mustang.sdc.com.au <http://
> mustang.sdc.com.au> <http://mustang.sdc.com.au <http://
> mustang.sdc.com.au>> nut-
> > server[11388]: Running as
> > foreground process, not saving a PID file
> > May 11 16:30:05 mustang.sdc.com.au <http://
> mustang.sdc.com.au> <http://mustang.sdc.com.au <http://
> mustang.sdc.com.au>>
> > upsd[11388]: Running as foreground
> > process, not saving a PID file
> >
> > 3. I then tried upsdrvctl start but got:
> > [root at mustang ups]# upsdrvctl start
> > Network UPS Tools - UPS driver controller 2.8.0
> > Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
> > USB communication driver (libusb 0.1) 0.43
> > No supported devices found. Please check your device
> availability with
> > 'lsusb'
> > and make sure you have an up-to-date version of NUT. If this does
> > not help,
> > try running the driver with at least 'subdriver', 'vendorid' and
> > 'productid'
> > options specified. Please refer to the man page for details
> about these
> > options
> > (man 8 nutdrv_qx).
> >
> > 4. [root at mustang ups]# pwrstat -status
> >
> > The UPS information shows as following:
> >
> >
> > Current UPS status:
> > State........................ Lost
> Communication
> >
> >
> > My ups.config has:
> > [nutdev1]
> > driver = "nutdrv_qx"
> > port = auto
> > vendorid = 0001
> > productid = 0000
> > bus = 002
> > protocol = hunnox
> > subdriver = hunnox
> >
> > The UPS is Digitech 650va
> >
> > [root at mustang ups]# lsusb
> > Bus 001 Device 005: ID 8087:0aa7 Intel Corp. Wireless-AC 3168
> Bluetooth
> > Bus 001 Device 006: ID 0461:4e70 Primax Electronics, Ltd
> > Bus 001 Device 003: ID 04ca:007d Lite-On Technology Corp.
> > Bus 001 Device 002: ID 0438:7900 Advanced Micro Devices, Inc.
> Root Hub
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> > Bus 002 Device 002: ID 0bda:0153 Realtek Semiconductor Corp.
> 3-in-1
> > (SD/SDHC/SDXC) Card Reader
> > Bus 002 Device 006: ID 0001:0000 Fry's Electronics
> > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > (Bus 2 device 6 is the UPS.)
> >
> > [root at mustang ups]# /sbin/nutdrv_qx -DD -a nutdev1
> > Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
> > USB communication driver (libusb 0.1) 0.43
> > 0.000000 [D1] debug level is '2'
> > 0.001243 [D1] upsdrv_initups...
> > 0.007948 [D2] Checking device (8087/0AA7) (001/005)
> > 0.008175 [D1] Failed to open device (8087/0AA7),
> skipping:
> > Permission denied
> > 0.008235 [D2] Checking device (0461/4E70) (001/006)
> > 0.008300 [D1] Failed to open device (0461/4E70),
> skipping:
> > Permission denied
> > 0.008350 [D2] Checking device (04CA/007D) (001/003)
> > 0.008411 [D1] Failed to open device (04CA/007D),
> skipping:
> > Permission denied
> > 0.008460 [D2] Checking device (0438/7900) (001/002)
> > 0.008537 [D1] Failed to open device (0438/7900),
> skipping:
> > Permission denied
> > 0.008593 [D2] Checking device (1D6B/0002) (001/001)
> > 0.008654 [D1] Failed to open device (1D6B/0002),
> skipping:
> > Permission denied
> > 0.008711 [D2] Checking device (1D6B/0003) (003/001)
> > 0.008776 [D1] Failed to open device (1D6B/0003),
> skipping:
> > Permission denied
> > 0.008825 [D2] Checking device (0BDA/0153) (002/002)
> > 0.008885 [D1] Failed to open device (0BDA/0153),
> skipping:
> > Permission denied
> > 0.008940 [D2] Checking device (0001/0000) (002/006)
> > 0.009034 [D1] Failed to open device (0001/0000),
> skipping:
> > Permission denied
> > 0.009089 [D2] Checking device (1D6B/0002) (002/001)
> > 0.009154 [D1] Failed to open device (1D6B/0002),
> skipping:
> > Permission denied
> > 0.009211 [D2] libusb0: No appropriate HID device found
> > 0.009258 No supported devices found. Please check
> your device
> > availability with 'lsusb'
> >
> > [root at mustang ups]# ls -al /run/nut
> > total 0
> > drwxrwx--- 3 nut nut 60 May 11 16:16 .
> > drwxr-xr-x 63 root root 1780 May 11 13:32 ..
> > drwxrwx--- 2 nut nut 40 May 11 13:57 nutdrv_qx-nutdev1
> >
> > It looks as if I am still missing something but I can't see what.
> >
> > Cheers and thanks,
> > Stephen
> >
> >
> >
> > _______________________________________________
> > 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>>
> >
>
More information about the Nut-upsuser
mailing list