<div dir="ltr">Cheers, we're getting to something here :)<br><div><br></div><div>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 ;)</div><div><br></div><div>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!</div><div><br></div><div>>
One of the things that the installation did not create is nutdrv_qx-nutdev1 ...</div><div><br></div><div>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?</div><div><br></div><div>* 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.</div><div><br></div><div>> ...(and I had no documentation to tell me how to create it)</div><div><br></div><div>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.</div><div><br></div><div>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 :)</div><div><br></div><div>> ...plus the error said "file/directory not found", so I created it as a directory. <br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So for some practical suggestions:</div><div><br></div><div>* Check if NDE did find and auto-create you a service instance:</div><div><br></div><div># 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.</div><div># Here we just check if any of those are enabled:</div><div>:; systemctl -a | grep nut-driver-enumerator</div><div><br></div><div># Check specifically for the expected wrapping instance, whichever way of calling NDE might have created it:</div><div>:; systemctl status nut-driver@nutdev1</div><div><br></div><div># 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):</div><div>:; journalctl -flu
nut-driver@nutdev1
<br></div><div><br></div><div>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).</div><div><br></div><div>Remove the directory, `systemctl restart nut-driver@nutdev1`, and check if it fares better now?</div><div><br></div><div>Hope this helps,</div><div>Jim Klimov</div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, May 12, 2025 at 5:00 AM Stephen Davies <<a href="mailto:sdavies@sdc.com.au">sdavies@sdc.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The key part of your reply is probably the para where you say "not a <br>
socket/pipe".<br>
One of the things that the installation did not create is <br>
nutdrv_qx-nutdev1 (and I had no documentation to tell me how to create <br>
it) plus the error said "file/directory not found", so I created it as a <br>
directory.<br>
How is it supposed to be created? One of the services I suppose.<br>
<br>
(I think I would like to get this version running before embarking on a <br>
source build.)<br>
<br>
Cheers and thanks,<br>
Stephen<br>
<br>
<br>
<br>
On 12/5/25 04:02, Jim Klimov wrote:<br>
> Hello, and welcome.<br>
> <br>
> On one hand, "yes" to what Greg said (there are known issues with <br>
> RedHat-derived packages, including lack of temporary paths or their <br>
> permissions, and 2.8.0 is rather old).<br>
> <br>
> On another, we still can dig around what's happening there :)<br>
> <br>
> * This part is most concerning:<br>
> <br>
> 0.008940 [D2] Checking device (0001/0000) (002/006)<br>
> 0.009034 [D1] Failed to open device (0001/0000), skipping:<br>
> Permission denied<br>
> <br>
> ...It means the driver could not access your UPS due to OS reasons, <br>
> which may include running as not a user allowed to use that devfs node <br>
> (assigned with an udev rules file on Linux - built by NUT, should be <br>
> delivered by the package), or potentially that another program (maybe <br>
> another instance of the NUT driver) grabbed it already...<br>
> <br>
> * The latter possibility would be consistent with NDE wrapping the <br>
> driver as a service unit, so you should not run it directly or via <br>
> upsdrvctl - see <a href="https://github.com/networkupstools/nut/wiki/" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/wiki/</a> <br>
> nut%E2%80%90driver%E2%80%90enumerator-(NDE) <<a href="https://github.com/" rel="noreferrer" target="_blank">https://github.com/</a> <br>
> networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)> <br>
> for more details.<br>
> <br>
> * However the revelation below that this is not a socket/pipe file but a <br>
> directory seems strange (I assume copy-paste error of some sort? or did <br>
> you/something else create it - and then indeed blocks access to the <br>
> driver-server socket?)<br>
> <br>
> drwxrwx--- 2 nut nut 40 May 11 13:57 nutdrv_qx-nutdev1<br>
> <br>
> * Warnings about too-open permissions should nudge you to tighten <br>
> security as documented :)<br>
> <br>
> * Messages about PID files are more meaningful in later NUT releases. <br>
> They mean that an earlier copy of this program is not running, so no <br>
> conflicts are expected (OR that its PID file got lost and so there would <br>
> be a conflict for some resources but we don't know which other PID to <br>
> signal away to terminate it, or send signals/commands to it).<br>
> <br>
> * `pwrstat` is not a NUT program. Seems to be from Cyberpower stack? If <br>
> a NUT driver has grabbed the device, other programs won't see it <br>
> (probable cause for "Lost Communication")<br>
> <br>
> * You can always build newer NUT, see <a href="https://github.com/" rel="noreferrer" target="_blank">https://github.com/</a> <br>
> networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or- <br>
> non%E2%80%90disruptive-tests <<a href="https://github.com/networkupstools/nut/" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/</a> <br>
> wiki/Building-NUT-for-in%E2%80%90place-upgrades-or- <br>
> non%E2%80%90disruptive-tests><br>
> <br>
> Hope this helps,<br>
> Jim Klimov<br>
> <br>
> <br>
> <br>
> On Sun, May 11, 2025 at 9:17 AM Stephen Davies via Nut-upsuser <nut- <br>
> <a href="mailto:upsuser@alioth-lists.debian.net" target="_blank">upsuser@alioth-lists.debian.net</a> <mailto:<a href="mailto:nut-upsuser@alioth-" target="_blank">nut-upsuser@alioth-</a> <br>
> <a href="http://lists.debian.net" rel="noreferrer" target="_blank">lists.debian.net</a>>> wrote:<br>
> <br>
> I installed a new UPS today and after several failed attempts with<br>
> other<br>
> software, installed Nut version 2.8 on my Centos 7 server using yum nut.<br>
> Several issues followed:<br>
> 1. When I started nut-server it failed because /run/nut did not<br>
> exist so<br>
> I created it by hand.<br>
> <br>
> 2. nut-server then started but gave he following in /var/log/messages:<br>
> May 11 13:33:00 mustang systemd: Started Network UPS Tools - power<br>
> devices information server.<br>
> May 11 13:33:00 mustang nut-server: fopen /run/nut/upsd.pid: No such<br>
> file or directory<br>
> May 11 13:33:00 mustang nut-server: Could not find PID file<br>
> '/run/nut/upsd.pid' to see if previous upsd instance is already running!<br>
> May 11 13:33:00 mustang nut-server: listening on 127.0.0.1 port 3493<br>
> May 11 13:33:00 mustang upsd[30778]: listening on 127.0.0.1 port 3493<br>
> May 11 13:33:00 mustang nut-server: listening on ::1 port 3493<br>
> May 11 13:33:00 mustang upsd[30778]: listening on ::1 port 3493<br>
> May 11 13:33:00 mustang nut-server: /run/nut is world readable<br>
> May 11 13:33:00 mustang upsd[30778]: /run/nut is world readable<br>
> May 11 13:33:00 mustang nut-server: Can't connect to UPS [nutdev1]<br>
> (nutdrv_qx-nutdev1): No such file or directory<br>
> May 11 13:33:00 mustang upsd[30778]: Can't connect to UPS [nutdev1]<br>
> (nutdrv_qx-nutdev1): No such file or directory<br>
> May 11 13:33:00 mustang nut-server: Running as foreground process, not<br>
> saving a PID file<br>
> May 11 13:33:00 mustang upsd[30778]: Running as foreground process, not<br>
> saving a PID file<br>
> <br>
> After a bit of manual tweeking, I now get:<br>
> May 11 16:30:05 <a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">mustang.sdc.com.au</a> <<a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">http://mustang.sdc.com.au</a>> nut-<br>
> server[11388]: fopen<br>
> /run/nut/upsd.pid: No such file or directory<br>
> May 11 16:30:05 <a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">mustang.sdc.com.au</a> <<a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">http://mustang.sdc.com.au</a>> nut-<br>
> server[11388]: Could not find PID<br>
> file '/run/nut/upsd.pid' to see if previous upsd instance is already<br>
> running!<br>
> May 11 16:30:05 <a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">mustang.sdc.com.au</a> <<a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">http://mustang.sdc.com.au</a>> nut-<br>
> server[11388]: listening on<br>
> 127.0.0.1 port 3493<br>
> May 11 16:30:05 <a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">mustang.sdc.com.au</a> <<a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">http://mustang.sdc.com.au</a>><br>
> upsd[11388]: listening on 127.0.0.1<br>
> port 3493<br>
> May 11 16:30:05 <a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">mustang.sdc.com.au</a> <<a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">http://mustang.sdc.com.au</a>> nut-<br>
> server[11388]: listening on ::1<br>
> port 3493<br>
> May 11 16:30:05 <a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">mustang.sdc.com.au</a> <<a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">http://mustang.sdc.com.au</a>><br>
> upsd[11388]: listening on ::1 port 3493<br>
> May 11 16:30:05 <a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">mustang.sdc.com.au</a> <<a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">http://mustang.sdc.com.au</a>> nut-<br>
> server[11388]: Can't connect to<br>
> UPS [nutdev1] (nutdrv_qx-nutdev1): Connection refused<br>
> May 11 16:30:05 <a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">mustang.sdc.com.au</a> <<a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">http://mustang.sdc.com.au</a>><br>
> upsd[11388]: Can't connect to UPS<br>
> [nutdev1] (nutdrv_qx-nutdev1): Connection refused<br>
> May 11 16:30:05 <a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">mustang.sdc.com.au</a> <<a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">http://mustang.sdc.com.au</a>> nut-<br>
> server[11388]: Running as<br>
> foreground process, not saving a PID file<br>
> May 11 16:30:05 <a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">mustang.sdc.com.au</a> <<a href="http://mustang.sdc.com.au" rel="noreferrer" target="_blank">http://mustang.sdc.com.au</a>><br>
> upsd[11388]: Running as foreground<br>
> process, not saving a PID file<br>
> <br>
> 3. I then tried upsdrvctl start but got:<br>
> [root@mustang ups]# upsdrvctl start<br>
> Network UPS Tools - UPS driver controller 2.8.0<br>
> Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)<br>
> USB communication driver (libusb 0.1) 0.43<br>
> No supported devices found. Please check your device availability with<br>
> 'lsusb'<br>
> and make sure you have an up-to-date version of NUT. If this does<br>
> not help,<br>
> try running the driver with at least 'subdriver', 'vendorid' and<br>
> 'productid'<br>
> options specified. Please refer to the man page for details about these<br>
> options<br>
> (man 8 nutdrv_qx).<br>
> <br>
> 4. [root@mustang ups]# pwrstat -status<br>
> <br>
> The UPS information shows as following:<br>
> <br>
> <br>
> Current UPS status:<br>
> State........................ Lost Communication<br>
> <br>
> <br>
> My ups.config has:<br>
> [nutdev1]<br>
> driver = "nutdrv_qx"<br>
> port = auto<br>
> vendorid = 0001<br>
> productid = 0000<br>
> bus = 002<br>
> protocol = hunnox<br>
> subdriver = hunnox<br>
> <br>
> The UPS is Digitech 650va<br>
> <br>
> [root@mustang ups]# lsusb<br>
> Bus 001 Device 005: ID 8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth<br>
> Bus 001 Device 006: ID 0461:4e70 Primax Electronics, Ltd<br>
> Bus 001 Device 003: ID 04ca:007d Lite-On Technology Corp.<br>
> Bus 001 Device 002: ID 0438:7900 Advanced Micro Devices, Inc. Root Hub<br>
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br>
> Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub<br>
> Bus 002 Device 002: ID 0bda:0153 Realtek Semiconductor Corp. 3-in-1<br>
> (SD/SDHC/SDXC) Card Reader<br>
> Bus 002 Device 006: ID 0001:0000 Fry's Electronics<br>
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br>
> (Bus 2 device 6 is the UPS.)<br>
> <br>
> [root@mustang ups]# /sbin/nutdrv_qx -DD -a nutdev1<br>
> Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)<br>
> USB communication driver (libusb 0.1) 0.43<br>
> 0.000000 [D1] debug level is '2'<br>
> 0.001243 [D1] upsdrv_initups...<br>
> 0.007948 [D2] Checking device (8087/0AA7) (001/005)<br>
> 0.008175 [D1] Failed to open device (8087/0AA7), skipping:<br>
> Permission denied<br>
> 0.008235 [D2] Checking device (0461/4E70) (001/006)<br>
> 0.008300 [D1] Failed to open device (0461/4E70), skipping:<br>
> Permission denied<br>
> 0.008350 [D2] Checking device (04CA/007D) (001/003)<br>
> 0.008411 [D1] Failed to open device (04CA/007D), skipping:<br>
> Permission denied<br>
> 0.008460 [D2] Checking device (0438/7900) (001/002)<br>
> 0.008537 [D1] Failed to open device (0438/7900), skipping:<br>
> Permission denied<br>
> 0.008593 [D2] Checking device (1D6B/0002) (001/001)<br>
> 0.008654 [D1] Failed to open device (1D6B/0002), skipping:<br>
> Permission denied<br>
> 0.008711 [D2] Checking device (1D6B/0003) (003/001)<br>
> 0.008776 [D1] Failed to open device (1D6B/0003), skipping:<br>
> Permission denied<br>
> 0.008825 [D2] Checking device (0BDA/0153) (002/002)<br>
> 0.008885 [D1] Failed to open device (0BDA/0153), skipping:<br>
> Permission denied<br>
> 0.008940 [D2] Checking device (0001/0000) (002/006)<br>
> 0.009034 [D1] Failed to open device (0001/0000), skipping:<br>
> Permission denied<br>
> 0.009089 [D2] Checking device (1D6B/0002) (002/001)<br>
> 0.009154 [D1] Failed to open device (1D6B/0002), skipping:<br>
> Permission denied<br>
> 0.009211 [D2] libusb0: No appropriate HID device found<br>
> 0.009258 No supported devices found. Please check your device<br>
> availability with 'lsusb'<br>
> <br>
> [root@mustang ups]# ls -al /run/nut<br>
> total 0<br>
> drwxrwx--- 3 nut nut 60 May 11 16:16 .<br>
> drwxr-xr-x 63 root root 1780 May 11 13:32 ..<br>
> drwxrwx--- 2 nut nut 40 May 11 13:57 nutdrv_qx-nutdev1<br>
> <br>
> It looks as if I am still missing something but I can't see what.<br>
> <br>
> Cheers and thanks,<br>
> Stephen<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> Nut-upsuser mailing list<br>
> <a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a> <mailto:<a href="mailto:Nut-upsuser@alioth-" target="_blank">Nut-upsuser@alioth-</a><br>
> <a href="http://lists.debian.net" rel="noreferrer" target="_blank">lists.debian.net</a>><br>
> <a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
> <<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a>><br>
> <br>
</blockquote></div>