Specify systemd startup ordering separately from dependency requirements

Pulling another unit into a transaction does not automatically make it start first.

Resilient network core with engineered blue and gold data paths.
DSE visual intelligenceNetworks & infrastructureGuide · 2 min read
Executive summary

What you need to know

Pulling another unit into a transaction does not automatically make it start first.

Potentially affected

Review requirement dependencies and ordering using the systemd.unit manual packaged for Debian trixie.

DSE recommendation

DSE recommends writing down whether a dependency is mandatory, optional, or merely ordered before editing a unit.

Pulling another unit into a transaction does not automatically make it start first.

Source facts

The Debian systemd.unit manual distinguishes requirement dependencies from ordering. Wants and Requires can bring another unit into startup, but do not determine the order. After and Before configure ordering separately. The manual describes these controls as independent, allowing a unit to request another service and also specify that it start beforehand.

Source: Debian systemd manual — systemd.unit(5) — systemd — Debian trixie — Debian Manpages.

Applicability

Review requirement dependencies and ordering using the systemd.unit manual packaged for Debian trixie.

DSE recommendation

DSE recommends writing down whether a dependency is mandatory, optional, or merely ordered before editing a unit. Choose the requirement relationship and ordering relationship intentionally instead of assuming one implies the other. Avoid replacing application connection retries with an ever-longer boot sleep. Inspect implicit dependencies and drop-ins as well as the main unit file. Keep the effect of a dependency failure in the operational record so an optional monitoring service does not accidentally become a hard prerequisite for a critical application.

Verification

In a nonproduction service pair, inspect effective dependencies and observe startup with the dependency healthy, delayed, and unavailable. Confirm the resulting behavior matches the intended requirement strength. Verify application readiness separately from the manager’s unit-start completion before authorizing the production change. Retain the effective unit and drop-ins with the observed start sequence. Have the service owner approve the unavailable-dependency result explicitly, including whether the main service should remain startable or fail with its prerequisite.

Official reference

Debian systemd manual — systemd.unit(5) — systemd — Debian trixie — Debian Manpages. Reviewed October 20, 2026.

Primary reference

Review the official source

Debian systemd manual — systemd.unit(5) — systemd — Debian trixie — Debian Manpages · Verified October 20, 2026

Open official reference ↗
Plan the next step

Need help applying this guidance safely?

DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.

Talk with DSE