Ralph Ronnquist via Dng <dng@???> writes:
> On Sun, Apr 05, 2026 at 12:25:51PM +0100, Rainer Weikusat via Dng wrote:
>> Didier Kryn <kryn@???> writes:
>> > Le 04/04/2026 à 18:49, Rainer Weikusat via Dng a écrit :
>> >> int main(void)
>> >> {
>> >> extern int wait(int *);
>> >> while (1) wait(0);
>> >> return 0;
>> >> }
>> >
>> > Well, this is for the second-stage init; but it must also respond
>> > to reboot requests and, maybe, monitor at least one getty.
>> >
>> > And it comes after a first stage which needs to start some daemon
>> > launcher. Otherwise it is pointless to reap processes since there
>> > arent any (~:
>>
>> That's what the shell-script was for. At worst, if a shell script cannot
>> yet be executed (seems very improbable), one would need to use two
>> executable binaries, one which launches the startup script and then
>> execs the other which waits for orphaned processes. There's really no
>> reason why init should do anything else, this can all be provided by
>> other processes/ programs. Poettering is a dolt. Or an early attempt at
>> creating an LLM which went really awry.
>>
>> I might eventually create something that's compatible SysV rc based on
>> this idea. On the outset, it looks like an interesting project.
>
> Well "zombie eating" can also be done in a shell script, so you
> wouldn't need much as /init script. Perhaps like so (reflecting a
> "normal" idea of use of sysvinit):
> ------------------------------
> #!/bin/sh
> eatzombie() { X=$?; }
> trap "eatzombie" CHILD
> /etc/init.d/rc S
> /etc/init/d/rc 2
> ------------------------------
This won't work because there's no 1:1 correspondence between SIGCHLDs
generated for a process and child processes which exited. It also keeps
a shell running all the time which is a pretty complicated program.
> Though then here's also the startup of "getty"s for virtual terminals
> and protecting the pid 1 process against spurious signals, etc;
init will only receive signals it installed handlers for.
::
Re: [DNG] Good thing we don't use s…
