title: Which "fatal" signals should a user-level program catch?
body: <p>First of all, <a href="https://stackoverflow.com/questions/5297062/recommended-signals-to-catch">I do know that there was a similar question here in the past</a>.</p>
  
  <p>But that question wasn't answered properly. Instead, it diverted into suggestion what to do to catch signals.</p>
  
  <p>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.</p>
  
  <p>The goal is to have as much info as possible <em>when something bad happens to the application</em>, w/o messing with "normal" operation, such as SIGHUP, SIGUSR1, etc.</p>
  
  <p>So my question is: <strong>which signals should I catch?</strong>
  I mean signals that w/o me catching them would cause application to abort anyway.</p>
  
  <p>So far I've come up with the following list:</p>
  
  <ul>
  <li>SIGINT (^C, user-initiated, but still good to know)</li>
  <li>SIGTERM (<code>kill &lt;pid&gt;</code> from shell or, AFAIK, can be result of OutOfMemory)</li>
  <li>SIGSEGV</li>
  <li>SIGILL</li>
  <li>SIGFPE</li>
  <li>SIGBUS</li>
  <li>SIGQUIT </li>
  </ul>
  
  <p>Does anybody know if I miss something? <code>kill -l</code> has lots of them... :)</p>