Steve Litt via talk wrote on 2024-11-01 12:55:
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.
What does the `exec 2>&1` on a line after the shebang do? How does that script handle restarts? If sshd goes down, what happens? My system will restart on failure unless exit code 255 from sshd occurred: Restart=on-failure RestartPreventExitStatus=255
I'm blaming it for deliberately becoming inseparable from other software
The blame lies with "the other software", whose developers probably just want to support the most common environment. I can't blame them. Again, when one is receiving something for free, it's unseemly to demand it be given in a manner that increases the burden of the giver.
and through marketing convincing software authors to include systemd-only code
Conspiratorial codswallop. Devs want to dev, not faff about with init systems. It's not like "systemd™ Inc.®" spent advertising dollars targeting devs.
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.
Note also that systemd was in the process of releasing statically linked versions of their binaries to prevent such attacks, which rushed the malware. (Which will lead to retro-techno folks to moan about statically linked binaries.)
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.
Hyperbole much?
It's been 10 years. Runit is tried and true. It's superior.
Opinion, not fact established by evidence.
You should check it out.
I am (we are?) satisfied with what we've got, so that seems like a waste of time. As Evan(?) said, we're trying to get stuff done, not bask in the ideological purity of the underlying software. As long as it's FLOSS, don't really care. And, systemd is FLOSS.
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.
I'm still waiting for a citation that "What you have in systemd is a notification of when the process*says* it's ready to work", because that Is. Not. True. Unless I missed something, was there a reply to the several types of execution "Type=" I posted earlier?
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.
So, if a 2-ping test fails, sleep one second (why, hasn't it already failed?), and exit 1 (a failure state) is the solution? Why the `sleep 1`? What if it takes longer than 2 ping packets for the network to come up for some reason? What if 30 seconds is the desired wait time? This will wait for the network to come up:
After=network.target
and
TimeoutSec=90
will fail the startup after 90 seconds.
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.
Just one test? What if the DB is in recovery mode and takes a while? Loop the calling of `psql`? How many times, for how long? Such a hack of a method when what we have is so much better.
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.
I pay nothing for systemd. Canonical users pay nothing for systemd. No one pays for systemd. RedHat initially went with Canonical's Upstart until systemd was deemed better. If RedHat went with Runit, they'd still sell support.
Summary: Red Hat requires complexity to make money.
Then you'd think Canonical and Suse would have gone with Runit, won over all the pissed off ex-RedHat clients, but that didn't happen. Silly conspiracy is silly.
Seriously, install Void Linux on a VM or unused hardware.
Void Linux is probably fine, but no amount of evangelizing is going to win converts who are just trying to get shit done and don't want to be techno hipsters.