Hi!

Some of you seem to know it better than anyone else. The second mail in
a tone that borders on arrogance if you ask me. Care to open for the
possibility that others can do good things as well or at least thought
about how to do things and came to different conclusions?

That is exactly the tone and attitude that I disliked with Lennart
Poettering when experiencing how he dealt with some bug reports I was
involved with. He seems to know what is best for everyone. And of course
he is always right about it. Often enough it sounded that way to me.

Rainer Weikusat via Dng - 02.08.23, 16:39:01 CEST:
> Martin Steigerwald <martin@???> writes:
> > karl@??? - 01.08.23, 20:36:05 CEST:
> >> > I just don't understand why it should take hundreds of
> >> > lines of shellscript to run a simple command.
> >>
> >> For busybox I just use a handwritten /etc/rcS to do everything,
> >> about 112 lines on my personal box, makes life very simple tough
> >> not automatic.
> >
> > Some init scripts of SysVInit in Debian use a wrapper that can lead
> > to init scripts as simple as:
> >
> > % cat /etc/init.d/fio
> > #!/bin/sh
> > # kFreeBSD do not accept scripts as interpreters, using #!/bin/sh
> > and sourcing. if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
> >

> >     set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true .
> >     /lib/init/init-d-script

> >

> > fi
> > ### BEGIN INIT INFO
> > # Provides:          fio
> > # Required-Start:    $syslog
> > # Required-Stop:     $syslog
> > # Default-Start:     2 3 4 5
> > # Default-Stop:      0 1 6
> > # Short-Description: Flexible I/O Tester as service
> > # Description:       Runs fio as a service to that fio clients can
> > connect #                    to it
> > ### END INIT INFO

> >
> > # Author: Martin Steigerwald […]
> >
> > DESC="Flexible I/O Tester as service"
> > DAEMON=/usr/bin/fio
> > DAEMON_ARGS='--server --daemonize /run/fio.pid'
> > PIDFILE='/run/fio.pid'
>
> In this case, the mess has been pushed into something else. A typical
> init script I'm using looks like this:

Has it? I did not review what is being done in
"/lib/init/init-d-script". Did you?

They may by using "start-stop-daemon" or something like that. Well, they
do as I looked briefly. Whether "start-stop-daemon" is well implemented,
I did not check.

I reviewed some run scripts in runit-services and found them to simply
start the daemon with "exec" at the end. I liked that approach as well.
Maybe it would be better to do it this way, however Sysvinit is not
runit. For example it would need to know whether its stopping the same
process it started. So for Sysvinit you'd need some basic PID file
handling for example. Runit knows as the process it starts is child
process of "runsv". Also "init-d-script" handles logging of starting and
stopping daemons in a unified way.

Regarding your example:

> ,----
>

> | case "$1" in
> | 
> |     start)
> |     
> |         systemd-dance "$0" && exit 0

What is this? If not putting logic elsewhere?

The other commands could be some of the software you use here, I don't
know. But the "systemd-dance" command or script appears to be exactly
what you criticize below:

> [That's even with systemd support as I'm meanwhile forced to support
> it professionally.]
>
> There's little point in splitting this tiny bit of code into separate
> files just because that's technically possible.

Well to me there is: It gives an opportunity to unify behavior between
different scripts using the same framework. And if there is a bug it only
needs to be fixed in one place instead of in maybe dozen of init scripts.
"init-d-script" still gives opportunity to override behavior if need be.
But I am open to changing the init script I wrote back then for running
fio as a server to start fio directly.

Whether "init-d-script" is well done or not, I don't know. For me it
worked well enough.
?
> The historically accumulated mess in Linux init.d scripts is/ was
> indeed fairly gruesome. But that's just an example of poor
> programming/ software design and in not way tied to the arrangement
> used for running such scripts at certain times. Thus, the main
> argument of the Poetterclown was that "Look what a mess you've made
> of the stuff you've put into your old shelf! You absolutely need my
> New And Very Much Improved Shelf[tm] because of this!"

Well I agree the that there is likely to have been quite some mess in
init scripts and likely there still is. Lennart Poettering and other
Systemd developers replaced that mess with other mess if you ask me.
IMHO. Just coded in C and compiled into binary form.

That written, I still do not agree with the sentiment that every idea
and every part of Systemd is bad. But I have seen more than enough
examples of things that when I learned about it, I thought how could
they even come up with such bugs¹?

So I tend to agree with your in principle that that lower complexity
gives fewer issues and bugs and mess. In case you like to improve upon
init script handling in Debian, review my other mails. I wrote
everything I know about how to engage.

Just remember: When go you in with something like "your stuff is all
shit" then that probably won't trigger the cooperative response you
probably would like to see. A detailed feedback, in actionable pieces,
best with offer to help would surely give better results.

For me init scripts are not that important anymore. I do not completely
agree with all the design decisions in runit like logging to process
name in certain situations, but for me from the existing systems I know
so far it is still be best. s6 sounds interesting as well, but their
command names are cumbersome if you ask me.

[1] Like for example breaking big time with newer kernel versions:

https://velt.de/blog/sven/systemd-enterprise-grade-software

Ciao,
--
Martin