Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

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.

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

_ _ _ _ _ _ _ _ _ _
- 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()!

    -sam

      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?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (6)
As of 2019-05-21 08:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you enjoy 3D movies?



    Results (131 votes). Check out past polls.

    Notices?
    • (Sep 10, 2018 at 22:53 UTC) Welcome new users!