Re: wait(2) and SIGCHLD

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> but isn't what's supposed to happen when a child's parent is
>>> ignoring SIGCHLD - the child should skip zombie state, and simply
>>> be cleaned up.
>> And how is "reparent to init" not an acceptable means of
>> implementing that?
> Acceptable or not, it would seem to not match our own documentation.

Point.  That manpage wording should be updated a little.

>> I thought I'd seen some code that rendered init immune to SIGKILL
>> and possibly SIGSTOP too [...]
> SIGSTOP is one of two signals that a process supposedly should not be
> able to intercept.  Of course, init is special enough that normal
> rules might not apply...

Yes, the code I was thinking of was inside the kernel, where of course
rules like that apply only insofar as the code chooses to let them.

>> Right, they shouldn't be.  But init shouldn't be stopped, either.

>> Similarly, I think it should be impossible to ptrace init, [...]

> How special do one really want init to be?

As special as it needs to be.

I'm not as confident now as I was when I wrote that that ptracing init
should be impossible.  I do think it should be possible to configure a
system such that it's impossible, and that that should be the default.
But, as someone who routinely goes under the hood, I think it could be
very useful to be able to set a system up so that it's possible.

As a data point: I booted a scratch system (4.0.1, because that's all I
have on the most convenient scratch hardware), and neither
"kill -STOP 1" nor "kill -KILL 1" had any effect visible to ps ax.  I
don't know where/how they're getting stopped, but they are.

					Mouse