search for: upsmons

Hello! I try use NUT on some servers. When i use this package on x64 Windows 2003 servers, upsmon hangs on with error: Faulting application upsmon.exe, version 0.0.0.0, faulting module upsmon.exe, version 0.0.0.0, fault address 0x0000458f. I try use another server, on 32-bit all is ok. Problem only on x64 platform (maybe in libusb)? And no different - upsmon master or slave. C:\Program Files

Hi; I have ran into an issue with the upsmon tool leaking memory over a two month period. It seems to be due to one of my UPS hosts offline. System is a debian stable with the default nut package. Here's the data so far: companyfs1:/var/log# ps aux | grep [n]ut nut 2439 0.0 3.6 380800 18800 ? S Jun05 6:41 /sbin/upsmon >From my logfiles its failing on one of my UPS

This will sound a bit odd. I have a current server running with a UPS. I'm in the process of replacing that server with another and obviously want Nut to monitor the new server. The new/old servers are in different locations, so I don't have access to the UPS while configuring the replacement server. I think I have the config ok, but what errors would you expect to see? Typically I'm

Hi All, I have noticed these messages in my logs: ========================================= Sep 01 13:14:22 osmc upsd[1450]: listening on 127.0.0.1 port 3493 Sep 01 13:14:22 osmc upsd[1450]: listening on ::1 port 3493 Sep 01 13:14:22 osmc upsd[1450]: listening on 127.0.0.1 port 3493 Sep 01 13:14:22 osmc upsd[1450]: listening on ::1 port 3493 Sep 01 13:14:22 osmc upsd[1450]: Connected to UPS

I deleted the plist file and rebooted: sudo /sw/sbin/upsmon -D Network UPS Tools upsmon 2.7.4 0.000000 fopen /sw/var/run/upsmon.pid: No such file or directory 0.044649 UPS: ups at ip address (slave) (power value 1) 0.081597 Using power down flag file /etc/killpower 0.162720 debug level is '1' 0.538410 Trying to connect to UPS [ups at ip address] 0.540345 Logged into UPS

hello, i have an apc smt750i with 3 debian computers connected to it. i want one of them act as a master to notify the other two in case the battery is about to exhaust. upsmon in the slaves gets notified when the system changes from main to battery and viceversa. the problem i have is that the slaves are not notified and shutdown because of losing the connection to the master, but not for

Short description: when upsmon starts it logs this to /var/log/messages: Jul 11 12:35:55 sorcerer upsmon[23902]: Startup successful Jul 11 12:35:55 sorcerer upsmon[23902]: user monuser not found Near as I can tell upsd is running properly. Long description: Centos 5 system (x86_64), built nut 2.2.2 from stable source with ./configure --with-usb --with-user=nut --with-group-nut make

Hello, I had a brief power fluctuation earlier, which caused the UPS to power up a few seconds. Then suddenly NUT was busy shutting down my server, after full power had already been restored. Here's the logs: Jun 6 13:28:30 hell upsmon[607]: UPS apc620 at localhost on battery Jun 6 13:28:35 hell apcsmart[602]: Communications with UPS lost - check cabling Jun 6 13:28:35 hell upsd[604]:

Centos5 NUT 2.6.5, compiled from source I was reminded by a previous thread about a message I get when starting NUT... Starting upsd: fopen /var/run/nut/upsd.pid: No such file or directory Starting upsmon: kill: No such process upsd removes its pid files when it's stopped, upsmon does not. If I remove upsmon's manually after stopping it, I get a different message for it when I start

But /etc/nut/upsmon.conf has the correct username and password. returns: gene at coyote:/usr/share/doc/nut-doc/pdf$ upsmon myups at localhost Network UPS Tools upsmon 2.6.4 kill: Operation not permitted /etc/nut/upsmon.conf line 75: invalid directive [*****] /etc/nut/upsmon.conf line 76: invalid directive password = ************** /etc/nut/upsmon.conf line 77: invalid directive upsmon master UPS:

I just did a fresh installation of Debian Jessie on one of my servers, but NUT won't configure and install. When I try to install, I get the following: Setting up nut-client (2.7.2-1+b2) ... Job for nut-monitor.service failed. See 'systemctl status nut-monitor.service' and 'journalctl -xn' for details. invoke-rc.d: initscript nut-client, action "start" failed.

On Thu, 6 Aug 2020, Todd Benivegna wrote: > ... I grep’d the syslog and here’s the results: Could you also grep for upsd and upsmon in the NAS log? Is this possible? > proton at proton:~$ sudo grep upsmon /var/log/syslog > Aug  6 19:19:09 proton upsmon[1552]: UPS ups at 192.168.1.70 on battery > Aug  6 19:19:14 proton upsmon[1552]: UPS ups at 192.168.1.70 on line

Ok rebooted All running ok now. Great thanks a lot! In system.log Jun 15 21:38:54 c01 com.apple.xpc.launchd[1] (org.networkupstools.upsmon): Unknown key for Boolean: SuccessfulExit Jun 15 21:38:54 c01 com.apple.xpc.launchd[1] (org.networkupstools.upsmon): This service is defined to be constantly running and is inherently inefficient. What is the purpose of Boolean: SuccessfulExit?

Here are the results of a restart as well as a stop/start. Seems like it may be the server? I tried to run the nut-server service with gdb, but no luck getting it to work so far. Thanks! ________________________________ From: Charles Lepple <clepple at gmail.com> Sent: Wednesday, October 12, 2016 8:20 PM To: Daniel Shields Cc: nut-upsuser at lists. alioth. debian. org Subject: Re:

Hi Charles, Thanks for your help. Seems to be mostly ok except am getting error access denied. See below. I see from searching this is a common error but so far I can't find a fix. This is how I configured things before make and install. created group nut nut:x:103: created system user ups with group nut. ups:x:123:103::/home/ups:/bin/bash Create statepath directory. sudo mkdir -p

On Jun 11, 2017, at 7:15 AM, Robbie van der Walle <rvanderwalle at gmail.com> wrote: > > I see only a reboot. Not a shutdown. But is this normal because shutdown -u -h +0 is used? > To be honest, I haven't experimented much with this, but I saw a normal shutdown/reboot when I just tried this from the command line (10.12): reboot ~ Mon Jun 12 08:36

On Saturday, 1 September 2018 17:50:13 BST Charles Lepple wrote: > I don’t have the code in front of me at the moment, but my guess is that the > config parser stopped parsing at the “#” character. I suspected a rogue character was being interpreted and used `backticks`, 'single quotes' and then "double quotes", but all failed. I ended up removing the offending #

Hello, I've installed Nut (2.0.5) on RedHat a week ago, and upsmon seems to generate false alarms every hour: ... Jun 8 06:10:56 nutevalserver upsmon[2849]: UPS usb-mge-evolution at localhost on line power Jun 8 06:35:46 nutevalserver upsmon[2849]: UPS usb-mge-evolution at localhost on battery Jun 8 06:35:51 nutevalserver upsmon[2849]: UPS usb-mge-evolution at localhost on line power

> grep nut /etc/passwd nut:x:129:134::/var/lib/nut:/usr/sbin/nologin > In your manual test do you restore utility power after 3-5 seconds? Yes, I have tried that.  I have also tried less than one second.  I’ve tried for 1-2 minutes, for 3-5 minutes, I’ve tried just about every length of time and all appears Ok when I manually test. -- Todd Benivegna // todd at benivegna.com On Aug 5,

Hello all, I have been having a problem with upsmon on Fedora 24 on boot. NUT is configured as a netclient to a Raspbian NUT server. After boot up upsmon repeatedly says "connect failed: No such host". It is not able to connect at all until the service is bounced. This seems to indicate a name resolution problem but shouldn't this auto correct once name resolution is working properly