Beyond Ctrl-C: The dark corners of Unix signal handling

My favorite signal surprise was running nginx and&#x2F;or httpd in the foreground and wondering why on earth it quit whenver i resized the window.<p>Turns out, they use SIGWINCH (which is sent on WINdow CHange) for graceful shutdown.<p>It&#x27;s a silly, silly problem.

&gt; Another common extension is to use what is sometimes called a double Ctrl-C pattern. The first time the user hits Ctrl-C, you attempt to shut down the database cleanly, but the second time you encounter it, you give up and exit immediately.<p>This is a terrible behavior, because users tend to hit Ctrl-C multiple times without intending anything different than on a single hit (not to mention bouncing key mechanics and short key repeat delays). Unclean exits should be reserved for SIGQUIT (Ctrl-\) and SIGKILL (by definition).

The article doesn&#x27;t mention the most useful of all signals: SIGINFO, aka &quot;please print to stderr your current status&quot;. Very useful for tools like dd and tar.<p>Probably because Linux doesn&#x27;t implement it. Worst mistake Linus ever made.<p>Also, it talks about self-pipe but doesn&#x27;t mention that self-<i>socket</i> is much better since you can&#x27;t select on a pipe.

I recently wrote a little data transfer service in python that runs in ECS. When developing it locally it was easy to handle SIGINT: try write a batch, except KeyboardInterrupt, if caught mark the transfer as incomplete and finally commit the change and shut down.<p>But there’s no exception in python to catch for a SIGTERM, which is what ECS and other service mangers send when it’s time to shut down. So I had to add a signal handler. Would have been neat if SIGTERM could be caught like SIGINT with a “native” exception.