search for: us_max_read

...cted behavior, or that it for some reason decides that the FD #7 (whoever that is) raised the hand but was then silent (0 bytes read). The next clue is 128 reads, which leads to https://github.com/networkupstools/nut/blob/v2.8.0/clients/upssched.c#L485 `sock_read()` method which indeed does up to `US_MAX_READ==128` attempts to read one byte from a connection (so from the CLI/child counterpart) at a time - so that is who FD#7 gotta be. So it is just at this point that I get stuck explaining what happens and why :) Possibly there was a child or CLI counterpart process which died and somehow the connectio...

...cted behavior, or that it for some reason decides that the FD #7 (whoever that is) raised the hand but was then silent (0 bytes read). The next clue is 128 reads, which leads to https://github.com/networkupstools/nut/blob/v2.8.0/clients/upssched.c#L485 `sock_read()` method which indeed does up to `US_MAX_READ==128` attempts to read one byte from a connection (so from the CLI/child counterpart) at a time - so that is who FD#7 gotta be. So it is just at this point that I get stuck explaining what happens and why :) Possibly there was a child or CLI counterpart process which died and somehow the connectio...

...t for some reason decides that the FD #7 (whoever that > is) raised the hand but was then silent (0 bytes read). > > The next clue is 128 reads, which leads to > https://github.com/networkupstools/nut/blob/v2.8.0/clients/upssched.c#L485 > `sock_read()` method which indeed does up to `US_MAX_READ==128` attempts to > read one byte from a connection (so from the CLI/child counterpart) at a > time - so that is who FD#7 gotta be. > > So it is just at this point that I get stuck explaining what happens and > why :) Possibly there was a child or CLI counterpart process which died a...

...t for some reason decides that the FD #7 (whoever that > is) raised the hand but was then silent (0 bytes read). > > The next clue is 128 reads, which leads to > https://github.com/networkupstools/nut/blob/v2.8.0/clients/upssched.c#L485 > `sock_read()` method which indeed does up to `US_MAX_READ==128` attempts to > read one byte from a connection (so from the CLI/child counterpart) at a > time - so that is who FD#7 gotta be. > > So it is just at this point that I get stuck explaining what happens and > why :) Possibly there was a child or CLI counterpart process which died a...

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,