Module accept 

Accept-loop health for the listeners that perform a real accept(2).

A listener loop cannot treat every accept failure the same way. The errnos accept returns mix two families that want opposite handling, and getting them backwards is not symmetric: pausing after a dead connection punishes the connections queued behind it, while retrying instantly after fd exhaustion is a hot loop burning the CPU the process needs in order to recover. Failure is that classification and Health applies it, so a listener’s failure arm is one call rather than a policy each caller re-derives.

Health is also the only thing that leaves the process when a listener goes dark. The loops here never give up (an accept loop is a process-lifetime supervisor with nobody to return an error to), so a node can be unable to accept a single TCP connection while every other signal looks healthy. The cumulative counters are the load-bearing half rather than stalled: a process with no descriptors left cannot serve a metrics scrape either, so the episode is often only visible once it is over, and a gauge read after recovery reads a healthy nothing while a counter still shows the jump.

Only a listener that performs a real accept(2) has anything to report here. The QUIC backends multiplex every session over one UDP socket, so they never call accept and exhaustion cannot reach them; registering one would publish a permanently-zero counter, which reads as a watch that is passing when it is really a watch that can never fire.

Structs

Health

One listener’s accept-loop health: how to react to a failure, and what a supervisor outside the process can read back.

Enums

Failure

What a failed accept(2) means for the listener that saw it.