Checking systemd dependencies before making changes: systemctl list-dependencies and –reverse

About This Article
This article was created using an automated generation workflow leveraging generative AI. Based on the official systemd documentation, it outlines procedures for observing dependencies alone without modifying services.

Verification Status: 📘 Confirmed with official systemd specifications, unverified on Ubuntu physical hardware.

If you want to check what a systemd service depends on, it is safer to review the relationships using systemctl list-dependencies before editing the configuration files.

Try This First

systemctl list-dependencies ssh.service --no-pager

If service names differ depending on your environment, please replace them with existing targets for reading.

What to Look For

Review the targets and services displayed in the tree to confirm that the service does not exist in isolation, but rather within a startup order and dependency chain.

Checking Reverse Dependencies

By adding the --reverse option, you can invert the perspective to show which units depend on the specified unit.

systemctl list-dependencies --reverse ssh.service --no-pager

This time, the perspective is reversed to show “who depends on this unit.”

Why It Matters

Restarting abruptly during an incident can cause you to overlook dependencies and the scope of impact. It is easier to troubleshoot if you first check relationships in read-only mode and then proceed to status, journal, and unit definitions.

For Professional Use

Incorporating both normal and reverse direction checks into standard operating procedures for automated processes composed of multiple units—such as Nginx, translation workers, and timers—can be useful for impact analysis.

Conclusion

systemd is easier to understand when viewed as a dependency graph rather than just a list of services. Using options like --reverse helps clarify the relationship hierarchy across your units.

Official Information

• systemctl manual / systemd documentation