similar to: Stopping dummy ups from broadcasting messages

On Fri, 16 Feb 2024, Dan Grostick via Nut-upsuser wrote: > Is there any way to stop dummy ups from continuously broadcasting status? > (onbatt)? I want to keep the broadcasts from the ups itself. Could you show us your entry in ups.conf for the dummy ups ? If you have an entry "port = file" in that section of ups.conf, could you show us the contents of "file" ?

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

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

On Fri, 16 Feb 2024, Dan Grostick wrote: > [heartbeat] > driver=dummy-ups > port=heartbeat.conf > mode=dummy-once > desc= "Heart beat verfication of NUT" I would be interesting to see the file heartbeat.conf and the NOTIFYFLAG declarations in upsmon.conf . See also chapter 6.3 "Configuration file upsmon.conf for workstation with heartbeat" in

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

Thanks for the tip. I had downloaded a prerelease source version of NUT 2.8.1, built and installed it. Evidently there was an issue with upssched consuming 100% CPU. I downloaded the current release and the issue has been resolved. Updating all 3 systems. Dan ________________________________ From: Nut-upsuser <nut-upsuser-bounces+danpower2023=outlook.com at alioth-lists.debian.net> on

NUT 2.8.01 When I pull the USB cable from the UPS, I get two notifications of the nocomm-timer expired. The first notification is in the proper sequence, the second notification occurs after 'commok' occurs. Seems somehow that upssched-cmd is getting a second nocomm-timer expired delayed. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Fri, 29 Mar 2024, Dan Grostick wrote: > It is consistently happening 14-15 minutes after starting. Please see attached > upssched-cmd and upssched.conf. I don't have a upssched.cmd. The binary > upssched is used. After the heartbeat failure, is upsd still running? Does the command "upsc -L" report the UPS's? If you use systemd, what does the command

Maybe...ish - I haven't seen those for a while, but had few outages either. Can you check if the updated (root) user profile or default profile(s) under /etc mention `mesg n` or similar means of limiting broadcasts? In your manual `wall` executions, do you see them in the same terminal that sent the message, or on all terminals (GUI, SSH sessions)? As root or as any user (as recipient and as

On Thu, 28 Mar 2024, Dan Grostick via Nut-upsuser wrote: > All three systems have a heartbeat-timer failure approximately 15 minutes > after starting NUT. No subsequent failures. Any ideas on what is happening? I've seen the timers: heartbeat.conf has two 300 sec timers, upssched.cmd looks like what is often called upssched.conf and has a 660 sec timer. So it looks as if the

Hello, I'm using nut with my MG Ellipse on serial port. No problem since one year. Two days ago, I wanted to add a phone alert through my asterisk box when power is down. Since then, upssched doesn't make his job anymore. here is the "syslog" I get when the power cord is unplugged : > > May 9 11:39:34 serveur upsmon[6411]: UPS ellipse@localhost on battery > May 9

Hello All, I'm trying to establish a MASTER SLAVE configuration of UPS using NUT Driver. I'm able to shutdown the master after UPS is on BATTERY ( POWER BLACKOUT) .However I'm trying to shutdown the other SLAVE MACHINES BEFORE MASTER. But at the remote side ( Slaves ) shutdown after UPS blackout does not happen. My configuration in Master are /usr/etc/upsd.users

Hi Roger, I get: Apr 27 20:50:05 unifi upsmon[1022]: UPS ups on batteryApr 27 20:50:05 unifi upssched[2688]: Timer daemon startedApr 27 20:50:06 unifi upssched[2688]: New timer: onbatt (20 seconds)Apr 27 20:50:26 unifi upssched[2688]: Event: onbattApr 27 20:50:26 unifi upssched[2688]: exec_cmd(/sbin/upssched-cmd.sh onbatt) returned 126Apr 27 20:50:41 unifi upssched[2688]: Timer queue empty,

Hi all, I've not been able to find the answer to my timer problem in the faq or the archives. (or google) Basically, I can't get timers to fire. They fire ignoring the timer value, as if the timer was set to 0. I'm using the OpenFiler distribution, patched to the latest and greatest. upsmon 2.2.2 When I pull the power plug, I see the text "Im In Battery" instantly, instead

Hello, I have noticed that (apparensly) since Debian 12 upgrade the WALL commands for upsmon.conf don's seem to work. To test I have configured upsmon-dummy.conf to debug this: NOTIFYCMD /usr/sbin/upssched NOTIFYFLAG ONBATT SYSLOG+EXEC+WALL NOTIFYFLAG ONLINE SYSLOG+EXEC+WALL the /usr/sbin/upssched gets called: /lib/nut/upsmon -D -D -D -D -f /etc/nut/upsmon-dummy.conf and I

On Mar 8, 2024, at 8:22?AM, Dan Grostick via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> wrote: > > I've installed 2.8.1 on a Raspberry PI 5 using Pi OS bookworm 64 bit (Debian 12) with success. > > When I take that same configuration to a PI 3B running bookworm 32 bit, compile from source, use the same files from /etc/nut, I get a 'nut-monitor ups at

On Tue, 4 Apr 2017, Arnaud Quette wrote: > Hi Jon, Stuart and the list > > 2017-04-04 1:09 GMT+02:00 Stuart Gathman <stuart at gathman.org>: > Which NOTIFYCMD is run when there is an ALARM? > Have you specified that in your upsmon.conf? > > And that is the question of the hour.? How do you specify that?? Note > that this is not the REPLBATT

Hi, I have been running nut successfully for a long time with my Debian 11 server. I upgraded my server to Debian 12 today, which upgraded nut also from 2.7.4-13 to 2.8.0-7. I noticed that after upgrade there was a upssched process running and taking 100% cpu time. I checked if there were any changes to configuration file formats with nut upgrade and only differences I noticed were a terminology

Is there a script to check that the automatic shutdown and logging configuration is set right? I had hoped I set it up right to at least log when it goes and off battery but I guess I missed something. /etc/nut# grep upssched /var/log/syslog Apr 3 12:31:06 gw upssched[12732]: Timer daemon started Apr 3 12:31:06 gw upssched[12732]: New timer: onbatt (30 seconds) Apr 3 12:31:36 gw