Which “fatal” signals should a user-level program catch?

Question

First of all, I do know that there was a similar question here in the past.

But that question wasn\'t answered properly. Instead, it diverted into suggestion what to do

Answer 1

You should not catch the signal and write the code to a pipe. This is both unnecessary and not failsafe.

Let me quote an answer from the question you linked to, to point out why it's not failsafe: "What makes you think that a SEGV hasn't already corrupted your program memory"

Now you may be wondering how to do it better, and why I've said it is "unnecessary".

The return code of the waitpid syscall can be checked using WIFSIGNALED() to determine whether the process was terminated normally or via a signal, and WTERMSIG() will return the signal number.

This is failsafe and it does not require a handler or a pipe. Plus, you don't need to worry what to catch, because it will report every signal that terminates your process.

Answer 2

I'm looking at my copy of advanced programming the unix environment (Stevens). According to the table in the section on signals, the following POSIX signals will by default terminate the process, if you don't catch them. It wouldn't be unreasonable to monitor all of these that you don't use:

• SIGABRT
• SIGALRM
• SIGFPE
• SIGHUP
• SIGILL
• SIGINT
• SIGKILL
• SIGPIPE
• SIGQUIT
• SIGSEGV
• SIGTERM
• SIGUSR1
• SIGUSR2

You can catch all of these except SIGKILL, but hopefully SIGKILL won't come up very often for you.

Note that your signal man page (man 7 signal) should give you the proper list for your system - this is the POSIX list, and may differ depending on your architecture.

Answer 3

It depends: whatever signal you like if that's useful to inform the user something bad just happened. However SIGKILL and SIGSTOP cannot be caught.