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 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.