Last night in id//811295, I asked about the best way to catch 'die' signals in embedded modules to convert them to 'warn' and prevent my script from exiting. The answer revolved around the best way to use 'eval' to "try" rather than execute the die signal.

I now have pretty much the converse question. I have a script that I daemonize and which creates a lock file. I would like the script to remove the lock file on signals INT, TERM, and __DIE__ just before actually dieing (in particular, this time I am *not* trying to prevent the process from exiting, I just want to prepend an action before exit). Of course, I only want to remove the lock if the __DIE__ signal is actually going to kill the process.

To do this, I added a handler of form: 
$SIG{INT} = $SIG{TERM} = $SIG{__DIE__} = \&signal_handler;
sub signal_handler {
    unlink($lockfile) if -w $lockfile;
}

Now this works just fine for INT and TERM but adding __DIE__ causes pr
+oblem since some of the indirectly called modules use "eval" to test 
+for conditions that don't result in a real exit.<br><br>

Specifically, one of my routines indirectly calls XML::Simple which us
+es the following "eval" block to test if XML::SAX is available:
<code>
eval { require XML::SAX; };      # We didn't need it until now
  if($@) {                         # No XML::SAX - fall back to XML::P
+arser
    if($preferred_parser) {        # unless a SAX parser was expressly
+ requested
      croak "XMLin() could not load XML::SAX";
    }
    return($self->build_tree_xml_parser($filename, $string));
  }

[download]
The problem is that my new handler catches the error caused by non-existent XML/Sax.pm (i.e., "Can't locate XML/SAX.pm in @INC...) and removes the lock file even though the eval block protects it from actually exiting.

So, I am looking for a method of *only* trapping the 'die' signals that actually are about to lead to the process dieing while avoiding trapping (or at least acting upon) "clever" eval tricks that are used only to "try" or test what happens. Specifically, is there a way to write the signal handler so it only does something (i.e. only removes the lock file) if the process is truly about to die?

In reply to How to catch 'die' signal - CONVERSE case of #811295 by puterboy

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.