similar to: [networkupstools/nut] Improve upssched example in documentation (#293) (fwd)

Hi Roger 2017-03-21 19:34 GMT+01:00 Roger Price <roger at rogerprice.org>: > On Tue, 21 Mar 2017, Arnaud Quette wrote: > > Hi Roger, >> >> reviving this discussion, since we have a Github ticket for 2.7.5: >> https://github.com/networkupstools/nut/issues/293 >> > ... > >> I've made some additions to clarify things on the timer, and complete

Hi Roger, reviving this discussion, since we have a Github ticket for 2.7.5: https://github.com/networkupstools/nut/issues/293 2016-06-05 12:34 GMT+02:00 Roger Price <roger at rogerprice.org>: > On Sat, 4 Jun 2016, Charles Lepple wrote: > > On Jun 3, 2016, at 6:48 AM, Roger Price <roger at rogerprice.org> wrote: >> >>> ... the timer. I don't see it in

On Tue, 21 Mar 2017, Arnaud Quette wrote: > Hi Roger, > > reviving this discussion, since we have a Github ticket for 2.7.5: > https://github.com/networkupstools/nut/issues/293 ... > I've made some additions to clarify things on the timer, and complete the script: > https://github.com/networkupstools/nut/compare/upssched-doc?expand=1 Hi Arnaud, Your change to the

Hi Arnaud, On Wed, 22 Mar 2017, Arnaud Quette wrote: > The technique is very general and is to send SIGUSR1/SIGUSR2 to the upsd daemon.? SIGUSR1 and SIGUSR2 are events just like ONBATT and ONLINE. > The patch runs successfully on my opensuse 13.2 box, and solves my problem. In upssched.conf I now have declarations such as > > ? ?AT SIGUSR1 * CANCEL-TIMER

On Sat, 4 Jun 2016, Charles Lepple wrote: > On Jun 3, 2016, at 6:48 AM, Roger Price <roger at rogerprice.org> wrote: >> ... the timer. I don't see it in /var/lib/ups where the locate tool >> finds upsd.pid, and I don't see it in /run or /var/run where I see >> upsmon.pid. >> > ... it seems that the timers are only stored in memory. See >

Hello, I am currently building a new server using debian amd64. Therefore I need to use my UPS EATON Evolution 1550 on it, using usbhid-ups driver. I installed nut with apt (version 2.4.3-1.1squeeze1) on debian 2.6.32-5 amd64. I can currently use nut with the drivers, upsc and upsmon: my UPS is detected and works. Actually everything works except upssched: I can shut down the server using

Thank you for answer Roger >?????, 13 ???? 2016, 11:49 +03:00 ?? Roger Price <roger at rogerprice.org>: > >On Wed, 13 Jul 2016, Dmitri Stepanov wrote: > >> Hi >> >> ?? I need to shutdown a number of hosts which has not NUT from one which has it. >> >> ?? I tried to do it from upssched script (after upssched's timer) like this: >> >>

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

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

On Wed, 13 Jul 2016, Dmitri Stepanov wrote: > Hi > > ?? I need to shutdown a number of hosts which has not NUT from one which has it. > > ?? I tried to do it from upssched script (after upssched's timer) like this: > > case $1 in > ??????? earlyshutdown) > ??????????????? logger -t upssched-cmd "Early shutdown is started" > ??????????????? /bin/sh

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

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... determining that FD is to be reaped proved hard. Internet lore suggests fcntl() and poll() on the FD, but it just seems valid to them. The errno is also usually not raised (once I saw a "111: Connection refused" though). So the best dumb idea so far is to bail out if we spent the whole loop (128 attempts) and only got zero-sized read replies and no errors.

So... determining that FD is to be reaped proved hard. Internet lore suggests fcntl() and poll() on the FD, but it just seems valid to them. The errno is also usually not raised (once I saw a "111: Connection refused" though). So the best dumb idea so far is to bail out if we spent the whole loop (128 attempts) and only got zero-sized read replies and no errors.

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