>>> 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
