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: 5, Insightful) by ledow on Friday October 16 2015, @08:19AM
I'm much more of the opinion that unless I've noticed a shortcoming, or one can be demonstrated that affects my usage, that we shouldn't go changing things.
I don't see what's WRONG with other systems, certainly nothing so major as to justify a drastic "every-part-of-the-system" upgrade. I'm sure there are nice new features. In fact, I'm positive of it. I'm sure that lots of things can be done.
What I don't get is what's currently so wrong that we need to change things, and need to change things so drastically that we can just fix the existing system but have to throw not just the implementation but the very idea out and start again from scratch through almost every part of a working system.
That's the bit that bugs me. People come in and mention this and that feature and I think "Well, why couldn't we do that with the 'old' way too?" Things like cgroups are KERNEL features, not systemd features. What's stopping us wrapping up the existing init systems in the same way using the same features.
Just the fact that virtually every command, every file, every way of starting a program or service has changed blows it out of the water for me. Hell, just put in a couple of legacy compatibility layers while you're pitching it at least. But, no, apparently even the COMMANDS are so bad that they have to change.
That's what I don't get. The ideal may be right, but the execution and management of it are so terribly, terribly wrong.
(Score: 2, Disagree) by bzipitidoo on Friday October 16 2015, @09:54AM
Biggest prob with init.d, or, really SysV init, and its incompatible alternate, BSD, is the shell scripting. There are many incompatible shell script dialects, though bash has emerged as the most popular. Shell script is an inferior Algol which itself is long dead, replaced by better languages. It's interpreted, it likes to run in a terminal, it depends upon these environment variables. Any library functionality it needs has to be loaded in the heaviest, slowest possible manner as a full blown executable binary that is linked to the desired library. To do some trivial text processing, might need to run grep, or sort, head or tail, awk, and cat. It just can't interface with C any more elegantly. Though, the fault for that it could be argued, is more with C. Lisp was a better choice of language. Perl was intended to replace it.
Now this system.d is trying to replace much, much more than the shell scripting. I like being able to check logs with "tail /var/log/messages", and not journalctl. I especially dislike the idiot decision to compress the current log file. There wasn't anything wrong with logrotate. Even worse, I've heard that system.d sometimes fails to log messages.
(Score: 0, Insightful) by Anonymous Coward on Friday October 16 2015, @10:27AM
And it's not just the speed. Programming something other that a | b | c using BASH is a real pain to read and write. Not to mention 1001 ways of shooting yourself in the foot with nuclear strikes in the process (hello, correct escaping, real data types…). If you want scripting, fine. Just use some real language to do that, not a bunch of sticks bound together with a duct tape.
(Score: 2) by hendrikboom on Friday October 16 2015, @03:56PM
It's not well-known, but scripting languages have come a long way. Scripting has come a long way, but not in common usage. You can now use a statically-typed, compiled language [mjambon.com] for scripting. It's statically type-checked, has a nontrivial syntax, and is compiled to a byte-code (or, if you prefer, machine code).data structures, modules, and gets compiled to byte-code (or, if you prefer, machine code) for speed.
(Score: 2) by sjames on Monday October 19 2015, @06:39AM
The nice thing about SysV init is that it doesn't care what you use for the "scripting" You can pick anything you want including compiled binaries. It really doesn't care WHAT S05myservice points to (or even where it points to as long as it's been mounted), it will run it with the argument "start".
The complex scripts are mostly just distro maintainers shooting themselves in the foot with a shotgun.
(Score: 2) by janrinok on Friday October 16 2015, @01:36PM
Of course, you can still run the traditional log as well as its new equivalent, and then you have access to grep etc. I agree, running both seems a bit of a waste of time, but I use it and I have the best of both worlds (on the 1 machine that I have running systemd)
(Score: 3, Informative) by Foobar Bazbot on Friday October 16 2015, @02:15PM
While shell script is conventional, it is not required -- you could just as easily write an init script in awk, perl, or even in a compiled language. There's some issues with ensuring that any required interpreter or library is available when needed (e.g. if it lives on /usr, and /usr isn't mounted yet), but nothing that can't be dealt with.
So write a custom interpreter that encapsulates the boilerplate logic in the interpreter, and only needs to read the essential data from its script. If you drink the systemd kool-aid, you'll surely design your interpreter around .INI-style syntax, because reasons -- hey, it could even be a subset of systemd's unit file language! But it could also take YAML, JSON, or even something bizarrely normal, like one KEY=value assignment per line (without .INI-style [section]s, and with escaping/quoting like shell assignments). For one service at a time, you replace the shell script in init.d with one using this new interpreter -- the whole system doesn't have to change at once, or include any sort of compatibility layer for unconverted shell scripts.
This doesn't directly address dependencies or default enable/disable status for each runlevel, of course, but neither does shell script; if your chosen syntax is reasonably compatible with shell script, it won't be an issue. For instance, if your distribution uses standard LSB dependency blocks, as shown below, just include one in your script, and then standard install_initd will do the right thing. If your chosen syntax doesn't treat lines starting with # as comments, maybe you can encapsulate that in a block comment... or just maybe, pick a saner syntax.
Finally, a brief example of what such a script might look like, for a very simple service:
#!/bin/inithelper
### BEGIN INIT INFO
# Provides: lsb-ourdb
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop OurDB
# Description: OurDB is a very fast and reliable database
# engine used for illustrating init scripts
### END INIT INFO
daemon=/usr/bin/ourdb
startargs="--daemon --config=/etc/ourdb.conf"
(Score: 0) by Anonymous Coward on Friday October 16 2015, @02:48PM
#!/bin/inithelper
### BEGIN INIT INFO
# Provides: lsb-ourdb
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop OurDB
# Description: OurDB is a very fast and reliable database
# engine used for illustrating init scripts
### END INIT INFO
daemon=/usr/bin/ourdb
startargs="--daemon --config=/etc/ourdb.conf"
----------------------------------------------------------------------
Look's a lot like /etc/rc.conf & rc.local on a FreeBSD box to me.....
Always thought it was a bit less complicated than the whole Linux run level thing myself but to each is own...
(Score: 0) by Anonymous Coward on Friday October 16 2015, @03:04PM
Why can't you just write a script that is valid and issue update-rc.d defaults ?
At least if you are just inserting a one off startup script. I don't know what the fuss about Bash is...it is pretty straight forward for most things. For everything else there is Python.
(Score: 2) by Eunuchswear on Saturday October 17 2015, @11:09AM
Yeah, everyone has heard this.
Nobody can ever point to a bug report.
Odd that.
Watch this Heartland Institute video [youtube.com]
(Score: 1) by zoefff on Tuesday October 27 2015, @03:23PM
Duh, because you have to provide logs for that. Kind of catch 22.
(Score: 2) by sjames on Monday October 19 2015, @06:42AM
Then pick something else. SysV doesn't care one way or the other. One of my problems with systemd is that it doesn't allow that in a meaningful way.
You can even throw out all of the scripting by starting something else in /etc/inittab. Once again, SysV doesn't care (even if it's not really SysV at that point).
(Score: 2) by Eunuchswear on Saturday October 17 2015, @11:07AM
Nothing. Do it. Let a million flowers bloom.
Watch this Heartland Institute video [youtube.com]