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>>
> >
>