3 ms·

> sometimes you have to do it, because that strictness really is there. In that case, wouldn't it be more correct to specify the strictness explicity through s

> sometimes you have to do it, because that strictness really is there. In that case, wouldn't it be more correct to specify the strictness explicity through service dependencies? Service dependencies form a DAG. Sequential start of services can be modeled by a DAG in which every node except the first and the last one has exactly one dependency and one dependant. So systemd way of starting services is a superset of the traditional, sequential way.

alxlaz 4y ago
That's sort of the model that systemd uses (used?). However, non-trivial setups that attempt to use it tend to degenerate into very complex beasts, for various reasons, including: - Unit properties can be specified both ways. For example, an unit can specify both that it should start after another unit (After=) and that it should start before another unit (Before=). 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. - Order and dependency is specified separately. If B depends on A (specified by Wants=A in B's definition) that does not, in fact, guarantee sequential start. - Some properties only apply to some systemd units. For example, Before= dependencies don't (didn't?) apply to device targets.
- paskozdilar 4y ago
  > 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

alxlaz 4y ago

That's sort of the model that systemd uses (used?). However, non-trivial setups that attempt to use it tend to degenerate into very complex beasts, for various reasons, including: - Unit properties can be specified both ways. For example, an unit can specify both that it should start after another unit (After=) and that it should start before another unit (Before=). 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. - Order and dependency is specified separately. If B depends on A (specified by Wants=A in B's definition) that does not, in fact, guarantee sequential start. - Some properties only apply to some systemd units. For example, Before= dependencies don't (didn't?) apply to device targets.

paskozdilar 4y ago
> 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