[Nut-upsdev] [Nut-upsuser] Upssched 100% CPU after updating Debian 12

[Jim Klimov]

Thanks for the insight.

I can't quickly make a value judgement on the choice of non-blocking mode -
existing NUT codebase uses both O_NDELAY (seemingly in code dealing with
Unix or TCP sockets, including the case here with upssched daemon/CLI
interactions) and O_NONBLOCK (seemingly for serial-port connections, and
for TCP sockets in nutclient.cpp `Socket::connect()` and upsclient.c
`upscli_tryconnect()`).

Otherwise, what you describe as poll() returning no error and read()
returning a 0 - that does match the situation I see.

My memory is vague on what @dtsecon tried to achieve in PR 1274 by adding
this line to `if (ret==0) continue` (possibly worked around some delays?
are those possible after the select() says the FD is ready?) - and so if
that use-case gets broken again by bailing out quickly here. I guess my
proposal in https://github.com/networkupstools/nut/pull/1965 - which is to
only immediately abort if explicit errors are seen, and abort after trying
to read() hard enough - is sort of best of two worlds, or least-worst :)
WDYT?

Jim


On Wed, Jun 14, 2023 at 3:15 PM Sam Varshavchik <mrsam at courier-mta.com>
wrote:

> Jim Klimov via Nut-upsuser writes:
>
> > 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.
>
> It's been my experience, that the path of least resistance is:
>
> 1) The sockets are sets to be non-blocking
> 2) poll()
> 3) If poll() says the socket is readable, and read() returns <= 0, then
> the
> socket is dead. You get no error, and read() returns 0, if the socket had
> an
> orderly shutdown.
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230614/e0190656/attachment.htm>