2.1 The Service

2.1.1 The service definition seed #

resolvd is started by peinit from Machine\System\Services\resolvd. The package ships the definition as a registry seed, /usr/share/regim/resolvd-service.reg, which is inert until an image names it in its [registry] autoapply list.

2.1.2 The service definition values #

ValueTypeDataEffect
ImagePathREG_SZ/usr/sbin/resolvdThe binary. resolvd reads no command-line arguments.
TriggersREG_MULTI_SZbootStarted at boot.
IdentityREG_SZServiceRuns under its own virtual service account.
ReadinessREG_DWORD0Notify: ready when resolvd says so.
RuntimeDirectoriesREG_MULTI_SZresolvdpeinit creates /run/resolvd.
RestartPolicyREG_DWORD2Always restarted.
LimitNOFILEREG_DWORD16384Descriptor headroom for 4 096 upstream transactions, their client waiters, 512 pending clients and daemon descriptors.
ErrorControlREG_DWORD0
DisplayNameREG_SZStub resolver
DescriptionREG_SZ(one sentence)

2.1.3 Identity and privilege #

resolvd holds no privilege and needs none. Its one claim on the machine that an ordinary process could not make — binding UDP and TCP port 53 — is met by a port reservation rather than a capability (PSPU §6.8).

Without the reservation applied, the stub listener cannot bind and resolvd exits at startup (§2.2, §9.3).

2.1.3.1 The port reservation seed #

The reservation is a second seed, /usr/share/regim/resolvd-port.reg, also inert until an image applies it. It writes one value:

KeyValueType
Machine\System\Network\TcpIp\PortReservationstcp,udp:53REG_BINARY

2.1.3.2 Who holds the reservation #

The data is a security descriptor granting the reservation to SYSTEM and to resolvd's service SID, S-1-5-80-3864064249-1823296737-2008945602-1354971773-2894779966, so it follows the service rather than whichever account the service happens to run as.

The selector tcp,udp:53 is more specific than the kernel package's tcp,udp:1-1023 and so decides port 53 alone. The descriptor bytes are generated from the SID by a tool in the source tree, not written by hand.

2.1.4 Readiness #

With Readiness 0 peinit waits for a notification. resolvd:

  • sends the datagram READY=1 to the socket named by the NOTIFY_SOCKET environment variable once the native socket and both stub sockets are open and the registry has been read;
  • does not wait for netd: readiness is sent after the first attempt to reach netd whether that attempt succeeded or not;
  • sends nothing when NOTIFY_SOCKET is unset, and logs a failure to send as readiness notify: <error> and carries on starting.

2.1.5 Restart #

RestartPolicy 2 restarts resolvd whenever it exits. A restarted resolvd removes the socket file its predecessor left, logs removed a stale /run/resolvd/resolv.sock, and binds a fresh one (§2.4). Everything resolvd holds is in memory, so a restarted resolvd has:

  • an empty cache;
  • no demoted servers;
  • every counter at zero (§4.10);
  • no scopes, and the kernel's hostname, until the first snapshot after netd is reached again (§3.3).

2.1.6 Log lines #

2.1.6.1 The log line format #

Every line resolvd logs has the form

resolvd: <level>: <text>

where the level is info, warn or error. Informational lines go to standard output; warnings and errors go to standard error. peinit forwards both streams to eventd, marking only standard error as is_error=true. The lines are read with:

evctl 'LOGS FROM resolvd SINCE 1h ago TAKE 40'

2.1.6.2 The kernel log mirror #

Each line is also offered to /dev/kmsg, at kernel priority 6, 4 or 3 for info, warn and error. The mirror is opened when the first line is logged, after that line has been written to its output stream, and the open is never retried.

/dev/kmsg is writable by SYSTEM only, so for resolvd the open fails, and resolvd writes one line to standard error saying so, directly after the first log line:

resolvd: warn: /dev/kmsg mirror unavailable (<error>): log lines go to stdout/stderr only

The mirror warning follows the first log call. That first line may be on stdout or stderr, so readers must not assume a cross-stream ordering. On a start that fails, the first logged line is the fatal one, such as native socket: <error> (§2.4). On a start that succeeds, it is a warning from earlier in startup when there is one, such as removed a stale /run/resolvd/resolv.sock (§2.4) or a Dns … warning (§2.3), and otherwise the result of the first attempt to reach netd, subscribed to netd or netd not reachable (<error>); retrying, which comes before listening on … (§2.2). The mirror line is written once, and nothing further about the mirror is written. resolvd's lines never reach the console or dmesg.

Edit this page