Re: abort() PID 1

[Igmar Palsenberg <igmar@palsenberg.com>]

> The recent thread about abort() and PID 1 left me in a state of
> confusion, in a matter I thought was clear enough:
> 
> What I thought I understood:
> 
> - the kernel will not deliver any signal to process 1, unless a signal
> handler for that particular signal has been installed
> 
> -if process 1 calls abort() (regardless of what purpose that would fill), then:
> 
>     - if a handler was setup, it should be done whatever the handler does
> 
>     - if a handler was not setup, nothing should happen (as in:
> process didn't receive any signal at all)

Pid 1 can ignore sigkill / sigstop. "Normal" processes can't. "Normal" 
processes have defaults handling signals, pid 1 ignores all by default, 
unless it instructs the kernel it wants to receive it. 

> 
> What the standards say:
> 
> (http://pubs.opengroup.org/onlinepubs/9699919799/)
> 
> "The SIGABRT signal shall be sent to the calling process as if by
> means of raise() with the argument SIGABRT."
> 
> "The effect of the raise() function shall be equivalent to calling:
> 
> pthread_kill(pthread_self(), sig);"
> 
> man raise(3):
> The  raise()  function  sends  a  signal  to the caling process or
> thread.  In a single-threaded program it is equivalent to
> kill(getpid(), sig);
> 
> So, what should " kill(1, SIGABRT)" do? It doesn't seem ambiguous to
> me. IOW, there's nothing special about SIGABRT regarding PID 1.

The "problem" in this case is that the "normal" abort() sends a SIGABRT, 
if that doesn't work, unblocks signals and retries.
While that works with "normal" processes, it doesn't work with pid 1, 
because the default action on that process for SIGABRT isn't terminate.

Hence the infinite loop you see. IMHO, we should leave this as it is, 
unless the abort() call fails to successfully terminate the process on 
non-pid 1 processes. That is a bug, failing to terminate pid 1 isn't.




Igmar