Hello all,

I did my Debian -> Devuan switch with a detour via Void Linux. I was blown
away
by the simplicity and the speed of their runit setup, so when installing
Devuan
I chose runit as the init system. I was disappointed to see that this is
not a
full-blown runit setup as it calls the sysvinit scripts - it only gives the
possibility to set up your own runit scripts in parallel.

So I decided to create a proper runit setup for myself. Now conceptually we
have 3
kinds of jobs that come into play here:

1. One-time jobs that are run at startup and shutdown. These are doing setup
that you don't want to mess with afterwards. On Void these are not even
standalone shell scripts but snippets that are sourced so that there are no
subshells started for maximum speed.

2. Jobs that are similarly of the setup/teardown kind, but you want to be
able
to turn them off and on while running the system. Potential examples are the
firewall rules or network filesystem mounts. Runit handles these with a bit
of a
hack, but it's simple enough.

3. Actual services that are managed by runit's supervisor.

In a sysvinit setup you have /etc/rcS.d and /etc/rc2.d (assuming the default
runlevel) roughly corresponding to #1 and #3. I'm saying roughly, because in
rcS.d for example we have rpcbind & nfs-common that should be run as runit
services and in rc2.d we have console-setup.sh that is obviously not a
service.

All this means that hybrid setups that partly rely on sysvinit might not
work
well. In my own setup I call the the necessary init scripts from my startup
scripts directly, irrespectively of where they are in the sysvinit dirs.

Later on the runit-scripts package became available, and I installed it so
that
I hopefully don't have to create runit scripts for a newly installed
service.

I was in for a bad surprise. The dhcpcd service was filling my logs,
complaining
about not being able to bind to eth1, which my box obviously didn't have.
1) Why
did a dhcpcd service start up when I didn't enable it, and it doesn't even
need
to run as the ifupdown framework can handle it? 2) Why does it have a user
config by default, referencing eth1? This should be a commented out
example, at
most. I deleted the symlink to the /etc/sv dir, effectively disabling the
service, only to return after installing some other package. I guess some
command needed to be run or file needed to be changed to disable this
automatic
respawning, but all this is about breaking the Principle of Least Surprise -
even in sysvinit it is OK to manually delete a symlink from rc*.d without
running
update-rc.d. Why does it want to re-enable a service I didn't want to start
in
the first place?

Overall I don't have a good impression of the Debian runit packages. First,
there's this tight coupling with sysvinit scripts. Startup calls into
/etc/rcS.d
by default, a wrapper is used to run the runit scripts instead of /bin/sh,
hooking into the init scripts, with /lib/lsb/init-functions.d/40-runit
hooking
back (which makes things like "invoke-rc.d rsyslog rotate" fail even
though the init script is there, because we have runit installed and it
tries to
invoke the runit script instead...).

Also there's the logging. As much as I love runit, I find its svlogd helper
useless. Preferably your logging should go through a log multiplexer, which
is
syslog. Syslog can then create logfiles per-app (every modern syslog can use
templates including time & date to name the files, while svlogd uses only
timestamps that are not human-friendly), all-in-one logs, send them to a
common
remote logstore and so on. This data multiplication might not make sense at
first, but troubleshooting sometimes needs not just the logs of one app,
but the
context of the whole system, or even multiple systems. This is why syslog is
superior to per-app logging, and Void does the right thing by using the
"logger"
program instead to send the logs into syslog for those apps that don't have
their own logging facilities.

I ended up uninstalling runit-scripts and staying with my own scripts. The
former is the perfect example of how to overcomplicate a very simple
concept by
creating all kinds of wrappers, meta-info etc. trying to be smarter than the
user and then failing.

All in all, I'm willing to help in creating a runit setup for Devuan,
hopefully without all the cruft and not relying on the sysvinit scripts.

Best Regards,
Lehel

Manfred Wassmann via Dng <dng@???> ezt írta (időpont: 2023. aug.
1., K, 17:43):

> On Tue, Aug 1, 2023 at 1:50 PM golinux <golinux@???> wrote:
>
>> On 2023-07-29 18:26, Steve Litt wrote:
>> >
>> > I suggest we form a runit script committee and a sysvinit script
>> > committee, each of which oversees a package of **all** init scripts.
>> > When peoplepower allows, we can also form an s6 scripts committee,
>> > which will work hand in hand with the runit scripts committee because
>> > s6 and runit are so similar.
>> >
>>
>> This idea was quite shocking and amusing at the same time . . .
>>
>
> ACK
>
>
>> Devuan is not a bureaucracy. We are a "do-ocracy". We do not flap gums.
>> We see a problem and find a way to fix it individually and/or
>> collectively as appropriate. What we need are more hands on deck and
>> less jawing. Would be delighted to have you on-board and leading the
>> init script restoration project, Steve. :)
>>
>
> You can find quite a few qoutes concerning committees, some of which may
> be inspirational here, like:
>
> *A committee is a group that keeps minutes and loses hours.*
> -- Milton Berle
>
> *A committee should consist of three men, two of whom are absent.*
> -- Herbert Beerbohm Tree
>
> *If Columbus had an advisory committee he would probably still be at the
> dock.*
> -- Arthur Goldberg
>
> *A camel is a horse designed by committee.*
> -- Alec Issigonis
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>