# Specify systemd startup ordering separately from dependency requirements

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

- Canonical URL: https://update.dsesecurity.com/updates/specify-systemd-startup-ordering-separately-from-dependency-requirements/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:15:21+00:00
- Modified: 2026-10-20T18:34:33+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## 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.

## Article

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](https://manpages.debian.org/trixie/systemd/systemd.unit.5.en.html).

## 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](https://manpages.debian.org/trixie/systemd/systemd.unit.5.en.html). Reviewed October 20, 2026.

## Primary reference

- Name: Debian systemd manual — systemd.unit(5) — systemd — Debian trixie — Debian Manpages
- Authority: manpages.debian.org
- URL: https://manpages.debian.org/trixie/systemd/systemd.unit.5.en.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Specify systemd startup ordering separately from dependency requirements,” DSE Security, https://update.dsesecurity.com/updates/specify-systemd-startup-ordering-separately-from-dependency-requirements/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.