title: How does SIGINT relate to the other termination signals such as SIGTERM, SIGQUIT and SIGKILL?
body: <p>On POSIX systems, termination signals usually have the following order (according to many MAN pages and the POSIX Spec):</p>
  <ol>
  <li><p><strong>SIGTERM</strong> - politely ask a process to terminate. It shall terminate gracefully, cleaning up all resources (files, sockets, child processes, etc.), deleting temporary files and so on.</p>
  </li>
  <li><p><strong>SIGQUIT</strong> - more forceful request. It shall terminate ungraceful, still cleaning up resources that absolutely need cleanup, but maybe not delete temporary files, maybe write debug information somewhere; on some system also a core dump will be written (regardless if the signal is caught by the app or not).</p>
  </li>
  <li><p><strong>SIGKILL</strong> - most forceful request. The process is not even asked to do anything, but the system will clean up the process, whether it like that or not. Most likely a core dump is written.</p>
  </li>
  </ol>
  <p>How does <code>SIGINT</code> fit into that picture? A CLI process is usually terminated by <code>SIGINT</code> when the user hits <code>CRTL+C</code>, however a background process can also be terminated by <code>SIGINT</code> using <code>KILL</code> utility. What I cannot see in the specs or the header files is if <code>SIGINT</code> is more or less forceful than <code>SIGTERM</code> or if there is any difference between <code>SIGINT</code> and <code>SIGTERM</code> at all.</p>
  <p><strong>UPDATE:</strong></p>
  <p>The best description of termination signals I found so far is in the <a href="http://www.gnu.org/s/libc/manual/html_node/Termination-Signals.html" rel="noreferrer">GNU LibC Documentation</a>. It explains very well that there is an intended difference between SIGTERM and SIGQUIT.</p>
  <p>It says about <code>SIGTERM</code>:</p>
  <blockquote>
  <p>It is the normal way to politely ask a program to terminate.</p>
  </blockquote>
  <p>And it says about <code>SIGQUIT</code>:</p>
  <blockquote>
  <p>[...] and produces a core dump when it terminates the process, just like a program error signal.
  You can think of this as a program error condition “detected” by the user. [...]
  Certain kinds of cleanups are best omitted in handling SIGQUIT. For example, if the program
  creates temporary files, it should handle the other termination requests by deleting the temporary
  files. But it is better for SIGQUIT not to delete them, so that the user can examine them in
  conjunction with the core dump.</p>
  </blockquote>
  <p>And <code>SIGHUP</code> is also explained well enough. SIGHUP is not really a termination signal, it just means the &quot;connection&quot; to the user has been lost, so the app cannot expect the user to read any further output (e.g. stdout/stderr output) and there is no input to expect from the user any longer. For most apps that mean they better quit. In theory an app could also decide that it goes into daemon mode when a SIGHUP is received and now runs as a background process, writing output to a configured log file. For most daemons already running in the background, SIGHUP usually means that they shall reexamine their configuration files, so you send it to background processes after editing config files.</p>
  <p>However there is no useful explanation of SIGINT on this page, other than that it is sent by CRTL+C. Is there any reason why one would handle SIGINT in a different way than SIGTERM? If so what reason would this be and how would the handling be different?</p>