问题
Currently, I catch SIGSEGV, send myself an email, and then abort() so I can get a core file and debug my program. (If I did not catch, there would be no way that I would not know that my particular program segfaulted. My program is run in a separate server from my own.)
Are there any other signals that I should catch for debugging or for reasons that I should know about ?
回答1:
What makes you think that a SEGV hasn't already corrupted your program memory so much that an attempt to send email won't fail spectacularly?
You should follow division of responsibility practices and monitor your program from a totally different program.
Simply have a (very simple so it's far less likely to fail) program which checks to make sure your primary program is still running and, if not, send you that email. You can even do defence-in-depth and run two checkers, both of which check the primary program and each other.
If you're paranoid like me, you can even run them on separate machines :-)
回答2:
Well, if your program attaches to a console, you might want to catch SIGINT to dump/flush any buffers/logs your are withholding.
回答3:
You should probably not catch SIGSEGV / SIGBUS etc.
What you should do instead, is write a wrapper program which will detect if the subprocess exits from a signal, and identify the problem, then that process can carry out any required action.
If it is a server process, you probably also want to restart if it fails unexpectedly.
来源：https://stackoverflow.com/questions/5297062/recommended-signals-to-catch