4 ms·

Then the question becomes whether an architecture obscures or exacerbates them, and also how it deals with them. The systemd object model does not fare well, as

Then the question becomes whether an architecture obscures or exacerbates them, and also how it deals with them. The systemd object model does not fare well, as discussed. What specific aspects of the systemd dependency model do you feel exacerbate race conditions and circular dependencies? (Also compare a system like s6-rc or serel where dependency graphs are compiled from manifests and consistency checked before being applied. The graph is persistent configuration and not an ephemeral artifact.) I have seen people discussing systemd error messages about circular dependencies online. It seems that systemd does perform some checking, although I haven't found documentation on what checks it does (I probably missed it). I'm not sure how the dependency graph could be persistent configuration because hardware can be hotplugged these days. For example, are you going to create nodes in the graph for all the hard drives that could possibly exist over the lifetime of the machine? Systems having ordering dependencies does not inherently affect their determinism, the startup discipline (sequential v. parallel) primarily does, and then there are different ways to tackle parallelism. systemd's execution model and transactional object system exacerbate non-determinism in ordering results. If the sequential vs. parallel startup discipline "primarily affects determinism" won't all these systems have the same issues with nondeterminism? I don't think anyone is seriously proposing starting up services on boot sequentially in 2015. Or even when a USB stick is inserted. Systems have 12 cores now and people can be very sensitive to boot times. [lack of portability is] a horrible criticism of systemd. Any cursory examination of systemd will quickly reveal the task is next to insurmountable without doing what amounts to a full reimplementation. I understand that systemd relies heavily on cgroups and other Linux-specific features for process isolation. And the BSDs are also unlikely to accept GPLed code. However, I feel like they could have at least discussed some way of reducing fragmentation here. As it is, I would be amazed if at least one or two of the BSDs didn't implement a similar init system to systemd in the next few years. And as it is, they probably won't share any code or concepts, unfortunately.

vezzy-fnord 11y ago
What specific aspects of the systemd dependency model do you feel exacerbate race conditions and circular dependencies? Well, the article discusses all of that... (Speaking of which, JdeBP helpfully linked to Upstart's pre/postconditions not being a proper dependency model, per the developers' testimony, and as I asserted.) I'm not sure how the dependency graph could be persistent configuration because hardware can be hotplugged these days. The idea of device units is not well borne out, as I mentioned. You don't need to create an object type out of a udev handle to order after devices or trigger hotplug events (the device node manager itself does fine, of course in the case of systemd, udev is part of the project, so...) If the sequential vs. parallel startup discipline "primarily affects determinism" won't all these systems have the same issues with nondeterminism? Not necessarily. It could either be more manageable if there wasn't so much indirection, see above (I'm afraid you just didn't get the article, and your original summary certainly implied as much). Additionally, one could forfeit being aggressively parallel for a more conservative approach like in OpenRC, s6-rc or even Upstart. * I don't think anyone is seriously proposing starting up services on boot sequentially in 2015. Or even when a USB stick is inserted. Systems have 12 cores now and people can be very sensitive to boot times.* Parallelism is but a small part of the complicated topic of boot time optimization. And yes, sequential strategies can still be really fast. Much of the speed increase in modern systems is not from parallelism, but forfeiting the overhead of the shell interpreter in favor of direct execution. Checkpointing can do far greater wonders for your boot times than parallelism can, anyhow. I understand that systemd relies heavily on cgroups and other Linux-specific features for process isolation. That's only scratching the surface of Linux-specific features in systemd. As it is, I would be amazed if at least one or two of the BSDs didn't implement a similar init system to systemd in the next few years. And as it is, they probably won't share any code or concepts, unfortunately. What will come of the BSDs is uncertain. launchd will be used in iXsystems products like PC-BSD and FreeNAS, and there's not much "code sharing" you could do there - it's already a complete product being ported.
- colin_mccabe 11y ago
  Parallelism is but a small part of the complicated topic of boot time optimization. And yes, sequential strategies can still be really fast. Much of the speed increase in modern systems is not from parallelism, but forfeiting the overhead of the shell interpreter in favor of direct execution. Checkpointing can do far greater wonders for your boot times than parallelism can, anyhow. No. I have worked on embedded Linux systems where we have carefully charted boot time. We were able to get order-of-magnitude improvements by parallelizing service startups during boot. Parallelism is far from "a small part"-- it is the only important part. The overhead of the shell is negligible even on the slowest systems. Checkpointing is not an option for most things (I have mentioned this several times) because most of the startup processes initialize the hardware directly or indirectly, and hardware can't be checkpointed. The idea of device units is not well borne out, as I mentioned. You don't need to create an object type out of a udev handle to order after devices or trigger hotplug events (the device node manager itself does fine, of course in the case of systemd, udev is part of the project, so...) The important question is whether there is more or less complexity in systemd than a system with a separate device node manager. I am not convinced that systemd is more complex than the alternative. If the device node manager was separate, you would have to debug the interaction between the two processes. Having dealt with debugging d-bus interactions on Linux before, it doesn't sound fun. I'm not convinced that a static dependency graph is even feasible in a world where users can reconfigure and install new services, hotplug hardware, and join and leave wireless networks.
JdeBP 11y ago
There already are systems for the BSDs that can import systemd units; and have been for more than a couple of years now.
- colin_mccabe 11y ago
  Thanks. As a developer, that is useful to know.

vezzy-fnord 11y ago

What specific aspects of the systemd dependency model do you feel exacerbate race conditions and circular dependencies? Well, the article discusses all of that... (Speaking of which, JdeBP helpfully linked to Upstart's pre/postconditions not being a proper dependency model, per the developers' testimony, and as I asserted.) I'm not sure how the dependency graph could be persistent configuration because hardware can be hotplugged these days. The idea of device units is not well borne out, as I mentioned. You don't need to create an object type out of a udev handle to order after devices or trigger hotplug events (the device node manager itself does fine, of course in the case of systemd, udev is part of the project, so...) If the sequential vs. parallel startup discipline "primarily affects determinism" won't all these systems have the same issues with nondeterminism? Not necessarily. It could either be more manageable if there wasn't so much indirection, see above (I'm afraid you just didn't get the article, and your original summary certainly implied as much). Additionally, one could forfeit being aggressively parallel for a more conservative approach like in OpenRC, s6-rc or even Upstart. * I don't think anyone is seriously proposing starting up services on boot sequentially in 2015. Or even when a USB stick is inserted. Systems have 12 cores now and people can be very sensitive to boot times.* Parallelism is but a small part of the complicated topic of boot time optimization. And yes, sequential strategies can still be really fast. Much of the speed increase in modern systems is not from parallelism, but forfeiting the overhead of the shell interpreter in favor of direct execution. Checkpointing can do far greater wonders for your boot times than parallelism can, anyhow. I understand that systemd relies heavily on cgroups and other Linux-specific features for process isolation. That's only scratching the surface of Linux-specific features in systemd. As it is, I would be amazed if at least one or two of the BSDs didn't implement a similar init system to systemd in the next few years. And as it is, they probably won't share any code or concepts, unfortunately. What will come of the BSDs is uncertain. launchd will be used in iXsystems products like PC-BSD and FreeNAS, and there's not much "code sharing" you could do there - it's already a complete product being ported.

colin_mccabe 11y ago
Parallelism is but a small part of the complicated topic of boot time optimization. And yes, sequential strategies can still be really fast. Much of the speed increase in modern systems is not from parallelism, but forfeiting the overhead of the shell interpreter in favor of direct execution. Checkpointing can do far greater wonders for your boot times than parallelism can, anyhow. No. I have worked on embedded Linux systems where we have carefully charted boot time. We were able to get order-of-magnitude improvements by parallelizing service startups during boot. Parallelism is far from "a small part"-- it is the only important part. The overhead of the shell is negligible even on the slowest systems. Checkpointing is not an option for most things (I have mentioned this several times) because most of the startup processes initialize the hardware directly or indirectly, and hardware can't be checkpointed. The idea of device units is not well borne out, as I mentioned. You don't need to create an object type out of a udev handle to order after devices or trigger hotplug events (the device node manager itself does fine, of course in the case of systemd, udev is part of the project, so...) The important question is whether there is more or less complexity in systemd than a system with a separate device node manager. I am not convinced that systemd is more complex than the alternative. If the device node manager was separate, you would have to debug the interaction between the two processes. Having dealt with debugging d-bus interactions on Linux before, it doesn't sound fun. I'm not convinced that a static dependency graph is even feasible in a world where users can reconfigure and install new services, hotplug hardware, and join and leave wireless networks.

JdeBP 11y ago

There already are systems for the BSDs that can import systemd units; and have been for more than a couple of years now.

colin_mccabe 11y ago
Thanks. As a developer, that is useful to know.