On 8/1/23 13:17, Bernádt, Lehel via Dng wrote:
> 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
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
I would just like to say how much I appreciate discussions like this on
the list. Lots of things have massively
improved since I dropped out over 20 years ago when after installation,
I had no mouse or keyboard and I was too
burned out to make a deep dive. I've been using Devuan almost from the
beginning but now its time to go deeper.
Thanks to Devuan, the logical principles of Unix are being preserved.
Thanks to all of you.
::
Re: [DNG] New goodies from systemd
