SoylentNews is people
SoylentNews
Structural and semantic deficiencies in the systemd architecture for real-world service management
This is a in-depth architectural critique of systemd. It claims to be the first purely technical review of systemd internals, and provides a detailed analysis of several components. It criticizes on the basis of ordering related failures, a difficult to predict execution model, non-determinism in boot-order, as well as several other points.
Though many users would perceive the long processing pipeline to increase reliability and be more "correct" than the simpler case, there is little to acknowledge this. For one thing, none of jobs, transactions, unit semantics or systemd-style dependencies map to the Unix process model, but rather are necessary complications to address issues in systemd being structured as an encapsulating object system for resources and processes (as opposed to a more well-defined process supervisor) and one accommodating for massive parallelism. Reliability gains would be difficult to measure, and that more primal toolkits like those of the daemontools family have been used in large-scale deployments for years would serve as a counterexample needing overview.
(Score: 3, Informative) by jdccdevel on Friday October 16 2015, @07:55PM
Non-determinism is ALWAYS bad in a computer's startup sequence, it should be removed whenever possible.
- In a deterministic system, I (a system administrator) can always be certain that A will start before B, because services will always start in the same order.
- In a non-deterministic system I cannot, unless there is a dependency between them. The dependencies are one way to try to bring a measure of determinism to the system.
The problem is that dependencies are not always easily defined, nor is it obvious if a given configuration change will require some change in dependencies.
How does a system administrator know if the computer starting properly was a fluke or not? The admin cannot know! It may be that 90% of the time things will start correctly, it may only be 10% of a one-off fluke, There is no way to know! I have more important things to do with my time than spend hours troubleshoot something as basic as a computer not starting some random percentage of the time, just because someone else thinks I need to save 30 seconds on my boot time once a month! (If that!)
Even once the problem is isolated, sometimes it is NOT POSSIBLE to express the dependency as a simple A before B, sometimes dependencies are dynamic.
For example, if I make a configuration change to a service, and suddenly my service depends on a library, which depends on a service that it didn't depend on before. How is that reflected in a systemd service file? In an init script, the startup script could account for that, but not in a systemd service.
Here's a real-life example I ran into the other day.
I have a arch system that loads some firewall rules, including NAT. I have some custom settings related to NAT in my sysctl configuration. One day I rebooted, and some of my sysctl settings were gone. Not all of them, just the NAT ones.
The problem was that _SOMETIMES_ the sysctl settings would be applied before the NAT module was loaded, and so my sysctl settings for NAT were not being applied.
Easy fix, you say, apply the settings afterwards. That isn't the point.
Why should I be required to hunt down issues like that? I moved my systems to Linux for stability and predictability. Specifically so that I would not have to deal with issues like that.
If my system starts correctly once, I want it to do so EVERY TIME. Not 90%, not even 99%. Nothing less than 100% of the time is good enough.
That is simply not possible with a non-deterministic boot system.
(Score: 1) by shrewdsheep on Friday October 16 2015, @08:37PM
This is a straw man argument.
systemd could (and probably should) have an option to start sequentially.
(Score: 0) by Anonymous Coward on Thursday October 22 2015, @05:53PM
Options bad, m'kay! All hail the one and only "init": systemd!
(Score: 2) by Justin Case on Saturday October 17 2015, @02:47PM
Non-determinism is ALWAYS bad in a computer's startup sequence^W^Wbehavior
FTFY