Re: abort() fails to terminate PID 1 process

[Szabolcs Nagy <nsz@port70.net>]

* Igmar Palsenberg <igmar@palsenberg.com> [2016-06-20 11:02:15 +0200]:
> > #include <stdlib.h>
> > int main ()
> > {
> > abort();
> > }
> > 
> > with "unshare --fork --pid" so that it runs as PID 1 in it's own PID
> > namespace.
> > 
> > Would it be reasonable to add a fallback strategy in abort() for terminating
> > processes when the signals don't have any effect?
> 
> This is a bad idea.
> 
> First, processes kan install handlers, which might 
> instruct the kernel to ignore the signal. SIGABORT can be ignored. I don't 

abort() should terminate the process even if SIGABRT is ignored.

> expect my process to be SIGILL'ed next because of this (which, can also be 
> ignored).
> Libc should NOT mess with these kind of things, that's up to the 
> application.

the glibc fallbacks are

change signal mask and set default handling for SIGABRT
raise(SIGABRT);
"abort instruction" (segfault, sigtrap or sigill depending on target)
_exit(127);
infinite loop

http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/abort.c;h=155d70b0647e848f1d40fc0e3b15a2914d7145c0;hb=HEAD

on x86 glibc, pid 1 would terminate with SIGSEGV
(unless there is a segfault handler).

the musl logic is explained in

http://git.musl-libc.org/cgit/musl/commit/?id=2557d0ba47286ed3e868f8ddc9dbed0942fe99dc

neither of them is correct because it is not possible to
exit with the right status in general.

SIGKILL can only be ignored by pid 1 whose exit status is
not supposed to be observable so musl may want to have a
fallback after it since the pid namespace thing is nowadays
widely abused on linux.

> 
> Second the behaviour you're seeing is due to the kernel's special PID 1 
> handling : It ignores signals send to pid 1 for which an explicit handler 
> has nog been installed.
> 
> Remedy : Fix your application. Better : Fix your whole setup, if you need 
> these changes, it's broken by design.
> 
> 
> 
> Igmar