Hi,

Il giorno mer 2 ago 2023 alle ore 15:37 Bernádt, Lehel via Dng <
dng@???> ha scritto:

> Hello all,
>
> [...]

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

it is the default in Debian to enable the service when the package that
ships
the binary is installed; runit-services emulates that behaviour.

2) Why does it have a user
> config by default, referencing eth1? This should be a commented out
> example, at
> most.
>
Mistake of mine


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

Try
# update-service --remove /etc/sv/servicename
or, if you don't want to use that
# mv /etc/service/servicename /etc/service/.servicename
services name that starts with a dot are ignored by runsvdir, so I'm using
"dot-links" to mark when a service is required to stay disable by the local
admin


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

if you delete all the links in runlevel 2-5 they will come back at the
first upgrade;
in runit there is only one "runlevel" managed by the package and if you
delete the link,
it comes back.
Links to enable services are created in /etc/runit/runsvdir/default, so you
can opt out the entire
mechanism by running in a non-default "runlevel";
it's possible force runit to boot in a custom runsvdir by writing the
directory name in
/etc/runit/default.runsvdir; the directory must exists in
/etc/runit/runsvdir/ and of course
you should link your services there before switching to it.
This way you'll have a setup where runit services are *never* automatically
enabled by
packages.

Overall I don't have a good impression of the Debian runit packages. First,
> there's this tight coupling with sysvinit scripts.
>

Inevitable: runit-init started with 0 runit services except the gettys, so
to produce
a usable system it used sysvinit scripts instead; as runit scripts are
slowly added
the coupling will be reduced.
However keep in mind that in Debian there are around 1300-1800 services,
while
the runit-services package will never ship more that 200 (maybe 300)
scripts, so
the sysv-emulation won't be dropped

Startup calls into /etc/rcS.d
> by default,
>
right, initscripts are used to initialize the system: given that runit is
an UNIX init
scheme with service supervision, I'm prioritazing the services over
initialization,
shutdown and oneshots tasks. I don't have enough time to do everything now

a wrapper is used to run the runit scripts instead of /bin/sh,
>

So everybody hates invoke-run, however
* a chain of exec is how deamontools like supervision works
* moving common code in a lib (instead of writing the same bits over and
over in each runscripts)
is usually a good practice
* it's really essential for long term maintainablility to be able to edit
one file (to fix a bug or add
add a feature) instead of edit let's say 100 scripts
* you can edit and adapt the script in /etc/sv/ to use /bin/sh


> hooking into the init scripts, with /lib/lsb/init-functions.d/40-runit
>

FYI: sysvinit scripts are run uncoditionally during package
install/upgrades,
via invoke-rc.d; without the 40-runit hack you get a duplicate (unmanaged)
instance
of the service in the best case, but you can also get a crash of the runit
service or in
some unfortunate case it can even break the packge upgrade.

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

I'm available to change this so that non-standard commands are forwaderd to
the
sysv scripts, my problem is: is there a non-standard command out there that
can break the correspondent runit service? who knows..

>
> 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'm available to add a switch so that all logs will go to syslog, please do
$ reportbug runit
keep normal severity, select "no tag", choose a title for the bug and use
the above
as bug text; I will produce a patch that you are required to test, then it
will be added
into the package in unstable

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

Perhaps it's overcomplicated, however if you do the comparison with
programs that perform the equivalent job for other init systems, you'll see
that with, for instance, sysvinit, the same complexity is there, but placed
in other
packages that are mandatory (init-system-helpers)
For example
*/lib/runit/trigger_sv does the equivalent job of update-rc.d and
invoke-rc.d,
plus logic that is usually written inside maintscripts of each deb package;
*metafiles expose some info that are usually passed to debhelper when the
package is built, and then hardcoded in maintainer scripts of the deb

trying to be smarter than the
> user and then failing.
>
> Epic fail of mine, then: the idea that is driving the packaging is actually
to set up an average installation that works by default for an occasional
average user (not necessarily a runit expert), while having all kind of
switches to customize and/or to opt out all the "Debian nunnery[1]" for
advanced users.

Note that I wrote the above in the hope to provide some trick for
customization and
to share some insight on why things are done this way; I don't expect Lehel
to like the runit packaging now. Anyway, sorry for the long and probably
boring
message.

Regards,
Lorenzo

[1] so defined by another unhappy advanced user

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
>

Il giorno mer 2 ago 2023 alle ore 19:29 Lehel Bernadt via Dng <
dng@???> ha scritto:

> Hi Martin,
>
> >Hmmm I think the runit-services package (it is not called runit-scripts)
> >uses a nice approach with cpsv. What do you disagree with?
>
> Normally your runit services should be under /etc/sv, with the ones you
> want
> to run symlinked into /etc/runit/runsvdir/<runlevel>. Now runit-services
> puts
> them into /usr/share/runit/sv (so that /etc/sv is not crowded with all the
> services without a corresponding installed package), and provides the
> helper
> cpsv to copy those into /etc/sv, and create the symlink to enable them.
>
> There are 2 separate tasks here that the command does:
> - Shadowing /etc/sv from a separate dir. I don't think this is really
> necessary to be honest, it's more like a convenience feature.
> - Enabling the service by creating the symlink. This is what update-rc.d
> does in
> sysvinit.
>
> A better approach would be to concentrate on the second task, and create
> runit-enabled versions of update-rc.d, invoke-rc.d etc. In Debian the
> default
> behavior is to start up a daemon when its package is installed (on Void
> the
> user needs to enable it manually), but this might not work well with
> runit. If
> you have an initscript that is driven by ENABLED=1 in
> /etc/default/<package>,
> then if this flag is set to 0, the script exits and that's it. With runit,
> when the symlink is created the service is already enabled in the sense
> that
> runsv will try to run it continuously. So this trigger of cpsv that both
> copies the service to /etc/sv and enables it should be rethought.
>
> >Hmmm the situation is definitely not easy at the moment. The Devuan/
> >Debian init diversity team is small. The Devuan developer team is also
> >small.
> >
> >Best changes are in case you really offer to help and engage and maybe
> >discuss your ideas on the Debian init diversity mailing list first.
>
> Alright, I understand. I know it's not easy to swim against the current.
>
> Best Regards,
> Lehel
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>