Requirements, Ordering and Failure Propagation

A service can need another unit to be started, need it to start first, or need it to remain active. Those are separate relationships. Confusing them can produce a boot that looks successful while the application starts before its prerequisite is ready.

Build the dependency model

Wants= pulls another unit into the transaction but is weak: its failure does not by itself prevent the requesting unit from starting. Requires= pulls in a stronger requirement; combined with After=, failure to activate the required unit prevents the ordered dependent from starting. After= and Before= specify ordering only and do not themselves pull another unit in. Shutdown order reverses the start order. BindsTo= with After= expresses a stronger ongoing association, but even an active unit is not necessarily an available remote endpoint. Conditions and unexpected deactivation have subtleties; use the systemd.unit manual when designing a real unit.

network.target does not guarantee an assigned address or remote connectivity. network-online.target is an optional synchronization point with meaning determined by the installed network stack and wait service; it cannot promise a remote database or DNS server will stay reachable. Applications need timeouts, retry and failure handling as well as unit dependencies.

Inspect the demo’s actual relationships:

systemctl list-dependencies bl06-demo.service
systemctl show bl06-demo.service -p Wants -p Requires -p After -p Before

Implicit dependencies and defaults can add relationships absent from the unit file. The listing describes manager relationships, not the complete application dependency graph.

Lab: observe a failed prerequisite

On bl06-service-lab, create two temporary system units under /run/systemd/system; they disappear at reboot and are not enabled. The prerequisite exits unsuccessfully, and the dependent requires it and is ordered after it. First check both names and files are unused:

systemctl cat bl06-prereq.service bl06-dependent.service
ls -l /run/systemd/system/bl06-prereq.service \
  /run/systemd/system/bl06-dependent.service

Unit-not-found and missing-file messages are expected. If either unit or file exists, stop rather than overwrite it. Confirm /usr/bin/false and /usr/bin/true exist, then write the units:

sudo tee /run/systemd/system/bl06-prereq.service > /dev/null <<'UNIT'
[Unit]
Description=BL06 intentionally failing prerequisite
[Service]
Type=oneshot
ExecStart=/usr/bin/false
UNIT
sudo tee /run/systemd/system/bl06-dependent.service > /dev/null <<'UNIT'
[Unit]
Description=BL06 ordered dependent
Requires=bl06-prereq.service
After=bl06-prereq.service
[Service]
Type=oneshot
ExecStart=/usr/bin/true
RemainAfterExit=yes
UNIT
sudo systemd-analyze verify /run/systemd/system/bl06-prereq.service \
  /run/systemd/system/bl06-dependent.service

Resolve verification errors before continuing. Reload and start the dependent:

sudo systemctl daemon-reload
sudo systemctl start bl06-dependent.service
systemctl status bl06-prereq.service bl06-dependent.service --no-pager
sudo journalctl -b -u bl06-prereq.service -u bl06-dependent.service --no-pager

The start is expected to fail: the ordered requirement fails before the dependent can run. Compare unit result and journal messages. The dependent’s own program has not demonstrated a failure; it was prevented from running by the dependency transaction. If the result differs, inspect the effective unit files and manager state before changing them.

After recording evidence, remove only the two units created in this exercise and clear their failure state:

sudo systemctl stop bl06-dependent.service bl06-prereq.service
sudo systemctl reset-failed bl06-dependent.service bl06-prereq.service
sudo rm -- /run/systemd/system/bl06-dependent.service \
  /run/systemd/system/bl06-prereq.service
sudo systemctl daemon-reload

Keep bl06-demo.service for subsequent chapters. No real system prerequisite was modified. In a production incident, preserve failure evidence before resetting status and check the implications of stopping a unit and its dependents.

Practice and recall

Draw two arrows: one for pulling in a prerequisite and one for ordering it. Explain what changes if Requires= becomes Wants=, and why After= alone would not start the prerequisite. State what this lab does and does not prove about a continuously running remote dependency.