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 to catch signals.

So just to clarify: I've done whatever needs to be done to handle signals. I have an application that forks a daemon that monitors the main process through pipe. If a main process crashes (e.g. segmentation fault), it has a signal handler that writes all the required info to pipe and aborts.

The goal is to have as much info as possible when something bad happens to the application, w/o messing with "normal" operation, such as SIGHUP, SIGUSR1, etc.

So my question is: which signals should I catch? I mean signals that w/o me catching them would cause application to abort anyway.

So far I've come up with the following list:

• SIGINT (^C, user-initiated, but still good to know)
• SIGTERM (kill <pid> from shell or, AFAIK, can be result of OutOfMemory)
• SIGSEGV
• SIGILL
• SIGFPE
• SIGBUS
• SIGQUIT

Does anybody know if I miss something? kill -l has lots of them... :)

Answer 1

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.