On Sun, Apr 05, 2026 at 01:29:08PM +0100, Rainer Weikusat via Dng wrote:
> 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.
You are wrong. Did you test it?
When the zombie process gets reparented to become an init's child,
init gets a CHILD signal. The zombie process stays zombie until its
return code is read.
>
> > 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.
I guess you mean, that like any process, "init" will only handle
signals that it has handlers for, and ignore those it has blocked.
A process has no say in which signals it receives.
Ralph.
::
Re: [DNG] Good thing we don't use s…
