similar to: NUT and Eaton UPS produce a lot of error messages

Hi Jim Thanks for the info. Nut runs on bare metal, there is no virtualization layer. I will have a look at the github post after writing this post. I have compiled and installed nut 2.8.2 as suggested. But now I am confused: Where is the usb-hid driver, which I used in Nut 2.8.0? Does one need to pass a special flag to configure to build it? Yours Stefan Am Fr., 5. Juli 2024 um 18:52 Uhr

Did you check also that `upsc` client does not report anything about the device? The message indicates that some other process has a hold on the USB devfs node, and those can typically be either other copies of a NUT driver, rarely some other programs that see and grab HID devices, or in case of virtualization and pass-through - the device being busy in the guest or host system (other than the

Stefan Schumacher via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes: > I am using: Debian Bookworm 12.6 with these packages, which were > installed from the official Debian Repository. > ii nut 2.8.0-7 > all network UPS tools - metapackage > ii nut-client 2.8.0-7 > amd64 network UPS tools

Hello Initial Disclaimer: I used this tutorial. I know its in german but the entries to be made in the configuration files are marked and should be able to identify if there are any errors. https://techbotch.org/blog/ups-setup/index.html After several power failures and damaged fuses I decided to give Eaton & Nut another try. Eaton because the model I bought seems to be the one on the

Well, from your logs it seems that at 05:17:03 your nut-server (upsd) restarted, so an upsmon reconnection attempt at 05:17:09 had an issue with that (config not all applied? strange a bit) but since 05:17:14 it is okay. Maybe a few too many banners shown from upsmon, while its same uptime seems to continue. Maybe someone should check on that, seems like a good and easy newcomer issue to learn

Also, just in case - are you in a virtualized environment? Is there (intentional or not) USB pass-through to the UPSes? My hint is, we had cases where a host or guest grabbed the device but it was not apparent from the part of system running NUT. Jim On Fri, Mar 24, 2023, 23:23 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Sounds like some other program is holding the port. Have

Sounds like some other program is holding the port. Have you stopped other NUT drivers for the device (e.g. via auto-resuscitating services) before starting this one? Does udev, ugen or similar facility have the configuration to hand off this device to NUT run-time user? (BTW, if you are now testing a custom build - was it configured to use same accounts as pre-packaged variant)? On Fri, Mar 24,

I?m making some progress I believe? I switched off and switched on the UPS further to the laptop having started the daemon and I?m not getting the same error message which is probably due to the server working in the background still locking the device I think the daemon starts but gets into an infinite loop and doesn?t finish and hand back control. Here are the updated traces I got by

Hello I recently bought a small UPS by Eaton (Ellipse ECO 800) in order to prevent my btrfs-fileserver (running Debian 12 Bookworm 12.4 from shutting down abruptly while writing something important during a power loss. I am using the version 2.8.0.7 provided by Debian. I have found very gooddocumentation on how to set up the UPS and the services on the server connected to it. Unfortunately

On 19.01.24 16:20, Stefan Schumacher via Nut-upsuser wrote: >This morning at 9:50 the server stopped working unexpectedly - I was >still sleeping until 10:00, so no user intervention took place. > >Jan 19 05:50:17 mars nut-server[1303]: mainloop: Interrupted system call >Jan 19 05:50:17 mars nut-server[1303]: Signal 15: exiting >Jan 19 05:50:17 mars nut-server[1303]: Network UPS

On 19.01.24 09:00, Jim Klimov via Nut-upsuser wrote: >Well, from your logs it seems that at 05:17:03 your nut-server (upsd) >restarted, so an upsmon reconnection attempt at 05:17:09 had an issue with >that (config not all applied? strange a bit) but since 05:17:14 it is okay. > >Maybe a few too many banners shown from upsmon, while its same uptime seems >to continue. Maybe

Jan 19 05:50:13 mars nut-monitor[849]: Signal 15: exiting Jan 19 05:50:13 mars nut-monitor[849]: Network UPS Tools upsmon 2.8.0 Jan 19 05:50:13 mars systemd[1]: Stopping nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller... Jan 19 05:50:13 mars systemd[1]: nut-monitor.service: Deactivated successfully. Jan 19 05:50:13 mars systemd[1]: Stopped nut-monitor.service

Hello and thanks for all the replies. This morning at 9:50 the server stopped working unexpectedly - I was still sleeping until 10:00, so no user intervention took place. Jan 19 05:50:17 mars nut-server[1303]: mainloop: Interrupted system call Jan 19 05:50:17 mars nut-server[1303]: Signal 15: exiting Jan 19 05:50:17 mars nut-server[1303]: Network UPS Tools upsd 2.8.0 Jan 19 05:50:17 mars

With recent NUT releases, driver disconnections should be contained in its own `nut-driver at eaton` instance (the `@upsname` part is derived from the `ups.conf` section name). One of the drivers failing and restarting is not a proper cause for the data server to recycle. Also, nowadays some (maybe not all) USB-capable drivers should try to reconnect without restarting. Note however, that in some

Hello On 06/14/2017 03:32 PM, Arnaud Quette wrote: > > > On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro > <mailto:wolfy at nobugconsulting.ro>> wrote: > >> > >> > If that matters, the OS is a fully updated CentOS 6.9 >> and this (latest stable ) version of nut was packaged by me. >>

Laurent Taieb via Nut-upsuser wrote on 3/9/23 9:25 AM: > > Hi NUT Users, > > One of my APC UPS is having battery issue and apparently we cannot > change battery in that UPS. (not super green?) > > I have purchased an EATON UPS and added the ref in ups.conf > > When restarting the driver, I got this error > > >0.030612[D2] Checking device 2 of 10 (0463/FFFF)

Thanks Larry, I tried. Got the following traces and the driver doesn?t start. 1.036797 [D2] - VendorID: 0463 1.036812 [D2] - ProductID: ffff 1.036826 [D2] - Manufacturer: unknown 1.036840 [D2] - Product: unknown 1.036872 [D2] - Serial Number: unknown 1.036912 [D2] - Bus: 002 1.036942 [D2] - Device: unknown 1.036965 [D2] - Device

Hi NUT Users, One of my APC UPS is having battery issue and apparently we cannot change battery in that UPS. (not super green?) I have purchased an EATON UPS and added the ref in ups.conf When restarting the driver, I got this error > 0.030612 [D2] Checking device 2 of 10 (0463/FFFF) > 0.287659 [D2] - VendorID: 0463 > 0.287853 [D2] - ProductID: ffff >

The "unknown" fields mean the driver did not get that piece of information from libusb. In case of Manufacturer/Product which are unknown in the later post, but known in the first, I suppose you had another driver running, or the kernel still owned it (udev misbehavior, not handing it off after reconnections, etc.) and so exclusive access was not given to the new (currently reporting)

Hi all, I am trying to communicate to this Eaton Ellipse (see above) using nut from a Debian Squeeze system on Armel architecture. But have not succeeded so far. Version: Linux b3 2.6.39.4-11 #1 Tue Apr 3 21:45:12 FET 2012 armv5tel GNU/Linux Nut version is 2.4.3-1.1squeeze2 this information if from dpkg. NUT installation method:from debian package for armel. The problem is I cannot