similar to: Heartbeat timer failure 15 minutes after startup

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

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. Dan ________________________________ From: Nut-upsuser <nut-upsuser-bounces+danpower2023=outlook.com at alioth-lists.debian.net> on behalf of Roger Price via Nut-upsuser <nut-upsuser at alioth-lists.debian.net>

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. If you speed up the heartbeat by reducing the timers in heartbeat.conf from 300 to 150, and the timer in upssched.conf from 660 to 360, does the failure still occcur

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

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:

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

After launching the command several times, with debug (posted by new code in a new branch for the investigation) confirming that the same daemon handles operations from the new client instances, its strace now has numerous FDs to report after select() - so I guess it is a problem of detecting an exit of the counterpart. 0.000000 [D2] parse_at: is 'heartbeat at localhost' in AT

After launching the command several times, with debug (posted by new code in a new branch for the investigation) confirming that the same daemon handles operations from the new client instances, its strace now has numerous FDs to report after select() - so I guess it is a problem of detecting an exit of the counterpart. 0.000000 [D2] parse_at: is 'heartbeat at localhost' in AT

Hi, Great work Jim! I?m glad you could reproduce the problem and found a potential culprit. Just for my own interest I restored upsshed from my backups (version 2.7.4-13) and it seems to running ok, so no big runtime changes regarding that with Debian 12. It is not hogging CPU. From the daemon log the heartbeat seems to be working ok. Only difference between the old logs (pre Debian 12 update)

Hi, Great work Jim! I?m glad you could reproduce the problem and found a potential culprit. Just for my own interest I restored upsshed from my backups (version 2.7.4-13) and it seems to running ok, so no big runtime changes regarding that with Debian 12. It is not hogging CPU. From the daemon log the heartbeat seems to be working ok. Only difference between the old logs (pre Debian 12 update)

So, got some good news: I hear(*) I managed to reproduce the problem with current NUT master and an adapted copy of your posted configs and script :D Experimental debugging now sounds possible. (*) PC under the desk wails with all its cooling fans as soon as I started the client which spawned a daemon and itself had exited: $ UPSNAME=heartbeat at localhost NOTIFYTYPE=ONBATT

So, got some good news: I hear(*) I managed to reproduce the problem with current NUT master and an adapted copy of your posted configs and script :D Experimental debugging now sounds possible. (*) PC under the desk wails with all its cooling fans as soon as I started the client which spawned a daemon and itself had exited: $ UPSNAME=heartbeat at localhost NOTIFYTYPE=ONBATT

PI OS - Debian12 - Raspberry PI 5 NUT 2.8.1 I'm building from source just downloaded from GITHUB. The error when starting NUT: nut-monitor: /usr/sbin/upssched not found I did a 'find / ' and upssched is not in the filesystem. I've done a make clean, make uninstall. then autogen.sh, make, make install 1. is there an option to make that completely removes everything? In

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

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

Hi, Thanks Jim! Here is more system information from the commands you mentioned. Kari root at fricka:~# lsof -p 1716171 lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1002/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME upssched 1716171 root cwd DIR 8,2 4096 2 /

Hi, Thanks Jim! Here is more system information from the commands you mentioned. Kari root at fricka:~# lsof -p 1716171 lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1002/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME upssched 1716171 root cwd DIR 8,2 4096 2 /

Hi, On Tue, Mar 05, 2024 at 08:37:32AM +0000, Dan Grostick via Nut-upsuser wrote: > My Raspberry PI 3B was overheating - 70 degrees C. I used Top and > it turns out that upssched is taking 100% CPU. Debian 11 (PI Os). > I have two others running the same configuration, 2.8.1 with no > problems. I have no first hand knowledge of this issue, but in the change log for the 2.8.1

I have a Raspberry PI that I have connected to a Deltec UPS via serial (upscode2 driver). I had an older version of Rasbian running. The nut configuration worked fine but I had mail issues I couldn't resolve when gmail changed how it handled MTAs. Plus it was running an old version of Deb that is no longer supported. It was broken enough I could not upgrade to a never version so I started from