Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

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

by snafu (Chaplain)
on Aug 29, 2006 at 17:04 UTC ( #570210=perlquestion: print w/replies, xml ) Need Help??

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.


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 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

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

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__' ];

    Interestingly, __WARN__ is there but __DIE__ isn't. I serriously doubt you want to trap and exit on warn()!


      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...

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).
      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...

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.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://570210]
Approved by Paladin
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (2)
As of 2022-05-24 19:02 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (84 votes). Check out past polls.