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.

Runit is missing from the picture. With runit you also know which
processes belong to a service and you do not even need control groups
for that. Runit does not need PID files either.

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

So what is even the point? Why not put this all into a run script to begin
with? 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

I do not even need to create the log dir, cause svlog can handle the
logging just fine. Not sure why they did on Systemd. Maybe they do not
trust systemd-journald?

I consider to contribute the run script. Not sure whether to suggest it
to the incus package manager or go straight for inclusion in
runit-services. I am tired of silly conflicts. But maybe I just ask the
maintainer(s) of Incus.

Also with run script you code for the desired state the service should
have when being running. I like how I see that good run script do not
assume things, but make sure.

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


In addition I wonder why another distribution? Adélie appears to be
based on musl. It appears to be based on Alpine. I quite like Alpine
especially for containers, however, now there is another distribution
based on it.

All well, folks can do all the distributions they want. But it is a lot
of duplicated effort if you ask me. And I only like to spend a limited
amount of time to explore new distributions. There is still void for
example I like to have a look at.


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.

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

and cryptic log file names of svlogd like: @4000000065f6a378183230e4.s

I'd really prefer something human readable like

% date -Iseconds
2024-03-17T10:49:10+01:00

But other than that… maybe some additional commands or tooling… like
a more extensive status output that shows which other processes belong
to a service… but really I see and appreciate how well designed Runit
really is. And adding to it needs careful, very careful consideration.

Just sometimes I wonder… why not build on runit or some other already
existing system instead of inventing a new one. It reminds me of:

How standards evolve: https://xkcd.com/927/

Thus I quite like the effort of Lorenzo with Runit and the runit-services
package. Run scripts are easy do to. It did not take me long to make
Incus work. I do not need a service file converter. Not at all.

Best,
--
Martin