Re: abort() fails to terminate PID 1 process

[Igmar Palsenberg <igmar@palsenberg.com>]

> Whether you realize it or not, what you're saying is equivalent to
> saying that it's UB for a process that runs as pid 1 to call abort().
> There is no basis for such a claim.
> 
> A vague "pid 1 is special" rule (which the standard does not support
> except in a few very specific places where an implementation-defined
> set of processes are permitted to be treated in specific special ways)
> does not imply "calling a function whose behavior is well-defined can
> legitimately lead to runaway code execution if the pid is 1".

But doesn't "bevavior is well-defined" also imply that that function 
behaves as it should ? If it doesn't, doesn't the "well-defined" no longer 
apply ? I call it UB in this case.

The standard also says a process can't ignore a SIGKILL, but on pid 1, it 
has no effect. I pretty much call that UB myself.

> > Can this even be reproduced under normal circumstances (aka : not pid 1) ? 
> > If thes, then I agree : It's a bug. If no : Then not. If people have a 
> > broken container init system, then it breaks and they keep the pieces.
> 
> Yes.

It it can be reproducted when not pid 1, then agree, it's a bug.

> > > > Well, normally abort() does some signal magic, and then raises again. 
> > > > Which is what POSIX mandates I think.
> > > 
> > > To make this work reliably I think we need to make abort() take a lock
> > > the precludes further calls to sigaction prior to re-raising SIGABRT
> > > and resetting the disposition. But there are all sorts of
> > > complications to deal with. For example if another thread performs
> > > posix_spawn for fork and exec concurrent with abort() munging the
> > > disposition of SIGABRT, the child process could start with the wrong
> > > disposition for SIGABRT, which would be non-conforming. Finding ways
> > > to fix all places where the wrong behavior may be observable is a
> > > nontrivial problem.
> > 
> > Does the whole guaranteed termination also includes threaded programs ?
> 
> Of course. The fact that you're asking such basic questions tells me
> that you're bikeshedding this based on negative opinions of certain
> container usage cases and not offering constructive input based on
> what the specification actually requires.

I've seen this different in practice, that why I'm asking. I never 
debugged that one issue, it just "disappared" at a certain point, which I 
could never reproduce afterwards.

I'm not bikeshedding container usage, I'm just seeing broken implementation in the 
wild (which do get rapidly fixed usually).




Igmar