Thanks for the feedback.
Just the bit about "when provided by Debian" concerns me - we have a
slow-ish cadence of releases, and then distros take another year to ship
them :\
You might be reasonably served by a custom build (in-place or even
package). YMMV...
Jim
On Tue, Jun 13, 2023, 18:38
Hi,
I ran the strace command while upssched was 100% CPU hungry. This is what I got:
1686633611.702798 read(7, "", 1)= 0 <0.04>
1686633611.702816 read(7, "", 1)= 0 <0.04>
1686633611.702834 pselect6(11, [7 10], NULL, NULL, {tv_sec=1, tv_nsec=0}, NULL)
= 1 (in [7], left
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
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
Hi,
Thanks Jim! Here is more system information from the commands you mentioned.
Kari
root@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
FWIW, cross-posted the issue to NUT GitHub tracker:
https://github.com/networkupstools/nut/issues/1964
Jim
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
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/550064930e369fb3a322c3b288b4acf53532
which added a `sock_read()` loop continuation effectively if `pconf_char()`
returned 0.
Thanks for the interesting puzzle to crunch!
Looking at these few bread-crumbs, I wager an educated guess that this
loops in `sendcmd()` (where CLI child processes talk to a daemonized copy
which tracks the timers for events), around here:
