> So if you have two units, B can start after A either because B's definition includes After=A, or because A's definition includes Before=B. That's true. Howev

> So if you have two units, B can start after A either because B's definition includes After=A, or because A's definition includes Before=B. That's true. However, most software can be easily misconfigured if you don't know what you're doing. And when creating any kind of DAG, it's implied we need to avoid cycles. I suppose systemd could use a tool for visualizing service dependencies and order. > Order and dependency is specified separately Order is stricter than dependency, and it slows down the whole process. If things can run in parallel, they should. If they cannot, then we should specify it explicitly. Leaving out order would make systemd useless for situations when order matters, and leaving out dependency would slow the whole process down. > Some properties only apply to some systemd units. For example, Before= dependencies don't (didn't?) apply to device targets. I agree, the rules are pretty complex. I don't like that about systemd at all. Combined with the fact that there are 175 different options [0] you can use in a unit file makes systemd really unpleasant for writing any kinds of services. I have a couple of boilerplate unit files I've written long time ago and I just reuse them with changed parameters. [0] check for yourself: cat <(man systemd.service) <(man systemd.unit) <(man systemd.exec) | grep '^ [A-Za-z]*=' | sed 's/=.*/=/' | sort -u