Didier Kryn said on Mon, 31 Jan 2022 10:27:53 +0100

>Le 29/01/2022 à 21:00, karl@??? a écrit :
>> I don't see the point in letting init do serious process monitoring.
>> Just use a minimal init and startup a separate process monitoring
>> daemon (or what theese things are called).
>>
>> ...
>> I don't see the point, learn to write good deamons. It seems the need
>> to use theese process monitors has sprung up from the availability
>> of shitty deamons.
>> In my view, when a deamon dies by any other cause than from your
>> will then it shall die so hard that it causes a major headacke and
>> the shitty programmer should be publicly flogged as a reminder and
>> example to other programmers -- well not really, but you get my
>> point.
>>
>> Most deamons I have run, they just run, they don't need a process
>> monitor except me.
>>
>     I fully share this pov. I'm happy with sysvinit or Busybox init. 
>If I was still active, and needing to write daemons, I would certainly
>welcome improvements on the following points:
>
>     - simplify start/stop scripts and find a better way to express
>their dependencies

Runit does that.

>     - help daemons ack when they're actually ready

Runit goes one better, by allowing you to put tests in the run scripts
of dependent processes to see when their dependencies are fully
functional. The beauty is that YOU decide the meaning of "fully
functional", not the daemon author, who might not understand your
individual situation.

>
>     Writing a self-daemonizing daemon in C was a routine when I was
>still active, though I understand it could be more difficult in shell.

But more difficult in Python. I try to stay away from C if Python does
the job. I think Python3 plus its standard libraries are more secure
than C code written by the error prone Steve Litt. As far as "routine",
I would think it's a lot more difficult to have a program doublefork
itself when finished than the 9 or so lines it takes to doublefork
something else.

I was unable to write a doublefork-something-else routine in /bin/sh.
Maybe smarter shellscript people than I can do it, but I can't.


>Also I like that the logs are sent to syslog.

I'm pretty sure runit can send logs to syslog.

>
>     But, as a user, I'm satisfied with sysvinit. Boot is so fast that
>I've abandonned the use of suspend/resume.

I'm pretty sure runit boots faster than sysvinit.

Also, an excellent move is to use sysvinit for PID1, and use runit for
most of the rest of your daemons.

About writing good daemons...

Sometimes, for my personal use, I want to write a quick and dirty
daemon in Python, and if it dies have runit run it again. If I were to
write a daemon where a crash would signify something terrible that
needs to be investigated, it can be run as a one-shot by any init
system. Whatever shellscript runs the daemon could end by getting $?
and if it's non-zero, make a lot of noise. This could also be done if
it's supervised.

So I still say daemons are usually best run in the foreground and
supervised by a supervisor. And therefore I'm not especially impressed
by finit.

Everything I said about runit in this email is also true of s6.

SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques