6 ms·

> systemd starts services in dependency order. I'm not sure if this is still the case, because I no longer use Linux, and I may be misremembering it. But IIRC

by alxlaz 4y ago

> systemd starts services in dependency order. I'm not sure if this is still the case, because I no longer use Linux, and I may be misremembering it. But IIRC a good while back, there was no way to guarantee service start order at boot. You could specify dependencies for some services, but even then, if there was more than one choice of dependency order that satisfied the requirements, systemd did not guarantee that the same one would be used on each startup. Otherwise, services with no dependency specs (or groups of services at the end of the same dependency chain) would get started in parallel. If you really wanted to start a sequence of services in order, doing so by specifying dependencies in separate unit files was really painful and basically impossible to debug, especially since dependencies weren't exactly easily described (various combinations of After=, Requires=, Wants=, BindsTo= that went both ways between targets and service links in the dependency chain). Please note the "I may be misremembering it" part. My life is a lot happier now that I no longer need to care about Linux userspace stuff so I may be repressing some memories :-D. Edit: > Why do I need to rebuild without Bluetooth support? The author chose a lazy example. Yeah, you don't usually need it. A better example: rebuild with `CONFIG_BFQ_GROUP_IOSCHED=y` to enable proportional weight division of disk bandwidth in CFQ.

danielheath 4y ago
> guarantee service start order at boot If the services boot after their dependencies, why do you care what order they boot in? Plus, it's rare to find a CPU with fewer than four cores these days, so 'order' becomes harder to reason about.
- alxlaz 4y ago
  First off, dependencies aren't just other services. You can have "when the network interfaces are up" as a dependency, for example, so this isn't just about how many programs run at once and in what order. Second, you care about it in scenarios where predictability is required. If your customer says they want their smart TV or their POS or whatever to boot in no more than X seconds under normal operating conditions, it's really not cool if the system can take a slightly different way to multi-user.target. Dependencies across separate chains can contend for resources, for example. "But these are embedded systems, you should just run rc.local" I hear you say? Right. These things run like fourty services, from telemetry to user interface and from firmware update to encrypted cloud backup, half of them written in Node.js, on top of a system that's basically built for systemd. It's not something you can extricate yourself out of. I don't know if there are equivalent examples in the server world (not my field), but I wouldn't be surprised if there were.
ink_13 4y ago
If starting a service has dependencies, not explicitly spelling out those dependencies and relying on the init system is akin to relying on unspecified behaviour. So among other things, don't be surprised if that's unreliable. > specifying dependencies in separate unit files was really painful and basically impossible to debug This is actually quite easy to check and to claim otherwise is FUD
- alxlaz 4y ago
  > This is actually quite easy to check and to claim otherwise is FUD It's only easy to check if you have a small number of dependent services that mostly go one way. On the general case it absolutely isn't easy to check. If I had a dime every time I've seen non-trivial chains of serial operations implemented through a systemd target that just runs a shell script, I could erect an ice statue for Stephen Bourne and it would be made out of the frozen tears of everyone who's had to deal with both systemd and shell scripts.
zaarn 4y ago
Systemd still has no dependency order. You still use Requires=, After= ,etc. Otherwise it'll start when it starts. I don't think dependency order is particularly valuable in the real world. Manually specifying order imposes a strictness upon reality that isn't there. Most apps are messy and starting a system tends to be a messy affair in of itself. The much simpler solution to specifying services to start in order is to write a script and have one big service start and terminate them. But I can't really imagine a real world scenario where that is somehow better than just giving each service the dependency definitions it needs. edit: the simpler solution to compiling the kernel is just blacklisting the module. Then bluetooth won't be loaded obviously. Though not everything can be a module, in practise I've found it to be rare that I was looking for a kernel option to be enabled that wasn't in my distro (but then again, I run most of my personal stuff on archlinux, which ships a near default config of the kernel anyway).
- alxlaz 4y ago
  > I don't think dependency order is particularly valuable in the real world. Manually specifying order imposes a strictness upon reality that isn't there. I mean... sometimes you have to do it, because that strictness really is there. > the simpler solution to compiling the kernel is just blacklisting the module. What module? I'm not talking about removing a module, but changing a compile-time option for one. Removing a module is certainly best achieved by just blacklisting it, that's why I mentioned this as a lazy example that the author picked. (But, FWIW, even that has unexpected consequences. A while back, for example, you could (sometimes significantly) improve the startup time of most embedded devices running Linux by removing the modules instead of blacklisting it because going through the list of blacklisted modules is surprisingly slow. That's probably not a relevant use case for what the author of this article is describing though)
  - paskozdilar 4y ago
    > 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.
throw7 4y ago
Lennart wanted/wants devs to switch to "socket-based or bus-based activation", leaving explicitly defined dependencies behind; in that way, he kind of punted on the issue. That said, I find it fairly flexible, but, yes, complex (or not particularly transparent).

by alxlaz 4y ago

danielheath 4y ago

> guarantee service start order at boot If the services boot after their dependencies, why do you care what order they boot in? Plus, it's rare to find a CPU with fewer than four cores these days, so 'order' becomes harder to reason about.

alxlaz 4y ago
First off, dependencies aren't just other services. You can have "when the network interfaces are up" as a dependency, for example, so this isn't just about how many programs run at once and in what order. Second, you care about it in scenarios where predictability is required. If your customer says they want their smart TV or their POS or whatever to boot in no more than X seconds under normal operating conditions, it's really not cool if the system can take a slightly different way to multi-user.target. Dependencies across separate chains can contend for resources, for example. "But these are embedded systems, you should just run rc.local" I hear you say? Right. These things run like fourty services, from telemetry to user interface and from firmware update to encrypted cloud backup, half of them written in Node.js, on top of a system that's basically built for systemd. It's not something you can extricate yourself out of. I don't know if there are equivalent examples in the server world (not my field), but I wouldn't be surprised if there were.

ink_13 4y ago

If starting a service has dependencies, not explicitly spelling out those dependencies and relying on the init system is akin to relying on unspecified behaviour. So among other things, don't be surprised if that's unreliable. > specifying dependencies in separate unit files was really painful and basically impossible to debug This is actually quite easy to check and to claim otherwise is FUD

alxlaz 4y ago
> This is actually quite easy to check and to claim otherwise is FUD It's only easy to check if you have a small number of dependent services that mostly go one way. On the general case it absolutely isn't easy to check. If I had a dime every time I've seen non-trivial chains of serial operations implemented through a systemd target that just runs a shell script, I could erect an ice statue for Stephen Bourne and it would be made out of the frozen tears of everyone who's had to deal with both systemd and shell scripts.

zaarn 4y ago

Systemd still has no dependency order. You still use Requires=, After= ,etc. Otherwise it'll start when it starts. I don't think dependency order is particularly valuable in the real world. Manually specifying order imposes a strictness upon reality that isn't there. Most apps are messy and starting a system tends to be a messy affair in of itself. The much simpler solution to specifying services to start in order is to write a script and have one big service start and terminate them. But I can't really imagine a real world scenario where that is somehow better than just giving each service the dependency definitions it needs. edit: the simpler solution to compiling the kernel is just blacklisting the module. Then bluetooth won't be loaded obviously. Though not everything can be a module, in practise I've found it to be rare that I was looking for a kernel option to be enabled that wasn't in my distro (but then again, I run most of my personal stuff on archlinux, which ships a near default config of the kernel anyway).

alxlaz 4y ago
> I don't think dependency order is particularly valuable in the real world. Manually specifying order imposes a strictness upon reality that isn't there. I mean... sometimes you have to do it, because that strictness really is there. > the simpler solution to compiling the kernel is just blacklisting the module. What module? I'm not talking about removing a module, but changing a compile-time option for one. Removing a module is certainly best achieved by just blacklisting it, that's why I mentioned this as a lazy example that the author picked. (But, FWIW, even that has unexpected consequences. A while back, for example, you could (sometimes significantly) improve the startup time of most embedded devices running Linux by removing the modules instead of blacklisting it because going through the list of blacklisted modules is surprisingly slow. That's probably not a relevant use case for what the author of this article is describing though)
- paskozdilar 4y ago
  > 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.

throw7 4y ago

Lennart wanted/wants devs to switch to "socket-based or bus-based activation", leaving explicitly defined dependencies behind; in that way, he kind of punted on the issue. That said, I find it fairly flexible, but, yes, complex (or not particularly transparent).