similar to: Installing and running NUT on OpenBSD

Hello, sorry and puzzled to hear about that. My guess would be permissions - while nut-scanner remains `root` (if started as one) and sees everything, drivers default to dropping privileges and may not see the devfs nodes (not sure OTOH which paths are involved on OpenBSD). One experimental workaround can be adding `user=root` to `ups.conf` entry for the device. But properly - tame whichever

I'm trying to Compile/Package and then (on a different box) Config/Run 2.8.1. Both boxes are Raspberry Pi 4b on Bullseye with a generic USB UPS. -- I'm trying to get nut running on my Raspberry (bullseye/11). (I'd also love to share a working 2.8.1 for Raspberry with the world, but...) I compiled the latest code from git: version 2.8.1-774-g963abbd87 I compiled it on one system

Running NUT version 2.8.2 on Fedora 40. NUT installed from the Fedora package. CyberPower CP1000AVRLCD connected by USB. I updated the system yesterday with all the latest Fedora packages. Now NUT will not run. Chasing the issue through the layers, I come to this: ===================== [root at mythtv rules.d]# upsc cyberpower Error: Driver not connected [root at mythtv rules.d]#

Did the upgrade by chance install/alter any udev rules causing the UPS devices to now have incorrect permissions? And what user is nut running as? On November 9, 2024 9:58:57 AM EST, Bill Gee <bgee at campercaver.net> wrote: >Running NUT version 2.8.2 on Fedora 40. NUT installed from the Fedora package. CyberPower CP1000AVRLCD connected by USB. > >I updated the system yesterday

Nut should be running as user nut. As far as I can tell, the udev rules have not changed. And the system IS seeing the UPS at a low level. I looked through /dev/ but did not see a device that jumps out as the UPS. ===================== [root at mythtv rules.d]# dmesg | grep -i 0764 [ 2.021485] usb 1-1.8: New USB device found, idVendor=0764, idProduct=0501, bcdDevice= 0.01 [ 2.049515]

Check /dev/hidraw6, as noted in your dmesg output (and any other *hid* devices under /dev). User nut has almost zero privs to devices unless a udev rule changes the perms on the dev for nut . . . On November 9, 2024 1:25:29 PM EST, Bill Gee <bgee at campercaver.net> wrote: >Nut should be running as user nut. As far as I can tell, the udev rules have not changed. And the system IS

I'm still digging into this but thought I'd post what I have so far in case there's a known issue that's easily fixed. I'm using the version of NUT that's in the ports tree (see the info at the bottom). Using the SNMP drivers to talk with two ACP SmartUPSs. NUT is functional about monitoring and initiating host shutdown. However, when it comes time to shut down the UPSs

Hello, Thanks for the report and sorry about any complications. A few first questions: * is this setup known to have been working with earlier NUT releases (e.g. same OS and devices, older NUT - can try with a custom build of older tags)? Is this a regression, or we never knew the correct mappings for timeouts and/or shutdown commands used by this model? * is there the `select` error when

Great! Regarding libusb and nut-scanner, I think the *.so (exact) symlinks are part of *-devel packages. This was solved in NUT recently (maybe after 2.8.2 release already) by detecting and stashing the basename of realpath of the library present during build, so the exact *.so.X.Y.Z would be also tried. Also, nut-scanner now (in 2.8.2 IIRC) should not suggest the volatile bus/busport/device

Ok - I'm wondering is this is a systemd config bit? systemctl restart nut-driver at malaysia.service Job for nut-driver at malaysia.service failed because the control process exited with error code. See "systemctl status nut-driver at malaysia.service" and "journalctl -xeu nut-driver at malaysia.service" for details. root at malaysia:~# systemctl status nut-driver at

Normally yes - enable and start the target and the particular services relevant to your setup. For the binary you have from packaging (if not rebuilt as suggested earlier), set debug_min=3 in ups.conf section for upscode2, to currently trade driver viability for some storage traffic with more logs :\ Sorry about that, Jim On Wed, Jul 5, 2023, 02:29 Karl Schmidt <karl at lrak.net> wrote:

Hello, I was thinking about what could be going wrong here, and a few ideas pop up: 1) If you installed NUT from packaging, there should have been no need to add OS groups/users manually. There is a valid use-case for running different daemons under different accounts, as long as they talk over network and access same files or UNIX sockets at best by sharing a group for that, but it does need

On 7/4/23 10:01PM, Jim Klimov wrote: > Normally yes - enable and start the target and the particular services relevant to your setup. > > For the binary you have from packaging (if not rebuilt as suggested earlier), set debug_min=3 in ups.conf section for > upscode2, to currently trade driver viability for some storage traffic with more logs :\ > > Sorry about?that, > Jim

Hi Jim, Thanks for your help. I'll respond in the same order as you did: 1. Unfortunately, I did "chown" stuff to these created users... Since the other three responses don't seem to be what you're looking for (but that's only my uninformed interpretation), I suppose the problem lies here? Is there a number of files/directories that I should

I would like to keep NUT installed but disable it completely at times. I tried both 'disabling' and 'masking' all the following 'systemctl services nut-server nut-monitor nut-client ups-monitor nut-driver-enumerator as follows: systemctl disable nut-server nut-monitor nut-client ups-monitor nut-driver-enumerator systemctl mask nut-server nut-monitor nut-client

Ah, I thought you missed in my earlier reply the part about a bug with debug printouts in 2.8.0 (fixed on master since), did not comment on that when you replied with quoting... So, for now options are to bump debugging to 3+ or to build your own in one of many ways possible :\ On Wed, Jul 5, 2023, 06:23 Karl Schmidt <karl at lrak.net> wrote: > On 7/4/23 10:01PM, Jim Klimov wrote: >

> Hello Arnaud, Hi Alex, > First of all i want to thank you for such useful and convenient > system tool as NUT. I think it is one from most important tools > for server machines. And it make its work excellent. thanks > I use NUT on SuSE distro and adapted init-scripts from package for > this distro style. Send you them with hope that you find them useful > for

On 7/5/23 03:17AM, Jim Klimov wrote: > Ah, I thought you missed in my earlier reply the part about a bug with debug printouts in 2.8.0 (fixed on master since), > did not comment on that when you replied with quoting... So, for now options are to bump debugging to 3+ or to build > your own in one of many ways possible :\ I think I'm not following you - with debug 3 -->> it

Got an update for APC Modbus users: a new PR is waiting for real-life testing for settable variables and instant commands support. https://github.com/networkupstools/nut/pull/2184 As before, a custom build of libmodbus may be needed for USB support (detailed in the earlier PR), but Serial and TCP may already be well served by a distro near you! Jim On Sun, Oct 22, 2023, 01:08 Jim Klimov

Got an update for APC Modbus users: a new PR is waiting for real-life testing for settable variables and instant commands support. https://github.com/networkupstools/nut/pull/2184 As before, a custom build of libmodbus may be needed for USB support (detailed in the earlier PR), but Serial and TCP may already be well served by a distro near you! Jim On Sun, Oct 22, 2023, 01:08 Jim Klimov