:: Re: [DNG] Reaping orphan processes.
Top Page
Delete this message
Reply to this message
Author: Didier Kryn
Date:  
To: dng
Subject: Re: [DNG] Reaping orphan processes.
Le 06/03/2023 à 00:12, Steve Litt a écrit :
> Rainer Weikusat via Dng said on Sun, 05 Mar 2023 19:31:09 +0000
>
>> Steve Litt <slitt@???> writes:
>>> There's no such thing as "init". There are many "init systems", but
>>> no such thing as "init".
>> There's absolutely such a thing: init is a UNIX program which has
>> existed since at least 6th edition UNIX
> I'm snipping your historical and technical post, which is factually
> correct except you should have said "init system" or PID1 or the name
> of a specific init system, depending on what you were trying to express.
> Using the word "init" as a name of a program is misleading and ambiguous
> because what you're really referring to is either sysvinit, in which
> case that should be stated, or the entire set of init systems, which
> should be stated.
>
> Now let me tell you why I care...
>
> The systemd cabal (poeterpuke's word, not mine) continually used the
> word "init" instead of sysvinit in order to misleadingly imply that the
> only choices were sysvinit or systemd. Sometimes they threw Upstart
> into their propaganda to satisfy those with an IQ over 80.
>
> Calling PID1 plus necessary instantiation and daemon management "init"
> enabled them to compare their massively entangled monolith only to
> sysvinit, which is a much easier job than comparing it to runit, s6,
> OpenRC, Busybox Init, and sysvinit PID1 plus [runit | s6 | OpenRC].
>
> Applying the word "init" to either PID1 or PID1 plus instantiation and
> daemon management aids the systemd aficionados' propaganda effort.
>
> Contrastingly, when you use the phrase "init system" to stand for the
> generic concept of PID1 plus instantiation plus daemon management, your
> meaning is unambigous and does not aid potterpunk's (now microsoft's)
> propaganda efforts.
>

    I think we are sharing the opinion that daemon management should be
kept out of the proper job of Pid1. The first massive regression of
Systemd is to include it (due to the hidden goal of locking down the
OS). I think the emerging conception is that daemon management should be
handled by a dedicated service which is started by Pid1.

    Sophisticated daemon management is too complex and does not need to
be included in Pid1. This management has been made even easier since
kernel version 3.4 with the concept of subreaper. At the maximum, Pid1
might monitor the daemon manager, like Sysvinit uses to manage getty.

    AFAIU s6-rc and openrc aren't meant to be Pid1. In this spirit,
there is no real need to replace Sysvinit, which has demonstrated
extremely high reliability and is perfectly able to monitor any daemon
manager if this is ever necessary; replacing it is essentially an
exercise of style; only the replacement of the Sysv-RC machinery is usefull.

--     Didier