Martin Steigerwald said on Sun, 17 Mar 2024 10:57:46 +0100

>Hi Charles, hi.
>
>Charles via Dng - 16.03.24, 23:21:14 CET:
>> Here's an interesting take on systemd from a developer of another
>> distro:
>> https://catfox.life/2024/01/05/systemd-through-the-eyes-of-a-musl-
>> distribution-maintainer/ linked from an article in the Register.
>
>While I do agree that service files are not really the worst part of
>Systemd, I do not agree with some other parts of the review.

Yeah, the article seemed like a whitewash to me too.

>
>Runit is missing from the picture.

As usual. It's 2024 and they still frame it as systemd vs sysvinit.

>With runit you also know which
>processes belong to a service

I didn't know that. I thought a runsv spawned exactly one process. Of
course that process is free to spawn other processes.

>and you do not even need control groups
>for that. Runit does not need PID files either.

I lived my whole life without control groups and I don't feel my growth
has been stunted. I view this control group thing as just another
magnesium paddle shifter.


>Also service files have a serious disadvantage: If its not implemented,
>you need to use some shell boiler plate as well. Last time I came
>across this is with the LXD fork Incus:
>
>% cat /usr/lib/systemd/system/incus.service
>[Unit]
>Description=Incus - Main daemon
>[…]
>
>[Service]
>EnvironmentFile=-/etc/environment
>Environment=PATH=/usr/libexec/incus:/usr/sbin:/usr/bin:/sbin:/bin
>ExecStartPre=/usr/libexec/incus/incus-apparmor-load
>ExecStartPre=/bin/mkdir -p /var/log/incus/
>ExecStartPre=/bin/chown -R root:incus-admin /var/log/incus/
>ExecStart=/usr/libexec/incus/incusd --group incus-admin
>--logfile=/var/log/incus/incus.log ExecStartPost=/usr/bin/incus admin
>waitready --timeout=600 […]
>
>% head -2 /usr/libexec/incus/incus-apparmor-load
>#!/bin/sh
># incus-apparmor-load: Load AppArmor profiles, if supported by the
>system

Gross!

>So what is even the point? Why not put this all into a run script to
>begin with?

A combination of NIH, features for features' sake, and pandering to
fools who can't write shellscripts.

>I did and it goes like this:
>
>% cat /usr/share/runit/sv/incus/run
>#!/usr/bin/env /lib/runit/invoke-run
>#Copyright: 2024 Martin Steigerwald <[…]>
>#License: BSD-3-Clause
>

>exec 2>&1
>if [ -e /etc/runit/verbose ]; then
>        echo "Invoke-run: starting ${PWD##*/}"
>fi
>/usr/libexec/incus/incus-apparmor-load
>exec /usr/libexec/incus/incusd --group incus-admin

The preceding is why I prefer script syntax to declarative syntax. It's
one reason I prefer runit to the very fine Epoch init system.


[snip]

>Also service files are tons of complexity in itself. They are far more
>non portable than many people think. From a comment to above blog
>article:
>
>https://skarnet.org/software/s6/unit-conversion.html

Everybody: Please read the preceding URL. The knowledge required for
complete systemd unit creation is breathtaking, and most of it is
easily replaced by relatively simple shellscripts. The unit key->value
pair collection is so broad and complicated that, in the time needed to
learn it, one could become a ninja bash/sh/dash/ksh programmer plus
learning a hell of a lot of Python.

>All well, folks can do all the distributions they want. But it is a lot
>of duplicated effort if you ask me.

This is one issue with which I disagree with you. Lennart's propaganda
was that systemd would remove all need for multiple distros. Meanwhile,
if it weren't for a multiplicity of distros, I would have been forced
to leave Linux when systemd came along.

[snip]

>
>
>As a last note: Runit is not the holy grail. But from the stuff I have
>experience with for me it is the best alternative so far. s6 might be
>similarly good, however I really dislike the s6 command prefix. Runit
>has short and easy to remember commands. I like that.

Runit is so simple that I could write it from scratch if I wanted.
That's a good thing. S6 is a close cousin that includes a
mini-supervisor in PID1, and now there are add-ons to facilitate
ordered startup and mixing of one-shots with long-runs. Those who need
those features need S6, those who don't could use either. I use runit
over S6 because Void inits with runit.

>With runit I mostly dislike that logging within process name
>

>root      1306  0.0  0.0   2500  1152 ?        Ss   Mär16   0:01
>runsvdir -P /etc/service log:
>............................................................................................................................................................................................................................................................................check:
>3: socklog-check: not found
>............................................................................................

Yeah, the readproctile method of logging is almost useless. Mine is
always full although I detect no problems in the working of my system.
The error messages tell you what's missing, but not *which* directory
it exists in.

SteveT

Steve Litt

Autumn 2023 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21