3.2 Reconnection and Backoff

3 min read

Failure and reconnection are covered by PSPU §6.9. resolvd's backoff starts at 0.5 seconds and doubles to a ceiling of 10 seconds.

3.2.1 The backoff sequence #

The first attempt is made during startup, before readiness (§2.2). Each failed attempt schedules the next one the current backoff later, then doubles the backoff up to 10 seconds. Measured from a first attempt that fails, attempts are made at:

3.2.2 The unreachable warning #

A failed attempt made before any connection has succeeded is logged as netd not reachable (<error>); retrying when it is the first failure, and not logged otherwise. Together with the rule after a loss (below), the warning is written at most once in the life of the process: for the first failure, when that failure comes before the first successful connection. A resolvd whose first attempt succeeds never writes it.

3.2.3 A good snapshot resets the backoff #

A successfully decoded snapshot resets the backoff to 0.5 seconds. Connecting, writing the subscription, or receiving another reply kind does not reset it. A partial snapshot does not reset it until complete.

3.2.4 After a loss #

When an established channel is dropped (§3.1):

• the next attempt is due after the current backoff, then the delay doubles up to 10 seconds. After a channel that delivered a snapshot, successive gaps are 0.5, 1, 2, 4, 8, then 10 seconds. A connection lost before its first snapshot continues the existing sequence;
• the netd not reachable warning is not logged for the failures that follow, however many there are; the lost the netd channel; reconnecting line that preceded them is the record.

3.2.4.1 A refused subscription also backs off #

A netd that accepts the connection and then answers the subscription with an error has not delivered a snapshot. Its retries follow the same growing delay, up to ten seconds, as other failures. Each connection still logs subscribed to netd at info level and two warnings (§9.4). An accept-then-close or malformed reply likewise preserves the growing delay until a good snapshot arrives.

3.2.5 Disconnected from netd #

Losing netd changes nothing in the engine. The scopes from the last snapshot, the hostname taken from it, and every cached answer stay in use until the next snapshot replaces them; questions are answered exactly as before, and the servers in those scopes are still asked. status reports netd as false (§5.3).

3.2.6 Before the first snapshot #

When resolvd has never received a snapshot it has no scopes. It answers synthetic and static names, uses the fallback servers if any are configured, and answers everything else unavailable (§4.4).

Edit this page