| View previous topic :: View next topic |
| Author |
Message |
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
 Posted: Wed Dec 25, 2019 4:58 pm Post subject: s6/s6-rc vs systemd, or why you probably do not need systemd |
 |
|
Introduction
Many people, when arguing against systemd, say they do not need the fancy features provided by systemd, or that these features are implemented badly in systemd. In my opinion, these are not very strong reasons themselves, because systemd proponents can still argue that these features worked well enough for many people. To truly prove systemd's deficiency, truly workable alternatives, in terms of supported features, are needed. Fortunately, such alternatives do exist: to my knowledge, daemontools-ish init/rc systems, best represented by s6/s6-rc, offer features comparable with those provided by systemd, often implemented in ways vastly superior to those in systemd. See below for a summary, and the following reply for steps to construct a small real-life example system based on s6/s6-rc.
| Code: | ----------------------------------------------------------------------------------------------------------------
| |systemd |s6/s6-rc |
|--------------------------------------------------------------------------------------------------------------|
|Simple service definition |Perhaps, but with lots of gotchas [b] |Yes, by chainloading [a] |
|Support for cgroups |Yes, hardcoded in init |Doable, in better ways [d] |
|"Socket activation" |Yes |Yes, by fd holding [a] |
|Service logging [c] |Inefficient, SPOF, binary logs |Efficient, reliable, textual logs |
|Separate /usr |Unsupported, for questionable reasons [1] |Supported |
|Portability |Only Linux with glibc |Linux (with glibc, musl, ...), BSD, ... |
|--------------------------------------------------------------------------------------------------------------|
|Speed ([b] for all below) |Hangs that are hard to predict |Consistently fast |
|Simplicity |Big, very complex due to tight coupling |Tiny, loosely coupled |
|Reliability |Easy to begin, but with lots of gotchas |Easy to learn, and predictable |
|Maintainability |Number of unresolved bugs growing quickly |Very few bugs, resolved quickly |
|Flexibility |Hardly extensible, components unreusable |Easily extensible, components reusable |
|Security |Many vulnerabilities |Few (if any) vulnerabilities |
|--------------------------------------------------------------------------------------------------------------|
|[a-d] See the "Basic background", "Quality", "Logging" and "Linux cgroups" parts below, respectively. |
|[1] <https://forums.gentoo.org/viewtopic-p-8354032.html#8354032>. |
---------------------------------------------------------------------------------------------------------------- |
Depending on your actual application scenario, sysvinit, OpenRC, or even upstart and systemd may actually be appropriate for your use, so this post does not attempt to persuade you to migrate to s6/s6-rc. Instead, it just uses s6/s6-rc to help you understand how the most touted features in systemd can be better implemented, and how necessarily (or not) these features are dependent on systemd's architecture. I try to keep this post factually and logically correct, so please feel free to tell me if you find any mistake; I will update the post as necessary. If you like this post, please consider helping to spread the voice, so that more people will know superior alternatives to systemd.
Basic background
To understand s6/s6-rc, you need a little basic knowledge. However, this knowledge is not hard to learn, and can be employed in many applications outside of init/rc, unlike systemd knowledge which is largely systemd-specific; additionally, once you master it, you will be able to implement most of your requirements with minimal reference to the s6/s6-rc documentation. First of all, you need to know some shell scripting; even if you do not use s6/s6-rc, this will probably be required for most kinds of non-trivial Unix system administration. If you have not mastered it yet, I recommend beginning by skimming through a decent guide to Bash scripting, then learning the `rc' shell (I prefer the implementation by Byron Rakitzis, and use it for my slew framework), and finally returning to Bash. `rc' will teach you the essentials of shell scripting, and Bash will give you the ability to read most shell scripts provided by Linux distributions.
You will also need to know, on an intuitional level, how processes are created in Unix through the fork() and exec() system calls: the original process first creates an almost identical child process with fork(), and the child process replaces itself with a new program with the exec(). exec() preserves process attributes like the working directory and certain resource limits, so the child can change its attributes before exec(), and the changes will also affect the exec()ed program. exec() can be regarded as a basis of chainloading, which is how daemontools-ish init systems (including s6) start service programs: a `run' script is fork()/exec()ed, which modifies its process attributes, and then exec()s into the service program or another program (called a chainloader) that exec()s; the chain of exec() results in the term "chainloading", and some good examples for chainloading `run' scripts can be found here.
So as was shown in the page mentioned above, chainloading `run' scripts are as clean as systemd "unit" files; moreover, by using chainloading, the init system can be made very small because the mechanism for setting process attributes of services is factored out of init. And although the init process is never allowed to exit (or you will get a kernel panic), it can exec(), so chainloading can also be used to further reduce the complexity of init: we can implement "stage 1" and "stage 3" programs which respectively care about early booting and late shutdown; stage 1 exec()s into the ("stage 2") init program, which when told to shut down exec()s into stage 3. This is exactly how s6 handles (in fact, avoids handling) platform-specific details of booting and shutdown; example stage 1 and stage 3 programs for Linux can be found, for instance, here (see the `rc.boot' and `rc.halt' scripts).
When services are started by the user in a traditional init system like sysvinit, in order to avoid interfering with the user's shell, the service program would fork() and then exit, with the fork()ed child runnning in the "background". However, this leads to many problems, and a most important among them is that there is no simple way to reliably tell the state of the fork()ed service process, and handle its exiting. Another scheme, called "process supervision", starts services (told not to fork()) from "supervisor" processes independent of the user's shell, and the kernel will tell the supervisor immediately when the corresponding service exits. Process supervision is much simpler and more reliable than fork()ing services, and it is also the prefered way in systemd; in s6, the real supervisors (one for each service), `s6-supervise' (controllable with `s6-svc'), are supervised by the init, `s6-svscan' (controllable with `s6-svscanctl'), so supervision is rooted in init. Only longrun services are managed by s6, while oneshot init scripts are managed by s6-rc, which also uses s6's tools to track the status of services in order to manage the dependency between them.
During exec(), a process's handles to open files (called "file descriptors" in Unix, eg. stdin, stdout and stderr) are also preserved, which is how I/O redirection (like `cat > /dev/null') works. In Unix, a process can be store some of its file descriptors in a "fd holder" process, and another process can copy these file descriptors for its own use. With this "fd holding" mechanism, we can pre-open pipes for use between service processes and their logger processes; and as long as the fd holder is alive, no log will be lost even if processes at both ends of a pipe are restarted. Apart from being used to construct reliable logging pipes, fd holding can also be easily used to implement the feature vaguely called "socket activation" by systemd proponents.
Quality
systemd proponents often claim systemd was modular, and meanwhile conveniently ignore the fact that systemd is badly modularised: the modules are tightly coupled, so the behaviour of each module is affected by many other modules, often through complex function calls. In comparison, the modules in s6/s6-rc are designed to be as small and as loosely coupled as reasonable: each module cares about very few other modules, and the modules are connected using simple mechanisms like process supervision, chainloading and fd holding. This architectural difference unsurprisingly results in dramatically different maintainability: systemd, with at least a few dozens of active developers, has an incessantly growing number of unresolved bugs; s6/s6-rc and closely related packages, with only one active developer, has very few bugs, and the fix for any bug almost always arrives within one week of the bug report. Even if we also count other projects with functionalities emulated by systemd, the number of bugs still does not grow in systemd's fashion.
systemd might seem easy to learn at a first glance, but as was analysed above, due to tight coupling, it is often hard to deduce systemd's behaviour from its documentation, especially in many "corner" cases (eg. the hangs here and here) that are not considered by its developers. This kind of issues rarely happen in systems based on s6/s6-rc, because each module is designed to care about (and therefore to be affected by) as little as possible; furthermore, due to the simple interfaces between these modules, they are highly reusable and composable, which makes s6/s6-rc very flexible and extensible. For example, the template mechanism (for "instanced" services) in systemd can be emulated by a roughly 4-line library script loadable by the `run' script; the requirement in this and this, which seems to even lack a reproducible way to implement with systemd, is trivial to implement with s6/s6-rc; as was noted here, chainloaders from daemontools, s6/execline, runit etc can be freely mixed, in comparison with how much effort it took elogind developers to separate logind from systemd. A user familiar with shell scriping and basic notions about processes can read through the core s6/s6-rc documentation comfortably in 2-3 hours, and then will be able to implement the desired configuration with s6/s6-rc; a vast majority of problems that can arise will be easily traceable to the causes, and problems with s6/s6-rc themselves are very rare.
systemd developers claimed that systemd was designed to be "small", "minimal", "lightweight", and was even suitable for embedded systems. However, for normal desktop/server use, systemd is usually built with a lot of "optional" dependencies (many of which are of little interest in many common use cases) and modules (most of which duplicate features of existing software, and implement them badly, eg. this and this) enabled. As can be seen from this post, there is probably no useful systemd feature that cannot be implemented with s6/s6-rc, often with much less yet much cleaner code, so these optional code can be legitimately called bloat. For embedded use, a carefully tailored systemd build plus necessary ancillary utilities and dependencies may not be too much bigger on disk than a workalike based on s6/s6-rc, BusyBox and other utilities; however, I believe the tailoring process for systemd would be much more complex than that for s6/s6-rc. Furthermore, because chainloading replaces a process with a new program, only the new program would reside in memory, which in combination with the smallness of individual s6 programs leads to the successful minimisation in the amount of memory-resident code in s6, which is a huge advantage in embedded applications.
systemd proponents often boast about its isolation features (often based on cgroups, namespaces etc) that may enhance the security of the system. However, a system is as vulnerable as its most vulnerable part, and the number of reported vulnerabilities in systemd (and in particular those that were still severe even in the presence of those features, like this and this) clearly shows that systemd is not secure. This is not coincidence: due to the complex interactions (which, as you can see from this post, are unnecessary) between systemd modules, it is very hard to stipulate their behaviours, let alone specify security requirements for them. In comparison, s6/s6-rc and related packages by the same author closely follow the style by Daniel J. Bernstein, the celebrated cryptographer, author of qmail (I strongly recommended that paper to anyone interested in producing highly secure software systems, and encourage you to observe how systemd falls for the security distractions discussed in the paper), daemontools and UCSPI-TCP, and I have yet to see a single vulnerability in s6/s6-rc etc.
Logging
In traditional init systems like sysvinit, in order to fully detach from the user's shell, fork()ing services also need to redirect their stdin, stdout and stderr from the user's terminal to elsewhere (usually /dev/null). However, they still need to write their logs somewhere, which results in the necessity of the syslog mechanism: services send their logs to the /dev/log socket, which is listened to by a syslogd process. With the syslog mechanism, log streams from different processes are first mixed up, then classified and filtered using string matching, which can be a central perfomance bottleneck when the log volume is huge, because the string matching is done globally on logs from the whole system. A more severe problem is that the mixing process is technically irreversible, because it lacks a reliable way to differentiate between services, so one service can falsely claim to be another one.
With supervision, we can assign one logger process for each service process, and redirect the stderr of the latter to the standard input of the former thanks to fd holding, so service processes only need to write to stderr in order to transfer logs. In this way, we can avoid the performance hit of global string matching, and completely eliminate the problems with irreversible mixing of log streams; because of fd holding, the service and the logger can be restarted independent of each other, and no log will be lost; different loggers can be run as different low-privilege users, therefore implementing a high level of privilege separation. systemd manages most services with process supervision, and lets them write logs to stderr, but again mixes log streams up prior to further processing in its journald module; the mixing process is reversibe because journald internally adds tags to logs, but the performance issue with global string matching is not avoided. journald is run with root privilege and little to no privilege separation, so its compromise (eg. this and this) can have serious implications.
Unlike daemontools-ish init systems which can be used in combination with any of `multilog'/`svlogd'/`tinylog'/`s6-log'/`cyclog' (respectively from daemontools, runit, perp, s6 and nosh) and also play nice with traditional syslogd, systemd cannot be used without journald. Even when you only need syslog (and have configured services to use it), with systemd you have no choice other than configuring journald to forward to syslogd, which in combination with the fact that journald is a big, complex module results in a single point of failure (SPOF), where problems (eg. this) can occur. journald saves logs in a binary format, which when corrupted loses more information than textual log files do, and is also much more difficult to recover; as can be seen above from the way system logs are handled in daemontools-ish init systems, systemd proponents' usual claim that the binary format was necessary for differentiation between multiple log streams is untenable. The choice of a binary format by journald is also often explained by systemd proponents with the possibility to prevent logs from being tampered with, but that is also doable in daemontools-ish init systems by a moderate amount of modification to the logger.
Linux cgroups
The expected usage of cgroups is to limit the allocation of system resources for certain services. Since the low-level system interface for cgroup management is just regular file/directory operations on /sys/fs/cgroup, corresponding settings can be easily done during chainloading, and some chainloaders (like those in nosh) have been written to facilitate this. A more important use of cgroups in systemd is to track the process trees of services, in order to deal with orphan processes of badly written service programs after the main service process exits, and to deal with services that do not support non-fork()ing execution. However, as a matter of fact, cgroups are not intended for process tracking, and such usage can be unreliable; and as you have just seen, this kind of usage is usually due to the requirement to run legacy or sub-standard service programs, so in my opinion you should avoid it when possible. Even if you really want to use cgroups to track process trees, the support for cgroups does not need to be in the init system, as I will explain below.
To handle unruly services, a cgroup-based babysitter program can be written to fork()/exec() the given service process in the specified cgroup. If the service supports non-fork()ing execution, the babysitter then waits for its child (the main service process) to exit, kills processes remaining in the cgroup, and then exits; if not, the babysitter then waits for the cgroup to be empty, and then exits. As far as I know such a program is not yet implemented, but I believe that I have outlined enough above for a practical implementation of the requirement, and that such a program will be available soon if enough people seriously demand it (eg. this was written recently). When reading this, some systemd proponents may argue that after this feature (and perhaps some other features they deem necessary) is implemented, "you get systemd anyway"; however, as you have seen from this post, most important systemd features have become simpler, securer, more reliable and more flexible when done in s6/s6-rc, so it is not unreasonable to expect the same for this small fraction of currently unimplemented features.
A possible argument for supporting cgroups in the init system is that certain special properties of init (PID 1) made such design more reliable: first, it is the only process that can block SIGKILL, and will not be killed because of resource exhaustion (like OOM); second, orphan processes are reparented to init, so it can somehow deal with them. The second point is invalid because under Linux we can set the babysitter as a subreaper, so orphans will be reparented to it. Concerning the first point, the inits from s6 and most other daemontools-like init systems are written to consume as little system resource as possible, so they are very unlikely to hit a resource limit, and very unlikely to be targeted by the OOM killer. Considering that SIGKILL can only be directed to the babysitter due to an operator error (and the operator will probably try to fix the problem) or a software bug (in extremely rare cases), and that a `finish' script can clean up processes in the cgroup, this problem is extremely unlikely to occur, and would be limited in scope even if it really occured. To summarise it up, in comparison with the tangible benefits above of decoupling cgroups from init, the imaginary disadvantages are definitely secondary, and perhaps even negligible.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Last edited by CasperVector on Sat Jan 04, 2020 3:49 pm; edited 26 times in total |
|
| Back to top |
|
 |
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Wed Dec 25, 2019 5:00 pm Post subject: |
|
|
Example
In this example, I will show how a Linux system with only essential services, dhcpcd on eth0, and an OpenSSH server, managed with s6/s6-rc, can be built. It also uses slew, a flexible framework that thinly (~500 core SLOC, including ~200 for core service definitions) wraps around s6/s6-rc to offer some features commonly requested by distributions; the author of s6/s6-rc considers these features as "policies" instead of "mechanisms", and therefore does not include them in s6/s6-rc. To make this example useful to as many people as possible, it will be given in a distribution-neutral way, but people with a little experience in distribution packaging should be easily able to write packaging specifications (Gentoo ebuilds, Alpine APKBUILDs etc) after following it.
First, you need to extract the core slew code plus necessary package-specific additions (eg. service definitions for dhcpcd), and do some basic customisation to meet the average use case for your distribution.
| Code: | #!/bin/sh -xe
git clone https://gitea.com/CasperVector/slew || true
mkdir -p pkgs build/slew
# Core slew code.
cd slew; cp -a base init lib main run ../build/slew; cd -
# Addons, preferably packaged separately for real use.
cd slew/pkg
cp -a udev/* nftables/* kbd/* dhcpcd/* openssh/* ../../build/slew
cd -; cd build/slew
# pkg/*/misc contain package-specific ancillary files (patches or non-slew
# configuration files). See pkg/wpa_supplicant and pkg/thinkfan for examples;
# here I assume these files will be handled properly.
rm -rf misc
# Use eudev instead of BusyBox mdev. Here I also strongly recommend
# <https://skarnet.org/software/mdevd/> for those interested in the latter.
ln -snf ../base/devices.udev main/devices
ln -snf ../base/drivers.udev main/drivers
ln -sn ../base/udevd main/devd
# Avoid the UCSPI-based syslogd, which only works with SOCK_STREAM /dev/log.
ln -snf ../base/syslog.busybox main/syslog
# Use `loadkeys' from kbd instead of `loadkmap' from BusyBox.
ln -snf ../base/keymap.kbd main/keymap
# Use `agetty' from util-linux instead of `getty' from BusyBox.
sed -i 's/^getty/agetty/' main/getty./contents
# The original script was more demonstrational.
printf '#!/bin/rc\n\nip link set dev lo up\n' > base/network/prep/up
printf 'ip link set dev eth0 up\nexit 0\n\n' >> base/network/prep/up
# The ways to configure iptables seem to differ greatly between distributions,
# and here I just create a dummy service based on the nftables version.
cp -a base/nftables base/iptables
printf '#!/bin/rc\nexit 0\n\n' > base/iptables/prep/up
ln -sn ../base/iptables main/firewall
ln -sn ../base/dhcpcd. main/dhcpc.eth0
echo dhcpc.eth0 >> main/services/contents
# OpenSSH server packaged by some distributions (eg. Ubuntu) seems to require
# the existence of /run/sshd before starting sshd. Note that in this way we
# can emulate the behaviour of tmpfiles in s6.
mkdir run/sshd
ln -sn ../base/openssh main/sshd
cd -
find build '(' -type d -o -type f -perm -0100 ')' -exec chmod 0755 '{}' ';'
find build -type f -not -perm -0100 -exec chmod 0644 '{}' ';'
tar -C build -czpf pkgs/slew-master.tgz slew |
Now with the slew code available from `pkgs/slew-master.tgz', we need to install and configure it for the target system. (Users of Debian/Ubuntu/... and RedHat/CentOS/... will additionally need the remaining scripts in this post; those scripts may also be interesting for advanced users.)
| Code: | #!/bin/sh -xe
#
# 1. Install s6, s6-rc and their dependencies.
# 2. Install the `rc' shell, and ensure it can be accessed at /bin/rc.
# 3. Ensure eudev and other dependencies are installed.
# 4. Run this script as root.
tar -C /etc -xopf pkgs/slew-*.tgz
for name in catchlog fdholder klog syslog devlog sshlog dhcplog klogd; do
useradd -r -d /dev/null -s /bin/false "$name" || true
done
/etc/slew/lib/build.rc main; rm -rf /etc/slew/prep.main
# May need to be customised if config files are located elsewhere, or if an
# alternative bootloader is used. Debian/Ubuntu etc seem to use a wrapper
# called `update-grub'.
sed -i '/^GRUB_CMDLINE_LINUX_DEFAULT=/ {
s@"$@ net.ifnames=0 init=/etc/slew/init/rc.boot"@
}' /etc/default/grub
grub-mkconfig -o /boot/grub/grub.cfg |
On distributions where s6/s6-rc or their dependencies are unavailable (eg. CentOS) or crippled (eg. Debian), the following script can help to build static-linked execline/s6/s6-rc, perferably on an Alpine virtual machine.
| Code: | #!/bin/sh -xe
# 1. install build-base (Alpine), build-essential (Debian) or so.
# 2. mkdir `distfiles' and download $pkgs source tarballs into that directory.
# 3. Run this script as root, and the binary packages will be put into `pkgs'.
# 4. These packages can be installed on the target machine by
# for name in pkgs/execline-*.tgz pkgs/s6-*.tgz; do tar -C / -xpf $name; done
pkgs="skalibs execline s6 s6-rc"
confargs="--enable-static-libc"
makeopts="-j $(nproc)"
mkdir -p build pkgs; cd build
for name in $pkgs; do
pkg="$(ls ../distfiles | sed -r -n 's/^('"$name"'-[0-9.]+)\.tar\.gz$/\1/p')"
[[ -d "$pkg" ]] || tar xpf ../distfiles/"$pkg".tar.gz
cd "$pkg"; ./configure $confargs; make $makeopts
mkdir -p ../"$pkg".pkg; make install DESTDIR=../"$pkg".pkg; cd ..
tar -C "$pkg".pkg -czpf ../pkgs/"$pkg".tgz .
tar -C / -xpf ../pkgs/"$pkg".tgz
done |
On distributions where BusyBox is unavailable (eg. CentOS 7) or badly configured (eg. lacking certain applets), the following script can help to build static-linked BusyBox, configured for comfortable daily use.
| Code: | #!/usr/bin/python
# Usage:
# $ git clone --depth 1 https://github.com/alpinelinux/aports
# $ pkgver="$(. ./aports/main/busybox/APKBUILD; echo "$pkgver")"
# $ wget https://busybox.net/downloads/busybox-"$pkgver".tar.bz2
# $ tar xf busybox-*.tar.bz2 && cd busybox-*/
# $ mv ../aports/main/busybox pkg && cd pkg
# $ /path/to/this/script.py busyboxconfig busyboxconfig-extras > ../.config
# $ cd .. && cat pkg/*.patch | patch -p1 && make oldconfig && make -j "$(nproc)"
import re
import sys
def conf_get(f):
d = {}
for l in f:
l = l.strip()
if l == "":
continue
elif l.startswith("#"):
if l.endswith("is not set"):
d[re.match(r"# (.*) is not set$", l).group(1)] = None
else:
l = l.split("=", 1)
d[l[0]] = l[1]
return d
def conf_merge(d, d1):
for k, v1 in d1.items():
if d.get(k) == None:
d[k] = v1
def main(argv):
d = {}
for f in argv:
conf_merge(d, conf_get(open(f)))
for k, v in [
("PIE", None), ("STATIC", "y"),
("SSL_CLIENT", "y"), ("EXTRA_COMPAT", "n")
]:
d["CONFIG_%s" % k] = v
for k in sorted(d):
v = d[k]
if v == None:
print("# %s is not set" % k)
else:
print("%s=%s" % (k, v))
if __name__ == "__main__":
main(sys.argv[1:]) |
Based on the example in this post, you will in principle be able to implement more complicated requirements, but it is necessary to note that slew is still quite incomplete as of now:
- The number of readily available service definitions is still small. This is merely due to a lack of request for service definitions, and you are surely welcome to submit such requests at the slew homepage.
- Package-specific converters, analogous to the `mariadb-service-convert' program and those provided by nosh, are not provided for now. They are much less trivial to write than service definitions, so I may write these converters when enough people request them. Of course, you are highly encouraged to contribute your converters!
- Networking is currently configured with the `network' oneshot and user-added networking longruns like `dhcpc.eth0', `wpasup.wlan0' etc. For newbies, this can be quite a challenge; some kind of higher-level abstraction, analogous to Gentoo's netifrc, Debian's ifupdown and Ubuntu's netplan, will certainly be desirable. However, since I am not very familiar with the configuration of many networking schemes, how to optimally construct such an abstraction is a non-trivial problem; if you happen to be savvy in this, I would be very grateful if you can give your thoughts on a plan for the abstraction, preferably in an "issue" on the slew homepage.
- On the lower level, s6/s6-rc also lack some less commonly requested functionalities: chainloaders and utilities related to Linux cgroups; integration of user-controlled supervision with the system-wide supervision tree; virtual dependencies in s6-rc. These can be worked around, but they do create inconvenience for certain users; if you are interested in helping to implement them in s6/s6-rc, please join the supervision mailing list.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Last edited by CasperVector on Wed Dec 25, 2019 6:03 pm; edited 5 times in total |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Wed Dec 25, 2019 5:05 pm Post subject: |
|
|
Myths
• "You use shell scripts, which are buggy."
First, users of daemontools-ish init/rc systems do not necessarily need to use shell scripts; they can use any language they like: Perl, Python, execline, nosh (the language), whatever. Second, that sysvrc service scripts are long and buggy does not imply shell scripts were inherently buggy; service scripts for OpenRC and BSD rc.d, for instance, are simple, clear and easily auditable. Third, in comparison with the ever-increasing number of unresolved bugs in systemd, the number of bugs in service scripts due to the shell language is negligible.
• "Chainloaders may hang or execute `rm -rf /'; they are also race-prone."
systemd code that runs services may also hang or execute `rm -rf /'; additionally, as has been said multiple times and proven by the comparison of bug counts, due to the tight coupling in systemd, this kind of bugs are vastly more likely to occur in systemd than in daemontools-ish init/rc systems. Since chainloaders do their jobs before exec() and die in case of failure in such jobs, when the actual service process is exec()ed, it is guaranteed to be in the desired state, so no race condition is possible.
• "systemd is good because it is tightly integrated."
The phrase "tightly integrated" is too vague; I can interpret it in two ways, and systemd fails in both ways. If the phrase means "tightly coupled" (which systemd is) then systemd is certainly bad, because as was shown above, tight coupling is bad. If the phrase means "with modules collaborating well with each other", then systemd is still worse than daemontools-ish init/rc systems: as can be seen from the comparison of bug counts, when implementing the same requirements, systemd modules surely collaborate much worse than modules from daemontools init/rc systems (plus traditional Unix utilities) do.
• "Few bugs have been reported in s6/s6-rc because they have few users."
As far as I know, systemd is one among the very few well-known open source projects that cannot control the growth of unresolved bugs, even with nearly two orders of magnitude more active developers than s6/s6-rc have. I also note that qmail has an extremely small total number of reported bugs, more than 20 years after its first release; I believe similar situations can be expected of s6/s6-rc, which closely follow the style of qmail.
• "systemd is good because it is popular."
This statement is clearly falling for the ad populum fallacy. For example, Debian's migration to systemd is a milestone in the growth of systemd's user base, but the migration was due to systemd developers' deliberate practice of the "embrace, extend and extinguish" ploy (cf. Section 10 of my document for the detailed analysis). Yes, the migration had some technical merits, because daemontools-ish alternatives to systemd were quite immature in 2014, but that is no longer the case, as has been shown above. And no, developers of free / open source software should not practise the EEE ploy even when the latter is not forbidden by the licence, as long as one assumes FOSS developers should have higher moral standards than other developers do.
• "systemd is actually Unix-ish because it uses Unix-ish features like cgroupfs."
I believe the essence of the Unix philosophy is the minimisation of the total cognitive complexity of the system while almost satisfying the requirements (cf. Section 07 of my document), which in my opinion is the key to technical excellence of all software projects (cf. Section 08-09 of the same document). From the comparison between s6/s6-rc and systemd, we can clearly see that the quoted statement misses this essence, because systemd duplicates existing system functionalities in an unnecessary and low-quality fashion, because systemd has tight coupling and many unnecessary external dependencies, and because systemd modules work badly whether in isolation or in combination.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Last edited by CasperVector on Mon Dec 30, 2019 8:45 am; edited 12 times in total |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Wed Dec 25, 2019 8:18 pm Post subject: |
|
|
| CasperVector wrote: | | • Networking is currently configured with the `network' oneshot and user-added networking longruns like `dhcpc.eth0', `wpasup.wlan0' etc. For newbies, this can be quite a challenge; some kind of higher-level abstraction, analogous to Gentoo's netifrc, Debian's ifupdown and Ubuntu's netplan, will certainly be desirable. However, since I am not very familiar with the configuration of many networking schemes, how to optimally construct such an abstraction is a non-trivial problem; if you happen to be savvy in this, I would be very grateful if you can give your thoughts on a plan for the abstraction, preferably in an "issue" on the slew homepage. |
I just run dhcpcd -MBp on everything and configure the network centrally. It doesn't need tons of resources or deps and supports everything netifrc does. |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Thu Dec 26, 2019 5:34 pm Post subject: |
|
|
| Ant P. wrote: | | I just run dhcpcd -MBp on everything and configure the network centrally. It doesn't need tons of resources or deps and supports everything netifrc does. |
Well, I think what dhcpcd can do is quite a small fraction of what netifrc can do.
(And I am a little unsatisfied with dhcpcd's lack of a specification on behaviours upon signals, like that of udhcpc.)
The netifrc design does seem suboptimal: it is essentially some kind of interpreter, but a compiler (of service definitions) is surely necessary for s6/s6-rc.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Thu Dec 26, 2019 5:37 pm Post subject: |
|
|
| CasperVector wrote: | | Myths |
This part has been expanded, and may be further extended depending on common criticism from systemd proponents.
(Sorry for my procrastination -- these posts have obviously taken more than just "a few days".)
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Thu Dec 26, 2019 9:19 pm Post subject: |
|
|
| CasperVector wrote: | | Ant P. wrote: | | I just run dhcpcd -MBp on everything and configure the network centrally. It doesn't need tons of resources or deps and supports everything netifrc does. |
Well, I think what dhcpcd can do is quite a small fraction of what netifrc can do. |
dhcpcd configures layer 3 and runs scripts to notify other services to react to network topology changes. If I want something to mess with my hardware directly, I run the appropriate daemon for that. I don't need a 250-line script from a systemd-esque framework to start wpa_supplicant when a 4 line runit one would do. |
|
| Back to top |
|
|
sitquietly
Apprentice
Joined: 23 Oct 2010
Posts: 151
Location: On the Wolf River, Tennessee
|
| Posted: Thu Dec 26, 2019 11:20 pm Post subject: |
|
|
| CasperVector wrote: | Myths
I believe the essence of the Unix philosophy is the minimisation of the total cognitive complexity of the system while almost satisfying the requirements (cf. Section 07 of my document), which in my opinion is the key to technical excellence of all software projects (cf. Section 08-09 of the same document). |
Thank you for all of the time and work reflected in your writeup here and especially in your little book Unix Philosophy by Casper Vector. It's turning into a really good book, and I loved it as soon as I encountered the definition of that philosophy as "minimization of the cognitive complexity of the system while almost satisfying the requirements." Since I first discovered the Forth programming language while studying math and compsci at Brooklyn Polytech I've enjoyed using minimalist, extensible systems (operating environments and programming languages), which Unix can be, and I'm glad for one more signpost pointing that way. |
|
| Back to top |
|
|
eric_vidal
n00b
Joined: 27 Dec 2019
Posts: 1
|
| Posted: Fri Dec 27, 2019 5:22 am Post subject: |
|
|
I cannot be quiet when i read this post.
First, thanks for this hard works. This kind of post take time to be made and difficult to write in a proper way.
So, i'm the creator of 66 (https://framagit.org/obarun/66.git) and also the creator of Obarun (an arch based system which run s6/s6-rc as default init and service manager for almost 4 years now).
S6/s6-rc is a marvel and stable as a rock. But to be honest it can be difficult to implement and to handle from the scratch even if the documentation is clear and complete. Administrator can argue that some tools are missing to be used/maintained on system mostly if the system is a Desktop one.
S6-frontend program is planned by Laurent Bercot but it can be take time to be available (Yes, FOSS do not pay the bills).
So, i decide to make my own tools.
66 is a collection of system tools built around s6 and s6-rc created to make the implementation and manipulation of service files on a machine easier. It is meant to be a toolbox for the declaration, implementation and administration of services where separate programs can be joined to achieve powerful functionality with small amounts of code.
You can find a complete online documentation here : https//web.obarun.org/software.
66 do not use configuration file but it configured at compile time or directly on command line. It can build with musl.
66 provide a fontrend (http://web.obarun.org/software/66/frontend.html) file for services declaration which has a format of INI with a specific syntax on the key field. You can find several examples here: https://framagit.org/pkg/observice
For example wpa_supplicant frontend declaration file:
| Code: |
[main]
@type = classic
@description = "wpa_supplicant@@I daemon"
@user = ( root )
@options = ( log env )
[start]
@build = auto
@execute = ( execl-cmdline -s { wpa_supplicant ${cmd_args} } )
[environment]
cmd_args=!-c/etc/wpa_supplicant/wpa_supplicant-@I.conf -i@I
|
yes, 66 support instantiated service.
To enable and start it, simply
| Code: |
# 66-enable -S wpa_supplicant@wlp0s20u1
|
Some features available with 66:
- Frontend file for service declaration
- Multiple directories service file declaration(packager,sysadmin,user)
- Automatic resolution of service dependencies
- Automatic (but highly configurable) creation of a logger for a daemon
- External configuration file for environment variable declaration (/etc/66/conf): a simple 66-start -r foo command restart the service and reload his environment configuration file
- Centralization of information for a service (66-inservice)
This is an example of the 66-inservice tool
| Code: |
# 66-inservice docker
Name : docker
In tree : docker
Status : enabled, None
Type : classic
Description : docker daemon
Source : /etc/66/service/docker
Live : /run/66/scandir/0/docker
Depends on : docker-log
Optional depends : None
External depends : None
Start script : s6-ipcserver-socketbinder -a 0660 -- /run/docker.sock
if { chown root:docker /run/docker.sock }
/usr/bin/dockerd -H unix:///run/docker.sock
Stop script : None
Environment source : None
Environment file : None
Log name : docker-log
Log destination : /var/log/66/docker
Log file :
@400000005e02ebaa2a1e5ddd time="2019-12-25T15:54:29.706622842+11:00" level=info msg="ClientConn switching balancer to \"pick_first\"" module=grpc
@400000005e02ebaa2b909923 time="2019-12-25T15:54:29.730877988+11:00" level=info msg="parsed scheme: \"unix\"" module=grpc
|
instantiated service
Nested supervision tree: yes service can be run and started as regular user
declaration of service as a tree: bunch of service which be managed as one service
centralized information about all services running on the system: 66-intree
This is an example of the 66-intree tool
| Code: |
% 66-intree -g graphics
Name : graphics
Initialized : yes
Enabled : yes
Starts after : security
Current : no
Allowed : obarun
Symlinks : svc->source db->source
Contents : /
├─(1204,Enabled,longrun) gvfsd-log
├─(1210,Enabled,longrun) gvfsd
├─(0,Enabled,oneshot) numlockx
├─(1205,Enabled,longrun) compton-log
├─(1206,Enabled,longrun) dbus-session@obarun-log
├─(1226,Enabled,longrun) dbus-session@obarun
├─(1203,Enabled,longrun) notification-daemon-log
├─(1218,Enabled,longrun) notification-daemon
├─(1214,Enabled,longrun) compton
├─(1195,Enabled,longrun) pidgin-log
├─(1222,Enabled,longrun) pidgin
└─(0,Enabled,bundle) All@obarun
|
All tools can be run as regular user
Multiple declaration of scandir are supported (66-scandir): you can create a supervision tree completely independent from the pid1, enable any service inside, test your service/program and destroy it without impacting the state of your machine.
and so on
A complete set of service for the boot can be found here : https://framagit.org/Obarun/boot-66serv. This set is highly configurable and hackable but it works out of the box. Many POC was made in other on: Obarun(Arch based, yeah for sure), Antix,Devuan(Debian base),Void (which provide 66 natively on their repo),Adelie,Funtoo (yes gentoo man it works out of the box),..
Also it provide you an configuration file found by default at /etc/66/conf/boot.conf which is self explained
| Code: |
######################
## MAIN ##
######################
## Set the HOSTNAME.
HOSTNAME=S6
## Set RTC [UTC|localtime].
HARDWARECLOCK=UTC
## Set timezone, availables timezones at /usr/share/zoneinfo.
TZ=Pacific/Noumea
## keymap to load, see loadkeys(8).
KEYMAP=!fr
## Console font to load, see setfont(8).
FONT=!lat9w-16
## Console map to load, see setfont(8).
#FONT_MAP=
## Console unimap to load, see setfont(8).
#FONT_UNIMAP=
######################
## SECURITY ##
######################
## Active encrypted devices [yes|no].
CRYPTTAB=!no
## Use iptables [yes|no].
IPTABLES=!no
## Use ip6tables [yes|no].
IP6TABLES=!no
######################
## DEVICES ##
######################
## Mount devices from FSTAB file [yes|no].
FSTAB=!yes
## Mount cgroups [yes|no].
CGROUPS=!yes
## Active swap [yes|no].
SWAP=!no
## Active lvm devices [yes|no].
LVM=!no
## Active dmraid devices [yes|no].
DMRAID=!no
## Active btrfs devices [yes|no].
BTRFS=!no
## Mount zfs devices [yes|no].
ZFS=!no
######################
## SYSTEM ##
######################
## Kernel configuration with sysctl [yes|no].
SYSCTL=!yes
## Force a check of filesystem partition [yes|no].
FORCECHCK=!no
## Use rc.local script [yes|no].
LOCAL=!no
|
So, give a try to s6/s6-rc, you will not regret it 
_________________
Obarun: free to control your system |
|
| Back to top |
|
|
Amity88
Apprentice
Joined: 03 Jul 2010
Posts: 265
Location: Third planet from the Sun
|
| Posted: Fri Dec 27, 2019 7:12 am Post subject: |
|
|
@CasperVector,
Thank you so much for doing this write-up. Documenting stuff is hard and takes time, you've gone out of your way to explain this.
I'll now sit down quietly and read through it (hopefully experimenting with S6 as well)
_________________
| Ant P. wrote: | | The enterprise distros sell their binaries. Canonical sells their users. |
Also... Be ignorant... Be happy! |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Fri Dec 27, 2019 11:44 am Post subject: |
|
|
| Ant P. wrote: | | dhcpcd configures layer 3 and runs scripts to notify other services to react to network topology changes. If I want something to mess with my hardware directly, I run the appropriate daemon for that. I don't need a 250-line script from a systemd-esque framework to start wpa_supplicant when a 4 line runit one would do. |
What you say is quite close to what I meant by mentioning interpreters (like `mysqld_safe') and compilers (like `mariadb-service-convert').
netifrc, ifupdown and netplan are all programs with hundreds to thousands of SLOCs that interpret (do something based on) their configs.
However, with given config, the effects of these programs can always be translated to some set of services, which will be much simpler.
Therefore a compiler (translator) from configs to sets of services will save us (and the machine) much energy on analysing the configs.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Fri Dec 27, 2019 11:46 am Post subject: |
|
|
| sitquietly wrote: | | Since I first discovered the Forth programming language while studying math and compsci at Brooklyn Polytech I've enjoyed using minimalist, extensible systems (operating environments and programming languages), which Unix can be, and I'm glad for one more signpost pointing that way. |
Thanks, and given this background I sincerely hope you enjoy the third part (about Unix and Lisp) of the document
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Last edited by CasperVector on Fri Dec 27, 2019 2:05 pm; edited 2 times in total |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1857
Location: South America
|
| Posted: Fri Dec 27, 2019 1:06 pm Post subject: |
|
|
I have a Gentoo VM that I use for experimentation, and that can be booted with either sysvinit + OpenRC or s6 + s6-rc + s6-linux-init, by selecting appropriate GRUB menu entries. Rather than attempting to make (or use) more general tools like slew or 66, this is a personal setup I made by reading the /etc/init.d/* service scripts and /lib/rc/sh/init.sh, and turning the applicable subset into s6-rc services with execline scripts (just because I like execline, not because it is required for service definitions). So it is probably not shareable work, but perhaps it can count as a "success story"
I used s6 and s6-rc from Gentoo's repository with some modifications for split /usr with no initramfs, and a version of s6-linux-init that is not currently packaged (for those who know, the one that supports /etc/s6-linux-init/current/scripts/rc.shutdown.final) by modifying the ebuild of the version that is packaged, and using dirty linker hacks.
| Code: | $ grep PRETTY_NAME /etc/os-release
PRETTY_NAME="Gentoo/Linux" |
| Code: | $ ps axf -o pid,tty,args
PID TT COMMAND
[...]
1 ? s6-svscan -st0 -- /run/service
64 ? s6-supervise s6-linux-init-runleveld
72 ? \_ s6-ipcserverd -1 -c 1 -- s6-sudod [...] /etc/s6-linux-init/current/scripts/runlevel
65 ? s6-supervise s6-linux-init-early-getty
70 tty6 \_ agetty --nohostname -f issue 38400 tty6 linux
66 ? s6-supervise s6-linux-init-shutdownd
69 ? \_ s6-linux-init-shutdownd -c /etc/s6-linux-init/current -g 3000
67 ? s6-supervise s6-svscan-log
71 ? \_ s6-log -bpd3 1 t /run/uncaught-logs
80 ? s6-supervise agetty@tty3
344 tty3 \_ agetty 38400 tty3 linux
81 ? s6-supervise s6rc-oneshot-runner
97 ? \_ s6-ipcserverd -1 -- s6-ipcserver-access [...] s6-sudod [...] /lib/skarnet/s6-rc-oneshot-run [...]
82 ? s6-supervise agetty@tty4
350 tty4 \_ agetty 38400 tty4 linux
83 ? s6-supervise lvmetad
112 ? \_ lvmetad -f
84 ? s6-supervise VBoxService-daemon
420 ? \_ VBoxService -f
85 ? s6-supervise VBoxService-logger
356 ? \_ s6-log -d3 t /var/log/s6/VBoxService
86 ? s6-supervise dbus
353 ? \_ dbus-daemon --system --nofork --nopidfile
87 ? s6-supervise eudev
188 ? \_ udevd
88 ? s6-supervise s6rc-fdholder
119 ? \_ s6-fdholderd -1 -i data/rules
89 ? s6-supervise agetty@tty5
359 tty5 \_ agetty 38400 tty5 linux
90 ? s6-supervise agetty@tty2
366 tty2 \_ agetty 38400 tty2 linux
91 ? s6-supervise agetty@tty1
364 tty1 \_ /bin/login --
432 tty1 \_ -bash
469 tty1 \_ /bin/sh /usr/bin/startx
486 tty1 \_ xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 -auth [...]
487 tty7 \_ /usr/bin/X -nolisten tcp :0 -auth [...]
494 tty1 \_ /bin/sh /etc/X11/Sessions/openbox
556 tty1 \_ /usr/bin/openbox --startup /usr/libexec/openbox-autostart OPENBOX
[...] |
| Code: | # s6-rc -a list | sort
agetty@tty1
agetty@tty2
agetty@tty3
agetty@tty4
agetty@tty5
create-wtmp
dbus
devfs@devtmpfs
eudev
fsck
hostname
hwclock
keymaps
kmod-static-nodes
localmount
loopback
lvm
lvmetad
mount@-dev-pts
mount@-dev-mqueue
mount@-dev-shm
proc
root
run-lock
s6rc-fdholder
s6rc-oneshot-runner
swap
sysctl
sysfs
truncate-utmp
udev-trigger
urandom
VBoxService-daemon
VBoxService-logger
wipe-tmp
X11-tmp |
EDIT to add:
| Quote: | | [...] and a version of s6-linux-init that is not currently packaged (for those who know, the one that supports /etc/s6-linux-init/current/scripts/rc.shutdown.final) by modifying the ebuild of the version that is packaged, and using dirty linker hacks. |
s6-linux-init-1.0.3.1, which supports rc.shutdown.final, is now in the repository, as well as the more recent versions of other s6-related software that provide the updated libraries it needs, so the hacks are no longer needed.
Last edited by GDH-gentoo on Sun Jan 05, 2020 6:24 pm; edited 2 times in total |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Fri Dec 27, 2019 8:17 pm Post subject: |
|
|
| CasperVector wrote: | | Ant P. wrote: | | dhcpcd configures layer 3 and runs scripts to notify other services to react to network topology changes. If I want something to mess with my hardware directly, I run the appropriate daemon for that. I don't need a 250-line script from a systemd-esque framework to start wpa_supplicant when a 4 line runit one would do. |
What you say is quite close to what I meant by mentioning interpreters (like `mysqld_safe') and compilers (like `mariadb-service-convert').
netifrc, ifupdown and netplan are all programs with hundreds to thousands of SLOCs that interpret (do something based on) their configs.
However, with given config, the effects of these programs can always be translated to some set of services, which will be much simpler.
Therefore a compiler (translator) from configs to sets of services will save us (and the machine) much energy on analysing the configs. |
Thanks for explaining more. That does sound like a pretty reasonable idea, now you mention it I think OpenWRT does something similar (it doesn't have the RAM to fork hundreds of shell PIDs at startup, lua config generates startup scripts instead). |
|
| Back to top |
|
|
shevy
n00b
Joined: 28 Aug 2017
Posts: 16
|
| Posted: Sun Jan 26, 2020 4:21 am Post subject: |
|
|
> Many people, when arguing against systemd, say they do not need the fancy features provided by systemd, or that these features
> are implemented badly in systemd. In my opinion, these are not very strong reasons themselves, because systemd proponents can
> still argue that these features worked well enough for many people.
This is, in my opinion, pointless because the systemd-corporate hackers do not have INDEPENDENT datasets to verify this claim. Take the whitewashing
list that was built as a strawman "argument" by Poettering about the gazillion advantages that systemd should have. Everyone can write
a self-promo article and link it into some random website that is based on selling ads to the user (indirectly). There is no debate in such
articles.
I think the argument in regards to the functionality in systemd not working well is very sound and perfectly reasonable. Functionality
that has worked for me in the past, no longer did work. When I had a problem with dhcpcd and found out that systemd acted against
it, I uninstalled this trojan horse at once. I don't tolerate Red Hat controlling my simple stack. I have a systemd-free system and
appreciate it (admittedly not gentoo but alienbob's slackware variant).
The more lines of code, the higher the complexity and the stronger the burden on people in understanding it.
Common users do not even have a choice. Most distribution maintainers flat out abused them. We are not surprised about
Red Hat, since they paid for systemd, but look at what happened to debian and the fork of the oldschool debian into devuan.
If you look at distrowatch, devuan is right now (January 2020) ranked 50. That's not that bad really, so I don't think the
"argument" can be maintained that "these features work well enough for many people" - if that were the case, devuan would
not be ranked there AT ALL. (It was at rank 35 or so a few weeks before; obviously distrowatch fluctuates).
The reality is that most people don't even know; and then, after that, many people don't care either way. The number
of pro-systemd people is VERY, very low; and the number of non-Red Hat pro-systemd people is even smaller. There is a
huge conflict of interest in Linux in general, increasingly so in the last few years. Why is DRM included into the
kernel, for example? Surely that isn't because the general user voted for DRM inclusion.
> To truly prove systemd's deficiency, truly workable alternatives [...]
See - I already have a problem here because when the term "alternatives" is used, do you mean an ALTERNATIVE to
systemd? Because I think this would be wrong. An "alternative" would just incur the same problems that systemd assimilated
away from the linux stack.
> to my knowledge, daemontools-ish init/rc systems, best represented by s6/s6-rc, offer features comparable with
> those provided by systemd
So wait a moment ... you are saying that the argument that systemd is too complex, is not good - yet you then go on
and say that you look for full-feature replacement of systemd? Why?
I don't need any of the functionality that systemd offers, thankfully. Every job I do I solve via ruby scripts. That
is also something I never understood why systemd attacked shell scripts. Yes, they suck. I don't understand why I
would want to defend shell scripts - they are terrible.
Equally well I do not understand why anyone replacing shell scripts would imply to have a perfect, awesome
design. I think the systemd added way more problems than it ever solved.
> often implemented in ways vastly superior to those in systemd.
I like simplicity. But I believe the technical limitations of systemd or its intrinsic complexity, and not even the
paid corporate hackers working on it, were the most important aspect.
To me the most important aspect was how upstream people abuse downstream people. The debian situation was indeed
the most vile of these attacks.
LFS/BLFS went a better route aka let the user decide; as far as I know, gentoo follows a somewhat similar idea.
Arch also went the route of abuse-the-user.
To me these aspects were always the more interesting ones.
The other part is that I really really want to avoid IBM Red Hat as much as possible. They cause way too many issues
in the long run.
> Depending on your actual application scenario, sysvinit, OpenRC, or even upstart and systemd may actually be appropriate for your
> use, so this post does not attempt to persuade you to migrate to s6/s6-rc.
I had a look at the code of runit and sysvinit. Oddly enough I found the quality of the runit code to be inferior to sysvinit. I also
found both to be horrible - I am getting really tired of C. It is soooo unclear compared to ruby and python code. If someone could
come up with a very fast language that would be as clean as ruby and python ... (and no, crystal is not, Julia is not and so forth;
it is hard to design a FAST and CLEAN programming language).
> Instead, it just uses s6/s6-rc to help you understand how the most touted features in systemd can be better implemented
It is a good effort, so props for that - but I believe the way is not to try to clone-replace systemd. That would just lend credibility
that people would need systemd to do tasks. Or shell scripts for that matter.
People should move into higher-level languages. Nix and NixOS is a good example. Now, these clowns moved to systemd, so they are out
of the equation; and creating a new language just to describe the whole operating system, is very stupid too - it should be general
purpose.
BUT, having said that ...
I think the IDEA behind it is really really good. Of course NixOS lacks user choice, which is quite typical these days (developers
don't give a fudge about the user anymore, in many distributions;gentoo gives more choice but gentoo is, unfortunately, also
complex).
> and how necessarily (or not) these features are dependent on systemd's architecture.
Systemd will just keep on growing - the Red Hat corporate hackers want to sustain their job after all.
By the way, a bit off-topic but as noted down on https://sysdfree.wordpress.com/2020/01/05/294/
reddit has really going downhill. I have not been banned for speaking against systemd, but I have been banned from
the ruby reddit after critisizing the type madness (albeit they will be optional).
In all these discussion it seems that a few people will ALWAYS abuse others and ban/censor discussions. This to me is actually
more interesting than the more technical discussions about the various flaws in the ever-increasing systemd stack.
The other interesting change in the linux ecosystem is indeed the increase in corporate control. The DRM inclusion into
linux and wayland are a wonderful example. These are not because users want that - that is a lie. Private networks
want that and dish out money for it in order to find merc hackers who implement that. |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Sun Jan 26, 2020 6:44 am Post subject: |
|
|
| shevy wrote: | | I think the argument in regards to the functionality in systemd not working well is very sound and perfectly reasonable. [...] An "alternative" would just incur the same problems that systemd assimilated away from the linux stack. [...] So wait a moment ... you are saying that the argument that systemd is too complex, is not good - yet you then go on and say that you look for full-feature replacement of systemd? |
systemd does work badly for many people, but systemd fanboys would underplay the problems and instead focus on the "exclusive" features in systemd.
What I did above, is demonstrating that the former problems cannot be underplayed, and that the latter features can be done much better without systemd.
Some of the features are themselves good; some (eg. cgroups) are of limited benefits. They are at least harmless when done properly; I showed this above.
| shevy wrote: | | I had a look at the code of runit and sysvinit. Oddly enough I found the quality of the runit code to be inferior to sysvinit. I also found both to be horrible - I am getting really tired of C. It is soooo unclear compared to ruby and python code. If someone could come up with a very fast language that would be as clean as ruby and python ... |
These two page may explain some choices which I think make daemontools-ish init systems designed and/or implemented better than sysvinit.
Regarding the choice of a language, here is the shameless plug again: you may be interested in the third part of my document.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Last edited by CasperVector on Sun Jan 26, 2020 3:03 pm; edited 2 times in total |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Jan 26, 2020 11:43 am Post subject: |
|
|
| shevy wrote: | | I am getting really tired of C. It is soooo unclear compared to ruby and python code. |
Incredible! Back in the early '80s when I knew nothing about C, I could read published code and understand what it was doing.
Python and Ruby (and bash) are the obscure ones.
Then my company sent me to a one day seminar at AT&T (only a couple of miles away from us) and I received a copy of K&R there. Between the seminar and the book, I was soon pumping out C code. The seminar, which explained what was going on under the hood, was a big help in understanding why C was designed as it was. |
|
| Back to top |
|
|
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Sun Jan 26, 2020 12:13 pm Post subject: |
|
|
| GDH-gentoo wrote: | | I have a Gentoo VM that I use for experimentation, and that can be booted with either sysvinit + OpenRC or s6 + s6-rc + s6-linux-init, by selecting appropriate GRUB menu entries. Rather than attempting to make (or use) more general tools like slew or 66, this is a personal setup I made by reading the /etc/init.d/* service scripts and /lib/rc/sh/init.sh, and turning the applicable subset into s6-rc services with execline scripts (just because I like execline, not because it is required for service definitions). So it is probably not shareable work, but perhaps it can count as a "success story" |
Actually would you mind sharing it? I think it's way easier for people to modify a working installation rather than everyone trying to setup everything from scratch. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 4045
Location: Rasi, Finland
|
| Posted: Sun Jan 26, 2020 12:32 pm Post subject: |
|
|
This topic should be linked to https://wiki.gentoo.org/wiki/Comparison_of_init_systems.
@CasperVector: Maybe you could improve the comparison table over there? 
... With biased parts removed.
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Sun Jan 26, 2020 2:55 pm Post subject: |
|
|
Thanks for the suggestion. I will try to somehow merge the information from both sides...
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
wenguiGwok
n00b
Joined: 02 Dec 2017
Posts: 4
|
|
| Back to top |
|
|
jeffss
n00b
Joined: 13 Sep 2019
Posts: 59
|
| Posted: Mon Mar 09, 2020 12:21 am Post subject: |
|
|
| now there is yet another software based on s6, called 66, by obarun OS (but really generally portable on gnu/linux). Details here: https://web.obarun.org/software/66/ |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Mar 09, 2020 3:26 pm Post subject: |
|
|
| Maybe it is time to move on from openrc. But systemd is not the way to go. maybe S6 is. |
|
| Back to top |
|
|
fungalnet
n00b
Joined: 06 Jan 2018
Posts: 14
Location: Namimbia
|
| Posted: Sun Oct 11, 2020 8:16 pm Post subject: systemd and busybox |
|
|
Hi Casper and hi Eric, thank you both for your hard work and contributions. I use s6 and 66 and I can't think of a reason to use anything else. I use s6 because I think it is the most advanced system in its field. I use 66 because I am still too dumb to understand s6 really deep and 66 makes it easy to handle.
I have a question for any of you here that can contribute regarding systemd and busybox.
One of the criticisms about systemd is that it is presented as one piece of software, when in fact it is a whole bundle of software put into one and doing several different and unrelated tasks. And this is criticism because unix culture and tradition dictates that each piece of software should be made separately for doing one and only one thing and do it as well as the developer can make it do this task. So systemd is more like MS-windows software than unix software.
Why isn't busybox getting the same criticism. One package (usually) doing many different utility work and init, and ....
I am trying to understand the difference of the object of criticism. I have used busybox and I appreciate its simplicity and clarity, but why isn't it criticized fro doing the same as systemd?
_________________
obarun Void @ systemD Free Space |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Oct 12, 2020 2:19 am Post subject: |
|
|
| The targets are different. systemd is aimed at general purpose computers. Busybox is aimed at small embedded systems. The different things it does are the things needed to start a system, as opposed to managing the start of a system. systemd is a manager and busybox is the workers. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
