Lennart Sorensen said on Fri, 1 Nov 2024 12:43:33 -0400
On Fri, Nov 01, 2024 at 04:36:53AM -0400, Steve Litt via talk wrote:
Initially I also thought systemd was too complex. Having worked with it for a while I eventually figured out why it had changed a bunch of stuff the way it did. The stuff it replaced was in fact not working well,
Was not working well in sysvinit. Works fine in runit and s6.
it was just traditional. As for attack surface, I am not convinced that is true. The amount of stupid mistakes one can make in a shell script that can be exploited is huge.
Here's my runit run script for sshd: ============================= #!/bin/sh exec 2>&1 ssh-keygen -A >/dev/null 2>&1 [ -r conf ] && . ./conf exec /usr/bin/sshd -D $OPTS ============================= The ss-keygen line generates host keys only if there are none. There's no conf file so the conf line is a no-op. Because there's no ./conf, $OPTS is an empty string. The -D in sshd runs it in the foreground, which is the right way to do things in an init system. A shebang plus four lines. Yeah, it's possible to screw up, but you have to be pretty careless to screw it up. Your wariness of shellscripts is perfectly understandable for sysvinit and OpenRC. But not for runit or s6: They're different animals. Now consider attack surface. IIRC systemd is 1.3 million lines of code. Runit is 47 thousand lines of code, 1/20 of the attack surface. I've looked at the runit source code: It looks pretty good and straightforward to me.
Blaming systemd for being successful is unfair.
Yes it is. But being successful isn't what I'm blaming it for. I'm blaming it for deliberately becoming inseparable from other software, and through marketing convincing software authors to include systemd-only code in their formerly init agnostic software, and convincing distros to package most/all their software to require systemd, which led to the recent supply chain attack against the recent CVE-2024-3094 exploit that came with hours of wrecking the Internet. Note that only xz and liblzma packages with systemd as a dependency suffered this.
I haven't seen any daemon that can't run without systemd, but certainly many do support it now.
:s/support/require exclusively/
Certainly in the case of Debian there has been a lot of arguing over systemd, and there are definitely other init systems available, but systemd is the one installed by default.
If you're saying that for better or worse systemd is Debian's only supported init system, that's true. If you're saying this Debian support is evidence of systemd's quality, that's completely wrong. Debian's 2014 decision to use systemd without requiring compatibility with any other init system was one of the most sleazy, kangaroo court railroad jobs there's been outside of politics and 1940's southern USA courtrooms. The powers that be cynically manipulated their voting system to place a no-op choice on the ballot so that what had been the plurality winner, which IIRC was either no systemd or systemd with sysvinit compatibility, was demoted, and then somehow used minor votes to put systemd over the former plurality. As far as the devs who originally voted on the systemd thing, it was something like 4 to 3.
And yes there are packages that no longer seem to provide sysvinit startup scripts because the package maintainer doesn't want to spend time on it since they don't use it and don't even have a system setup to test it on.
I'm not faulting that, and will not defend that lousy sysvinit in any way except that it does not obstruct the installation of any other init system. The sooner sysvinit is gone, the better I'll like it.
OK, all the ones you tried sucked. I know you never tried s6 because you never heard of it, and I have a feeling you never tried runit either. Those are the two best init systems.
It appears from the git tree that it came out in 2014 (version 2.0.0, I can't find any indication of a version before that). That's a bit late to the party as most major distributions had already gone to systemd by then. Even Debian had by that time and they were one of the last to do it.
It's been 10 years. Runit is tried and true. It's superior. You should check it out. Oh, and runit preceded the Debian systemd vote: runit was discussed in the mailing list civil war.
Why are shellscripts crappy? They're a wonderful way to boss your computer. Use the ksh scripting language and the shellcheck shellscript validation checker and you'll have a spectacular control over whatever you want. If you consider shellscripts bad, why use a Unix clone at all?
There is far far more to a unix system than shell scripts.
True.
Even a python script would give better control over things than a shell script. It seems a bit overkill though.
Python's great. I use it almost daily. Python is too slow for most system software. It also has a massive attack surface, just like systemd. By using dash or ksh instead of bloated bash for your shellscripts, you get fast loading and operation with a small attack surface. And you're right about overkill: The shellscripts used for runit are almost always less than 10 lines of simple shellscript code.
Dealing with arguments and quoting and such in a shell script is very error prone.
The preceding is an understatement. It seems like you start out doing something as a shellscript, and as you incorporate more features/requirements all of a sudden the whole thing seems to just collapse on itself. But there's a solution called shellcheck (https://www.shellcheck.net/) that reads your shellscript and tells you what's wrong with it and how to fix it. Once you fix all your errors and warnings, the shellscript typically does just what you want. Also, during the planning stage, if it looks like your shellscript will exceed 100 lines when done, it's best to use a different language. But 90% of the time runit uses shellscripts less than 10 lines, and I don't think I've ever seen a runit run script exceed 25 lines.
systemd avoids that by not using a shell to launch processes at all.
That is a lot safer. Less flexible,
Much less flexible.
but much safer
A little safer.
and less error prone.
A little *more* error prone. Have you seen all the different variations of keys that can go in a unit file? Have you noticed that a lot of them seem to do the same thing on viewing the names, but you need to read some pretty voluminous documentation to understand when to use each key.
I want my system to work. Building from source and tweaking was fun and interesting at the start, but that was 30 years ago.
"Building from source and tweaking" is an inaccurate description of life with runit. You don't mess with anything unless you install your own daemon.
To me distributions like Gentoo are a joke. Their focus is something that is a complete waste of time. There is no point building everything from source on every machine. There is no benefit just wasted CPU cycles. I can't recall which linux distribution used to claim that it made a difference that you optimized everything for your particular CPU model at compile time, but again, what a waste of time.
Yeah, Gentoo is made for a different breed of cat.
Looking at the packaging file to see how things are being built is definitely interesting and you can learn from it, but that doesn't mean you need to actually spend time doing it to learn.
I'm glad I've installed Gentoo and Funtoo, and learned quite a bit. But I don't use them in daily life for the reasons you articulate.
What you have in systemd is a notification of when the process *says* it's ready to work, which may or may not be true information. The way s6 and runit work, you devise an easy test to *prove* the process is ready to work, and act accordingly. Runit has complete monitoring and control of processes via its sv program, and s6 has something equivalent.
I would think if it isn't true then that is a bug in the service that should be fixed.
*Should* be. I'm not holding my breath.
And making an external test could be rather complicated.
========================================== if ! ping -c2 8.8.8.8 > /dev/null; then sleep 1 exit 1 fi ========================================== In the preceding test for a working network, substitute whatever IP address you consider "always up" for 8.8.8.8. I think you can get away without the sleep, but I keep it in there just to make sure I don't create a race condition. Sounds annoying. A proper test is not a bad idea, but I
am not sure the complications of implementing it are worth it.
Not complicated at all. For instance, if it's a Postgres database, just execute a psql command the performs a quick and simple SELECT statement that proves or disproves that a database is ready to use.
S6 and runit do that.
Well it seems s6 was too late to be relevant. Runit predates systemd by about 6 years. There must have been some reason it didn't catch on instead of sysvinit at the time.
F o l l o w t h e m o n e y . The systemd takeover was bankrolled by Red Hat, a hugely capitalized giant. Their motive was uttered by their former CEO years before systemd: https://asay.blogspot.com/2006/10/interview-with-red-hat-cto-brian.html Summary: Red Hat requires complexity to make money. Anyway... Seriously, install Void Linux on a VM or unused hardware. With Void you can even install Gnome, gdm, KDE, Pulseaudio, and most of the other "user friendly" stuff. I think you'll like it, and have very little hassle from runit once you learn the ln -s command to enable a daemon and get some skill with the sv command (man sv and learn only the status, up and down subcommands). SteveT Steve Litt http://444domains.com