[Nut-upsuser] UPS configuration issue?
Jim Klimov
jimklimov+nut at gmail.com
Mon May 12 08:57:52 BST 2025
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> 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/
> > nut%E2%80%90driver%E2%80%90enumerator-(NDE) <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/
> > networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-
> > non%E2%80%90disruptive-tests <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:nut-upsuser at alioth-
> > 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]
> > (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> 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> 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> 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>
> > upsd[11388]: listening on 127.0.0.1
> > port 3493
> > May 11 16:30:05 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>
> > upsd[11388]: listening on ::1 port 3493
> > May 11 16:30:05 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>
> > 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> 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>
> > 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>
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
> > <
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20250512/96acb85a/attachment-0001.htm>
More information about the Nut-upsuser
mailing list