Global SIG handler: Is this advisable? Is there a better way?

snafu has asked for the wisdom of the Perl Monks concerning the following question:

I'm writing code that is fork()able and within that code I want to be able to catch and log all signals whether or not they kill the code (of course, not TERM). So, after trying a few options (including $SIG{__DIE__} and END{};) I came up with the following code which does what I want it to do. What I'm curious about is whether or not there is anything wrong with this pragma and if there is a better(tm) way to do it.

I did a search and found some ideas using Carp and eval()'s but felt that since this program is already 99.9% done being written, it's on a deadline, and it's working quite well that this would be an acceptable way of getting what I want.

TIA

     72 ## Place this first.
     73 for my $sig ( keys(%SIG) )
     74 {
     75     $EXIT++;
     76     outmsg('   Processing handler: '.$sig.'('.$EXIT.')',1);
     77
     78     $SIG{$sig} = sub
     79                    {
     80                        outmsg('Caught signal: '.$sig.'...dying
+.',2,$EXIT);
     81                    };
     82 }
     83
     84 ## Then any specific handlers here...next.
     85 $SIG{USR1}     = sub
     86                    {
     87 ## Make sure that the process is in a sleep state so that
     88 ## we don't inadvertently interrupt a run cycle.
     89                        if ( $SLEEPING )
     90                        {
     91                            outmsg('  CAUGHT USR1! -- pre-empti
+ng sleep '.
     92                                   'schedule.',10);
     93                            _main();
     94                        }
     95                    };
     96
[download]

_ _ _ _ _ _ _ _ _ _
- Jim
Insert clever comment here...

Comment on Global SIG handler: Is this advisable? Is there a better way? Download Code

Replies are listed 'Best First'.
Re: Global SIG handler: Is this advisable? Is there a better way? by samtregar (Abbot) on Aug 29, 2006 at 17:37 UTC
Are you sure you really want to catch and exit on every signal? That's a weird thing to do with STOP, for example. Looking at your code I wondered what was in keys(%SIG). The answer was surprising to me - what is all this junk? $ perl -MData::Dumper -e 'print Dumper([sort keys %SIG])' $VAR1 = [ 'ABRT', 'ALRM', 'BUS', 'CHLD', 'CLD', 'CONT', 'FPE', 'HUP', 'ILL', 'INT', 'IO', 'IOT', 'KILL', 'NUM32', 'NUM33', 'NUM35', 'NUM36', 'NUM37', 'NUM38', 'NUM39', 'NUM40', 'NUM41', 'NUM42', 'NUM43', 'NUM44', 'NUM45', 'NUM46', 'NUM47', 'NUM48', 'NUM49', 'NUM50', 'NUM51', 'NUM52', 'NUM53', 'NUM54', 'NUM55', 'NUM56', 'NUM57', 'NUM58', 'NUM59', 'NUM60', 'NUM61', 'NUM62', 'NUM63', 'PIPE', 'POLL', 'PROF', 'PWR', 'QUIT', 'RTMAX', 'RTMIN', 'SEGV', 'STKFLT', 'STOP', 'SYS', 'TERM', 'TRAP', 'TSTP', 'TTIN', 'TTOU', 'UNUSED', 'URG', 'USR1', 'USR2', 'VTALRM', 'WINCH', 'XCPU', 'XFSZ', '__WARN__' ]; [download] Interestingly, __WARN__ is there but __DIE__ isn't. I serriously doubt you want to trap and exit on warn()! -sam	[reply] [d/l]
Re^2: Global SIG handler: Is this advisable? Is there a better way? by snafu (Chaplain) on Aug 29, 2006 at 17:42 UTC
Yes, perhaps I may want to block a few of those signals but really, the idea is that I wanted a global (mostly global) way of trapping sigs. I'm not too worried about which signals I'm trapping as much as I am about the method by which I'm trapping. _ _ _ _ _ _ _ _ _ _ - Jim Insert clever comment here...	[reply]
Re: Global SIG handler: Is this advisable? Is there a better way? by cdarke (Prior) on Aug 29, 2006 at 19:05 UTC
Excuse me for pointing this out if you already know, but it is not possible to trap ALL signals, many cannot be trapped. The most obvious is KILL, but there are others like SEGV, BUS, FPE, ILL, etc. The default action of USR1 and USR2 is not to terminate the process, they are benign, so I have to wonder why you are trapping those. Also beware of trapping CHLD, its behaviour (like some others) varies across platforms (*nix's).	[reply]
Re^2: Global SIG handler: Is this advisable? Is there a better way? by snafu (Chaplain) on Aug 29, 2006 at 20:52 UTC
Indeed. And I was thinking that even though I am attempting to trap all signals that even the ones that can't be trapped will not be trapped with my code. I'm thinking that it doesn't hurt anything to trap those signals, though. Right? The USR1 signal that I'm trapping is actually being trapped for a function purpose of my program that is not clearly obvious from my posted code but you're right, however, that there is no real reason to trap it either unless there is a specific reason. In my case, for this code, there is. :) Now the CHLD signal you mention is a very interesting case that I didn't think about before. So, I will consider this in my existing code. Thank you! _ _ _ _ _ _ _ _ _ _ - Jim Insert clever comment here...	[reply]
Re: Global SIG handler: Is this advisable? Is there a better way? by diotalevi (Canon) on Aug 29, 2006 at 21:09 UTC
You may want to handle the case that there is already a handler for a signal and possible run that also. You may also want to run checks at END or similar that no one else has disturbed your signals. If that happens, debug it and and out if it is innocuous. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]