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... :)
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.
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.
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.
来源：https://stackoverflow.com/questions/13219071/which-fatal-signals-should-a-user-level-program-catch