I was the primary maintainer for Arch's init scripts for a while and I can share a couple of thoughts

I was the primary maintainer for Arch's init scripts for a while and I can share a couple of thoughts.

Arch's initscripts were incredibly stupid. In their first phase, there was a static set of steps that would be performed on every boot. There was almost no way to adjust the behaviour here. In their second phase, the configured daemons were started in order, which only meant that a init scripts were called one after another.

In the early 2000s, that seemed like a good idea and has worked for a while. But with more complex setups, the shortcomings of that system become apparent.

>With hardware becoming more dynamic and asynchronous initialization of drivers in the kernel, it was impossible to say when a certain piece of hardware would be available. For a long time, this was solved by first triggering uevents, then waiting for udev to "settle". This often took a very long time and still gave no guarantee that all required hardware was available. Working around this in shell code would be very complex, slow and error-prone: You'd have to retry all kinds of operations in a loop until they succeed. Solution: An system that can perform actions based on events - this is one of the major features of systemd.
>Initscripts had no dependency handling for daemons. In times where only a few services depended on dbus and nothing else, that was easy to handle. Nowadays, we have daemons with far more complex dependencies, which would make configuration in the old initscripts-style way hard for every user. Handling dependencies is a complex topic and you don't want to deal with it in shell code. Systemd has it built-in (and with socket-activation, a much better mechanism to deal with dependencies).
>Complex tasks in shell scripts require launching external helper program A LOT. This makes things very slow. Systemd handles most of those tasks with builtin fast C code, or via the right libraries. It won't call many external programs to perform its tasks.

[cont.]

Attached: 1521210418682.jpg (2100x2556, 1.21M)

Other urls found in this thread:

bugs.gentoo.org/391945
twitter.com/SFWRedditVideos

>The whole startup process was serialized. Also very slow. Systemd can parallelize it and does so quite well.
>No indication of whether a certain daemon was already started. Each init script had to implement some sort of PID file handling or similar. Most init scripts didn't. Systemd has a 100% reliable solution for this based on Linux cgroups.
>Race conditions between daemons started via udev rules, dbus activation and manual configuration. It could happen that a daemon was started multiple times (maybe even simultaneously), which lead to unexpected results (this was a real problem with bluez). Systemd provides a single instance where all daemons are handled. Udev or dbus don't start daemons anymore, they tell systemd that they need a specific daemon and systemd takes care of it.
>Lack of confiurability. It was impossible to change the behaviour of initscripts in a way that would survive system updates. Systemd provides good mechanisms with machine-specific overrides, drop-ins and unit masking.
>Burden of maintenance: In addition to the aforementioned design problems, initscripts also had a large number of bugs. Fixing those bugs was always complicated and took time, which we often did not have. Delegating this task to a larger community (in this case, the systemd community) made things much easier for us.

[cont.]

I realize that many of these problems could be solved with some work, and some were already solved by other SysV-based init systems. There was no system that solved all of these problems and did so in a realiable manner, as systemd does.

So, for me personally, when systemd came along, it solved all the problems I ever had with system initialization. What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. You can say what you want about Poettering, but he actually realized what the problems with system initialization were and provided a working solution.

I could go on for hours, but this should be a good summary.

>systemd defense force
sysvinit wasn't perfect, but that doesn't make systemd good. it's another dimension of retardation.

Attached: 1504983481946.jpg (280x280, 13K)

Excellent arguments, as always.

Is there actually any decent alternative for systemd that also uses declarative config instead of having to write shitty bash scripts for every single basic thing?
From what I'm reading OpenRC/Runit use scripts so they're out, launchd uses XML (and I think the FreeBSD port was dropped?). Is there anything else?

>copies some old reddit post
also
>disregards the fact that the other current alternatives like OpenRC don't have the same issues that the arch garbage init scripts had

Last I checked, OpenRC doesn't provide a solution to pidfiles like cgroups, or fix udev/dbus service activation, or machine local configuration

bugs.gentoo.org/391945
openrc is shit though

>bugs.gentoo.org/391945
>feature never considered stable is unstable
oh no

Why would you add a feature if you can't get it right?

>it's not a bug bro
Just like systemd

Works on my machine

lmao it's only bad when systemd does it

>pidfiles
The solution to pidfiles is to patch the software to stop forking and use a real supervisor (e.g. not openrc).
Alternatively, implement a fix for the shitty daemons outside of your supervisor and outside of your init.
>udev/dbus service activation
This shit shouldn't exist and it's not the job of the init or supervisor to work around this brain damage.
>machine local configuration
What is this and what does it have to do with init / supervision?

What's wrong with openrc/runit scripts? You literally only have to write the command. It's way shorter than Systemd's service files

>but muh no shell overhead
>but muh less error prone
>but muh random options nobody really ever uses which can be turned into a wrapper instead and then don't have to be coupled to a supervisor
>but muh cgroups
>but muh timers
>but muh overrides
Don't bother with these people. They are delusional.

spawning a thousand shells just to boot.

>thousand
>has never actually looked at how a runit based system boots
Please do your research before making yourself look like a retard.

$ pgrep runsv|wc -l
Now, kindly fuck off.

If I was on my machine it would give a count of 10.
10 is a lot less than 1000 user. How do you explain that? Do you realise that runsv isn't a shell? Do you realise that no shells continue running when the system is booted? Do you realise that lightweight /bin/sh implementations and execline exist?
Of course you don't user, you're a based systemdfag spammer.

>10 is a lot less than 1000 user
Because you're barely running anything on your toy runit-init'd system.

tl;dr

Attached: didnt read.gif (490x360, 3.49M)

>Because you're barely running anything on your toy runit-init'd system.
Who runs 1000 daemons on anything? My server runs 21 services (nginx, opensmtpd, dovecot, teamspeak3 server, murmur, sshd, znc, authdaemond, dbus, spampd, dkimproxy_in, dkimproxy_out, named, fcgiwrap, php-fpm, cronie, spamassassin, mariadb, haveged, ntpd) that would be 21 instances of runsv. runsv has no more overhead than systemd once it's running. What the fuck are you on about?

>What the fuck are you on about?
launch runsv -> one fork
launch the actual service -> two forks
You're double-forking, FFS.

>But with more complex setups, the shortcomings of that system become apparent.
Arguably, this is your core problem.

>You're double-forking, FFS.
Do you know what that means? No, of course you don't, systemdfags are too coddled to actually understand the dumb problems their system management software is having to solve.
Also, nice job evading the rest of my response.

>The solution to pidfiles is to patch the software to stop forking and use a real supervisor (e.g. not openrc).
You don't need them to stop forking; just set PR_SET_CHILD_SUBREAPER on the process starting them.

There are lots of disadvantages to using PR_SET_CHILD_SUBREAPER over fixing the software.
But you're right, this is ONE option.
But I still maintain that double forking is an unnecessary hack and should be optional on all modern daemons and capable of being disabled on older daemons.

>double-forking
Forking twice in a row. Generally the second parent exits, and the service parent becomes init.
It's a ugly hack, and irrelevant as nobody is doing that anymore.
>you're double-forking ffs
A joke on that. Forks+execs are costly, and doing it twice just to launch one service is silly. supervisor/daemontools was a shitty but useful hack that did its job. Now there's better, like systemd. Runit is silly.

>fixing the software
Forking and exiting is a good way of communicating that your daemon has finished initializing.

>Forking and exiting is a good way of communicating that your daemon has finished initializing.
Fuck no. And what a sane init should do when faced with that is kill the whole cgroup and respawn the service, then throttle that as it keeps doing the same. Until someone actually fixes the service.

Write a medium blog post and put this on hackernews for it to reach an audience than can understand and appreciate it.

>Generally the second parent exits
So you don't know.
This second exit is not optional. It's what seals the deal, the idea is to reparent the fork to pid1. Having two forks is not the same as double forking.
>A joke on that. Forks+execs are costly, and doing it twice just to launch one service is silly. supervisor/daemontools was a shitty but useful hack that did its job. Now there's better, like systemd. Runit is silly.
If you're on a potato then maybe an extra two forks and an extra exec are very costly but in reality the 20 threads or 10 forks each of your major services or user processes is going to produce is going to be more overhead. This isn't real overhead, it doesn't slow boot, runit boots as fast as systemd and in some instances of misconfiguration even faster than systemd.
What brain damaged reasoning. It's an awful way of communicating that the daemon has finished initializing and it's not even ubiquitous. The disadvantages of this method don't outweigh the apparent benefit.

>weeb
>contribute anything

Attached: 1524782446911.jpg (500x605, 95K)