similar to: Upssched 100% CPU after updating Debian 12

Hi, I ran the strace command while upssched was 100% CPU hungry. This is what I got: 1686633611.702798 read(7, "", 1) = 0 <0.000004> 1686633611.702816 read(7, "", 1) = 0 <0.000004> 1686633611.702834 pselect6(11, [7 10], NULL, NULL, {tv_sec=1, tv_nsec=0}, NULL) = 1 (in [7], left {tv_sec=0, tv_nsec=999998800}) <0.000006> 1686633611.702862 read(7,

Hi, I ran the strace command while upssched was 100% CPU hungry. This is what I got: 1686633611.702798 read(7, "", 1) = 0 <0.000004> 1686633611.702816 read(7, "", 1) = 0 <0.000004> 1686633611.702834 pselect6(11, [7 10], NULL, NULL, {tv_sec=1, tv_nsec=0}, NULL) = 1 (in [7], left {tv_sec=0, tv_nsec=999998800}) <0.000006> 1686633611.702862 read(7,

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

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

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

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

Yes, that was the power off test. However the upssched-cmd script gave absolutely no signs of activity. Even it's logger lines don't show up in journalctl. No any permission error messages - nothing. Only the 2 messages from upsmon - on battery and then on line power. Here is the nut-report: http://www.filehosting.org/file/details/518300/NUT.report --- George Anchev On Tue, Oct 27,

On Thu, 8 Jun 2017, Robbie van der Walle wrote: > The "upsrw" command contacts upsd, so it sounds like you should be able to add a user to upsd.users on the NAS, and then run something like > this on the Mac: > > ??upsrw -s battery.charge.low=80 -u upsmaster -s sekret UPS at synology > > Per?http://networkupstools.org/docs/man/upsd.users.html?,

Here is the previous email that I sent directly to Charles Lepple. ?I am now sending to the correct email with cc to Charles. ---------------- I am looking at, and trying to understand the rest of the conf files. ?But first want to askabout something from this message:[CODE]root at debian:/home/john# upsdrvctl startNetwork UPS Tools - UPS driver controller 2.7.2Network UPS Tools - Megatec/Q1

On Thu, 8 Jun 2017, Robbie van der Walle wrote: > After the first test and the NAS is restarted I had to change the > setting battery.charge.low again to 80? Does the NAS DSM reset battery.charge.low to 10 or is it internal to the UPS? You will have to experiment by disconnecting the UPS control lead from the NAS and connecting it (if possible) to the Mac. After setting to 80 and a

FWIW, I wonder if this is a fallout of PR #1274 : https://github.com/networkupstools/nut/pull/1274/files and specifically https://github.com/networkupstools/nut/commit/550064930e369fb3a322c3b28ffff8b4acf53532 which added a `sock_read()` loop continuation effectively if `pconf_char()` returned 0. Just grasping at straws here (since it is a change a couple of months before the release was cut),

FWIW, I wonder if this is a fallout of PR #1274 : https://github.com/networkupstools/nut/pull/1274/files and specifically https://github.com/networkupstools/nut/commit/550064930e369fb3a322c3b28ffff8b4acf53532 which added a `sock_read()` loop continuation effectively if `pconf_char()` returned 0. Just grasping at straws here (since it is a change a couple of months before the release was cut),

hello, i've got a problem with the notifycmd here is a part of my upsmon.conf : NOTIFYCMD /usr/local/ups/bin/nut_notify NOTIFYMSG ONLINE "UPS %s is getting line power" NOTIFYMSG ONBATT "UPS %s is on battery" NOTIFYMSG REPLBATT "The UPS %s battery is bad and needs to be replaced" NOTIFYMSG LOWBATT "UPS %s is being shutdown by the master" NOTIFYMSG FSD

Hello guys Yesterday i started do configure my Mustek Powermust650 with nut using the megatec_usb driver. Everything works fine except for the mailing when something happens. My upsmon looks like this: MONITOR powermust650 at localhost 1 local controller master MINSUPPLIES 1 SHUTDOWNCMD "/sbin/shutdown -h +0" NOTIFYCMD /root/upsmailer POLLFREQ 10 POLLFREQALERT 5 HOSTSYNC 15