<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>jonEbird's Landing Place - Latest Comments in Deciphering Caught Signals</title><link>http://jonebird.disqus.com/</link><description></description><atom:link href="http://jonebird.disqus.com/deciphering_caught_signals/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Thu, 26 Jan 2012 11:32:14 -0000</lastBuildDate><item><title>Re: Deciphering Caught Signals</title><link>http://jonebird.com/2010/02/09/deciphering-caught-signals/#comment-421484381</link><description>&lt;p&gt;There's a lot of good information here, good post!&lt;/p&gt;

&lt;p&gt;It reminds me that end users are going to Ctrl-C the wrappers we create (and as you point out Systems Engineers are going to create scripts that send kill signals as well). I recall once sending out emails pleading, 'please do a kill -15 before kill -9' because my wrappers where doing database locks, transactions, etc., at the time. Eventually I learned to trap and add handlers for SIGKILL and SIGTERM as a necessity, and, as I recall, made a deal with the SysAdmins to provide SIGINT handlers to do other things as well.&lt;/p&gt;

&lt;p&gt;I think it is worth noting, and it's my understanding (though I have not tested this lately) that when a wrapper traps SIGINT, etc., and it's handler gracefully shuts down child processes, etc. (which is binary progress, or others in the process group?) then the shell might not begin sending SIGINT to others in process group until after the wrapper has responded (and hopfully did not leave any others in process group). In other words, a wrapper that traps SIGINT might stop interactive shell from sending SIGINT to others in process group, or that the shell might only look for others in the process group after wrapper has responded to SIGINT.&lt;/p&gt;

&lt;p&gt;You definately got me thinking :-)&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Sturdyworks</dc:creator><pubDate>Thu, 26 Jan 2012 11:32:14 -0000</pubDate></item></channel></rss>
