15 Running rgbdns under supervision

15.1 The service contract

rgbdns daemons run in the foreground, emit diagnostics to standard error, take configuration from files and environment, and terminate on fatal startup errors. That is the portable contract a supervisor needs. The generated djbdns-style directories additionally provide run and log/run programs, but the daemon binaries do not require a particular supervisor.

The classic daemontools control plane is:

supervise service/       keep one process running
svc -u service/          bring it up
svc -d service/          bring it down
svc -t service/          send TERM
svstat service/          inspect status

No modern replacement is universally best. Choose according to the host and the migration boundary.

15.2 Recommendations

15.2.1 Existing Linux host: systemd

Use systemd when the machine already boots and manages services with systemd. It supplies dependency ordering, restart policy, socket and readiness models, resource controls, credential and filesystem sandboxing, a unified journal, and distribution-native administration. Avoid wrapping an rgbdns daemon in a second nested supervisor.

A minimal authoritative unit is:

[Unit]
Description=rgbdns authoritative DNS
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=dns
Group=dns
Environment=IP=192.0.2.53
Environment=PORT=53
Environment=DATA=/etc/rgbdns/data.cdb
ExecStart=/usr/local/bin/tinydns
Restart=on-failure
RestartSec=1s
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadOnlyPaths=/etc/rgbdns
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Prefer a socket above 1024 or a narrowly bounded bind capability over running the daemon as root. Test hardening settings on the target distribution because name-service libraries and trust-anchor paths may require additional read-only access.

Command mapping:

daemontools	systemd
`svc -u service`	`systemctl start service`
`svc -d service`	`systemctl stop service`
`svc -t service`	`systemctl kill --signal=TERM service`
`svc -h service`	`systemctl kill --signal=HUP service`
`svstat service`	`systemctl status service`
`multilog` output	journal, or explicit file logging policy

15.2.2 Closest service-directory migration: runit

Use runit when you want the smallest conceptual migration from daemontools. It uses a service directory with a run program, keeps the supervised process in the foreground, has a companion log service, and exposes the compact sv control command. Existing rgbdns generated run scripts are close to the required shape; adjust the directory layout and enablement symlink for the distribution.

daemontools	runit
`svc -u service`	`sv up service`
`svc -d service`	`sv down service`
`svc -t service`	`sv term service`
`svstat service`	`sv status service`

Choose runit for minimal hosts, appliances, or migrations where preserving the service-directory model matters more than rich dependency and sandbox policy.

15.2.3 Strong supervision composition: s6 and s6-rc

Use s6 when precise process supervision, reliable readiness, and composable small tools are primary requirements. Its s6-supervise and s6-svc are close in spirit to supervise and svc; s6-rc adds declared dependencies and transactional service-state changes. The ecosystem is particularly effective in carefully constructed containers and small systems, but its compilation and directory conventions make migration more involved than runit.

daemontools	s6
`supervise service`	`s6-supervise service`
`svc -u service`	`s6-svc -u service`
`svc -d service`	`s6-svc -d service`
`svc -t service`	`s6-svc -t service`
`svstat service`	`s6-svstat service`

Choose s6/s6-rc when the team is willing to own its service database and wants more rigorous dependency transitions than ad hoc shell orchestration.

15.2.4 OpenRC and container orchestrators

On an OpenRC-based distribution, use the native init integration unless there is a deliberate reason to introduce another supervision tree. OpenRC service scripts can use its supervisor support while retaining distribution-standard boot ordering and administration.

In Kubernetes or a similar orchestrator, run one foreground rgbdns daemon per container and let the platform own restart, health, resource limits, log collection, and rollout. Use a Deployment for tinydns or dnscache, a Service for stable network reachability, readiness/liveness probes that test the intended DNS role, ConfigMaps or mounted immutable CDBs for public data, and Secrets for sensitive material. Do not put systemd, daemontools, and the orchestrator around the same single process.

An s6-based container is reasonable only when one image intentionally contains several cooperating long-lived processes and that tradeoff is explicit.

15.3 A practical selection rule

Use this order:

Follow the host’s native manager: systemd on systemd hosts, OpenRC on OpenRC hosts.
For a direct service-directory replacement, choose runit.
For a designed supervision graph or multi-process container, choose s6/s6-rc.
In an orchestrated single-process container, use the orchestrator.

The least risky migration preserves one owner for restart policy and logs. Running two supervisors creates ambiguous signal paths, duplicate restarts, and status commands that disagree.