systemd dependencies: separate unit ordering from application readiness

Last updated: 5 Oct 20267 min read

tutorial

A systemd unit can pull another unit into a start transaction and order itself relative to it, but those are different relationships. Wants and Requires express activation dependencies; After and Before express ordering. After alone does not start the named service, and a started dependency may still be unable to serve an application request. Type=simple can report a service start before its process has finished initializing. A daemon that supports Type=notify can report readiness after its own initialization; otherwise the application needs a specific health check before downstream traffic is admitted. A retrying client should also tolerate later dependency outages after boot.

Operational decision

A settlement API needs a local certificate agent and a reachable database. It starts after the certificate unit, but does not assume that unit success guarantees a valid certificate. The API verifies its credential file, makes a bounded database connection attempt, and reports ready only after both checks pass. If the database is remote, the deployment avoids inventing a local systemd unit dependency for it. The operator tests boot with the certificate unit delayed, a database accepting TCP but rejecting authentication, and a database outage after startup. The service should either remain not ready or fail visibly; it must not enter the load balancer merely because systemctl reports active.

[Unit]
Wants=certificate-agent.service
After=certificate-agent.service
[Service]
Type=notify
ExecStart=/opt/settlement/bin/settlement-api
Readiness signal: sent only after credential and database checks

Cost and verification

Stronger dependency wiring can propagate failures or create ordering cycles; weak wiring may require application retries. Type=notify requires the process to implement the notification protocol, so changing only the unit file can leave startup waiting until timeout. Measure cold start, dependency recovery, and readiness transitions. A boot test must check a real user path, not merely a green unit status. Preserve a bounded startup timeout and a clear failure log so operators can distinguish unavailable dependencies from a deadlocked application.

Common Mistakes

Do not expect After to start its named unit.
Do not treat active as proof of application readiness.
Do not set Type=notify unless the process sends readiness notifications.

Connected lessons

Practice and check

Linux storage follow-up

Linux mount boot contracts: prevent a service from writing into an empty mountpoint

devops

systemd

linux-services