Python SIGPIPE handling

diff --git a/2009-07-02-python-sigpipe.txt b/2009-07-02-python-sigpipe.txt
new file mode 100644 (file)
index 0000000..af61ab9
--- /dev/null
+++ b/2009-07-02-python-sigpipe.txt
@@ -0,0 +1,37 @@
+Python SIGPIPE handling
+
+<p><a href="http://www.enricozini.org/2009/debian/python-pipes/">Enrico</a>
+writes about creating pipelines with Python's <code>subprocess</code>
+module, and notes that you need to take care to close stdout in non-final
+subprocesses so that subprocesses get <code>SIGPIPE</code> correctly. This
+is correct as far as it goes (and true in any language, although there's a
+<a href="http://bugs.python.org/issue1615376">Python bug report requesting
+that <code>subprocess</code> be able to do this itself</a>), but there's an
+additional gotcha with Python that you missed.</p>
+
+<p>Python ignores <code>SIGPIPE</code> on startup, because it prefers to
+check every write and raise an <code>IOError</code> exception rather than
+taking the signal. This is all well and good for Python itself, but most
+Unix subprocesses don't expect to work this way. Thus, when you are creating
+subprocesses from Python, it is <strong>very important</strong> to set
+<code>SIGPIPE</code> back to the default action. Before I realised this was
+necessary, I wrote code that caused serious data loss due to a child process
+carrying on out of control after its parent process died!</p>
+
+<pre>
+import signal
+import subprocess
+
+def subprocess_setup():
+    # Python installs a SIGPIPE handler by default. This is usually not what
+    # non-Python subprocesses expect.
+    signal.signal(signal.SIGPIPE, signal.SIG_DFL)
+
+subprocess.Popen(command, preexec_fn=subprocess_setup)
+</pre>
+
+<p>I filed a <a href="http://bugs.python.org/issue1652">patch</a> a while
+back to add a <code>restore_sigpipe</code> option to
+<code>subprocess.Popen</code>, which would take care of this. As I say in
+that bug report, in a future release I think this ought to be made the
+default, as it's very easy to get things dangerously wrong right now.</p>