similar to: NUT with openSUSE 13.2

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:

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

Roger, Ok, I simplified it somewhat. I start all of the NUT services on the command line after boot, to verify they are all starting correctly. They appear to be. Doing this, I found the systemd service unit to somewhat reliably execute the shutdown. I only tried 5 times, but it worked each time which is a fairly significant change from previously. Still...hardly conclusive, and I'd

On Fri, 4 Sep 2015, Rob Groner wrote: > Well, I tried the same script method with openSUSE 13.2, and it still did not execute. > > So I tried the system method, and it worked 1 time out of 3 attempts. I captured the last failure: > 2015-09-04T11:43:38.825317-04:00 linux-5048 upsdrvctl[1887]: Can't claim USB device [2a37:5110]: No such file or directory >

Hello, i have this strange problem with APC BackUPS RS 1500 ? older one model, white one under windows in powerchute is device OK, working everything ok selftest ok, just ordinary ups. under CentOS 7 minimal (CentOS-7-x86_64-Minimal-1708.iso) kernel version 3.10.0-693.el7.x68_64 driver version 2.7.2 i have this strange probem: nut driver didnt start automatically with error, after i enter in

Hello, i have this strange problem with APC BackUPS RS 1500 ? older one model, white one under windows in powerchute is device OK, working everything ok selftest ok, just ordinary ups. under CentOS 7 minimal (CentOS-7-x86_64-Minimal-1708.iso) kernel version 3.10.0-693.el7.x68_64 driver version 2.7.2 i have this strange probem: nut driver didnt start automatically with error, after i enter in

Roger, Well, I tried the same script method with openSUSE 13.2, and it still did not execute. So I tried the system method, and it worked 1 time out of 3 attempts. I captured the last failure: 2015-09-04T11:43:38.825317-04:00 linux-5048 upsdrvctl[1887]: Can't claim USB device [2a37:5110]: No such file or directory 2015-09-04T11:43:38.825970-04:00 linux-5048 upsdrvctl[1887]: Network UPS

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

maybe i have solved this issue, i unplugged APC BackUPS from USB 2.0 and PLUGGED INTO USB 3.0 and now it works prefectly at first time without any side effects, strange, this shoud be working since USB 1.0 so ups driver is configured OK, this config works ok for backups, this looks like there is no problem with detection of UPS but with USB driver or something around so simply if somebody has

OS: Raspbian Lite 4.19 (Linux 5.4.51-v7l+ armv7l) NUT version: 2.7.4 Install Method: Package (apt-get) Device Name: CyberPower CP1500PFCLCD, connected via USB Problem: This is a brand-new installation; the only step I've taken is my initial edit of /etc/nut/ups.conf (which I'll post below). I started the driver and after doing so issued a reboot command to my Raspberry Pi (sudo reboot).

Yes: Previous complete boot through shutdown Oct 26 21:02:54 i7 upsdrvctl[1955]: Using subdriver: MGE HID 1.32 Oct 26 21:02:55 i7 upsdrvctl[1955]: Network UPS Tools - Generic HID driver 0.38 (2.7.1) Oct 26 21:02:55 i7 upsdrvctl[1955]: USB communication driver 0.32 Oct 26 21:02:56 i7 upsdrvctl[1955]: Network UPS Tools - UPS driver controller 2.7.1 Oct 26 21:02:56 i7 upsd[2226]: fopen

The latest release of openSUSE is 13.1 and it includes NUT 2.6.5. It is a pleasure to report that this works well when equipped with a working set of configuration files. Additionally, the setup requires 1. Something to execute upsdrvctl shutdown to turn off the UPS unit. A systemd script "ups-delayed.shutdown" in /usr/lib/systemd/system-shutdown will do the job. #! /bin/bash

Hi, Every time that I have to restart the nut-server it's a nightmare. For example, after editing ups.conf In many cases the only "solution" is to reboot the system. These are the errors: systemctl -l status nut-driver ? nut-driver.service - Network UPS Tools - power device driver controller Loaded: loaded (/usr/lib/systemd/system/nut-driver.service; static; vendor preset:

On 12/16/2013 09:23 PM, Charles Lepple wrote: > Not sure - I didn't write the getaddrinfo() code in upsd, but it seemed to > follow all of the recommendations on how to use that function. So if there is > a way to fix it in the NUT code, I am not aware of it (and would appreciate > any updates if that turns out to be the case). > > The odd part is that it looks like you went

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

I've told systemd to wait up to 10 minutes for startup but it's still failing. Sometimes it fails with "timeout exceeded" and sometimes with the ASN error previously reported. I went back to running upsdrvctl -D to see if I could see anything. On the third run I saw messages about "startup timer elapsed" for ups2-1 and then it tried again to launch that one (killing

Which OS is that? With Linux+systemd, I'd expect systemd to start the drivers (hence blocking the port) and keep logs in the systemd journal (if your packaging includes nut-driver-enumerator, you may see them with `journalctl -lu nut-driver at myups3`; for older systems just `journalctl -lu nut-driver`), and on others init-scripts added by packaging should do the same to start drivers when

Hello all: I did a fresh install of CentOS 7 on a new machine. I wrote /usr/local/bin/firewall.stop to remove all the firewall rules. It contains this code: # Flush the rules /usr/sbin/iptables -F # Set the default policies to accept /usr/sbin/iptables -P INPUT ACCEPT /usr/sbin/iptables -P OUTPUT ACCEPT /usr/sbin/iptables -P FORWARD ACCEPT I wrote /usr/local/bin/firewall.start to set the

Hi Jim, I?m using on Kali Linux. I?m not using a custom version and finally found the issue which was a hidden character staying in the ups.conf file. I rebuilt the file and everything worked out. Issue closed and many thanks for your help. Laurent From: Jim Klimov <jimklimov+nut at gmail.com> Sent: mercredi 29 mars 2023 13:22 To: laurenttaieb at free.fr Cc: nut-upsuser