[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dng
Subject:    Re: [DNG] Systemd through the eyes of a musl distribution maintainer - Runit missing from the pictur
From:       Steve Litt <slitt () troubleshooters ! com>
Date:       2024-03-17 19:18:02
Message-ID: 20240317151802.4881dffc () mydesk ! domain ! cxm
[Download RAW message or body]

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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


[prev in list] [next in list] [prev in thread] [next in thread]