similar to: Compile/Package / Config/Run 2.8.1 / Raspberry / UPS

Hi, I'm trying to get NUT running. I've installed it with pkg_add nut I can see my UPS as follows: # nut-scanner Cannot load SNMP library (libnetsnmp.so) : file not found. SNMP search disabled. Cannot load XML library (libneon.so) : file not found. XML search disabled. Cannot load AVAHI library (libavahi-client.so) : file not found. AVAHI search disabled. Scanning USB bus. No start

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:

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

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

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

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

Sounds great! By `connection error` it looks like the `upsc` client had nowhere to go. Is `upsd` started (and does it `LISTEN` on locahost or asterisk per `upsd.conf`)? Jim On Sat, Oct 26, 2024, 08:13 William R. Elliot <bill at wreassoc.com> wrote: > Hello again. > > I now have large chunks of the new driver working in the foreground and > wanted to see what upsc reports

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

> 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

An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20241026/ce542852/attachment.htm>

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

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

I'm trying to work out how to set up a custom udev rule to override permissions on serial ports (/dev/ttyS* and /dev/ttyUSB*) on CentOS 5.3 The default rule, in /etc/udev/rules.d/50-udev.rules has the line: KERNEL=="tty[A-Z]*", NAME="%k", GROUP="uucp", MODE="0660" and I would like the mode to be 0666 Various docs on web say that you

I've not been able to connect to my ups using NUT 2.7.4 or NUT 2.8.0. 2.7.4 was installed as a package, 2.8.O was compiled from source. I've messed with permissons, everything is root:root and has the approprate read/execute permissons. I've tried two differnt UPS(es) APC & CyperPower. I'm running PI OS (Raspbian) on a Raspberry Pi3 model B. The port 3493 is open (UFW). I can

Hi all, Yesterday, I bought a UPS for the first time in my life, and was eager to dive into NUT. But not all is working as expected... I saw a similar thread started on 18 October, but it didn't help me. (I also spent a handful of hours searching the web for solutions, and of course read the manual and FAQ - "queequeg".) I tried shutting my UPS (APC "Back-UPS BX750MI

I've built NUT 2.8.0 from source. When the nut-monitor runs: fopen upsmon.pid fails. I'm running as root, upsmon has root:root permissions as well as the other daemons and .conf files. I've tried configuring with and without --prefixpath --prefixaltpath. Is there something I am missing? Please see attached. Dan -------------- next part -------------- An HTML attachment was

I'm not sure I understand your question. The UPS was running for more than 15 minutes before it went below the battery.charge.low: of 70. Below is my /etc/nut/nut.conf. My goal is that when the UPS report a battery.charge.low of < 70 (or, if possible has been running for 5 minutes) it starts the shutdown process. The shutdown process should take 15 minutes so that proxmox can shutdown

Now that upsstats.cgi works, I've noticed that dummy-ups changes state every 5 minutes between OL and OB (probably when the 300 second timer expires). The UPS state stays online. Also "online" and "onbatt" are broadcast to the console probably via WALL. (The state changes don't seem to be form the ups as upsshed-cmd doesn't run). Upssched-cmd does run when the UPS

OpenBSD 6.1/amd64 nut-2.7.4p0 (from OpenBSD package) UPS: Tripp-Lite OMNI1500LCDT I cannot get the driver for the UPS to load without error. Here are the commands, with the output, and the config files: ======================================================= # upsdrvctl start Network UPS Tools - UPS driver controller 2.7.4 Network UPS Tools - Generic HID driver 0.41 (2.7.4) USB communication