Author Message

CasperVector









Joined: 03 Apr 2012

Posts: 155

ApprenticeJoined: 03 Apr 2012Posts: 155

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



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



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,



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 "



Quality



systemd proponents often claim systemd was modular, and meanwhile conveniently ignore the fact that systemd is



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



systemd developers claimed that systemd was designed to be



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



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.



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



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



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.



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

CasperVector









Joined: 03 Apr 2012

Posts: 155

ApprenticeJoined: 03 Apr 2012Posts: 155

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



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.

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



ip link set dev lo up

' > base/network/prep/up

printf 'ip link set dev eth0 up

exit 0



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

exit 0



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

On distributions where s6/s6-rc or their dependencies are unavailable (eg. CentOS) or crippled (eg. Deb ian ), 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 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:_________________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

CasperVector









Joined: 03 Apr 2012

Posts: 155

ApprenticeJoined: 03 Apr 2012Posts: 155

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



• "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 "



• "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 current OpenPGP key:

RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)

7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C 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.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.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.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.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.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

Ant P.









Joined: 18 Apr 2009

Posts: 6685

WatchmanJoined: 18 Apr 2009Posts: 6685

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.

CasperVector









Joined: 03 Apr 2012

Posts: 155

ApprenticeJoined: 03 Apr 2012Posts: 155

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

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

CasperVector









Joined: 03 Apr 2012

Posts: 155

ApprenticeJoined: 03 Apr 2012Posts: 155

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 "

_________________

My current OpenPGP key:

RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)

7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C 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

Ant P.









Joined: 18 Apr 2009

Posts: 6685

WatchmanJoined: 18 Apr 2009Posts: 6685

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

sitquietly









Joined: 23 Oct 2010

Posts: 103

Location: On the Wolf River, Tennessee Tux's lil' helperJoined: 23 Oct 2010Posts: 103Location: 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.

eric_vidal









Joined: 27 Dec 2019

Posts: 1

n00bJoined: 27 Dec 2019Posts: 1

Posted: Fri Dec 27, 2019 5:22 am Post subject:



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 (



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 (

For example wpa_supplicant frontend declaration file:



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

Some features available with 66: 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 So, give a try to s6/s6-rc, you will not regret it_________________Obarun: free to control your system

Amity88









Joined: 03 Jul 2010

Posts: 246

Location: Third planet from the Sun ApprenticeJoined: 03 Jul 2010Posts: 246Location: Third planet from the Sun

Posted: Fri Dec 27, 2019 7:12 am Post subject:



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)

_________________

@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! Also... Be ignorant... Be happy!

CasperVector









Joined: 03 Apr 2012

Posts: 155

ApprenticeJoined: 03 Apr 2012Posts: 155

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 `

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

CasperVector









Joined: 03 Apr 2012

Posts: 155

ApprenticeJoined: 03 Apr 2012Posts: 155

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

GDH-gentoo









Joined: 20 Jul 2019

Posts: 458

Location: South America GuruJoined: 20 Jul 2019Posts: 458Location: South America

Posted: Fri Dec 27, 2019 1:06 pm Post subject:



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.

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

Ant P.









Joined: 18 Apr 2009

Posts: 6685

WatchmanJoined: 18 Apr 2009Posts: 6685

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 `

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

shevy









Joined: 28 Aug 2017

Posts: 16

n00bJoined: 28 Aug 2017Posts: 16

Posted: Sun Jan 26, 2020 4:21 am Post subject:

> 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

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. > 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 whitewashinglist that was built as a strawman "argument" by Poettering about the gazillion advantages that systemd should have. Everyone can writea 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 sucharticles.I think the argument in regards to the functionality in systemd not working well is very sound and perfectly reasonable. Functionalitythat has worked for me in the past, no longer did work. When I had a problem with dhcpcd and found out that systemd acted againstit, I uninstalled this trojan horse at once. I don't tolerate Red Hat controlling my simple stack. I have a systemd-free system andappreciate 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 aboutRed 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 wouldnot 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 numberof pro-systemd people is VERY, very low; and the number of non-Red Hat pro-systemd people is even smaller. There is ahuge conflict of interest in Linux in general, increasingly so in the last few years. Why is DRM included into thekernel, 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 tosystemd? Because I think this would be wrong. An "alternative" would just incur the same problems that systemd assimilatedaway 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 systemdSo wait a moment ... you are saying that the argument that systemd is too complex, is not good - yet you then go onand 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. Thatis also something I never understood why systemd attacked shell scripts. Yes, they suck. I don't understand why Iwould 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, awesomedesign. 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 thepaid 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 indeedthe 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 issuesin 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 alsofound both to be horrible - I am getting really tired of C. It is soooo unclear compared to ruby and python code. If someone couldcome 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 implementedIt 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 credibilitythat 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 outof the equation; and creating a new language just to describe the whole operating system, is very stupid too - it should be generalpurpose.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 (developersdon't give a fudge about the user anymore, in many distributions;gentoo gives more choice but gentoo is, unfortunately, alsocomplex).> 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 fromthe 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 actuallymore 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 intolinux and wayland are a wonderful example. These are not because users want that - that is a lie. Private networkswant that and dish out money for it in order to find merc hackers who implement that.

CasperVector









Joined: 03 Apr 2012

Posts: 155

ApprenticeJoined: 03 Apr 2012Posts: 155

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

Regarding the choice of a language, here is the shameless plug again: you may be interested in the third part of

_________________

My current OpenPGP key:

RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)

7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C 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

Tony0945









Joined: 25 Jul 2006

Posts: 3988

Location: Illinois, USA AdvocateJoined: 25 Jul 2006Posts: 3988Location: 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.

Dr.Willy









Joined: 15 Jul 2007

Posts: 518

Location: NRW, Germany GuruJoined: 15 Jul 2007Posts: 518Location: 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.

Zucca









Joined: 14 Jun 2007

Posts: 1803

Location: KUUSANKOSKI, Finland VeteranJoined: 14 Jun 2007Posts: 1803Location: KUUSANKOSKI, Finland

Posted: Sun Jan 26, 2020 12:32 pm Post subject:



@CasperVector : Maybe you could improve the comparison table over there?

... With biased parts removed.

_________________

..: Zucca :..



This topic should be linked to https://wiki.gentoo.org/wiki/Comparison_of_init_systems : Maybe you could improve the comparison table over there?... With biased parts removed._________________..: Zucca :.. Code: ERROR: '--failure' is not an option. Aborting...

CasperVector









Joined: 03 Apr 2012

Posts: 155

ApprenticeJoined: 03 Apr 2012Posts: 155

Posted: Sun Jan 26, 2020 2:55 pm Post subject: Zucca wrote: 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.

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

wenguiGwok









Joined: 02 Dec 2017

Posts: 4

n00bJoined: 02 Dec 2017Posts: 4

Posted: Sun Feb 02, 2020 2:16 pm Post subject: just got s6 suite running

I just set up s6/s6-rc on my box and feel good.

For anyone who wants to see one more working example, check

To see how I made it, check Thanks for your hard work!I just set up s6/s6-rc on my box and feel good.For anyone who wants to see one more working example, check https://gitlab.com/miteigi/s6user To see how I made it, check https://miteigi.gitlab.io/gw3-s6-initrc.html

jeffss









Joined: 13 Sep 2019

Posts: 27

n00bJoined: 13 Sep 2019Posts: 27

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/

Tony0945









Joined: 25 Jul 2006

Posts: 3988

Location: Illinois, USA AdvocateJoined: 25 Jul 2006Posts: 3988Location: 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.