views:

196

answers:

1

In a Perl script I'm writing I'm having a problem where I block the INT and QUIT signals, execute a process within backticks, and then unblock the INT and QUIT signals. I want to prevent an INT or a QUIT from reaching the child process and killing it.

The script successfully blocks and unblocks at the right points in the code, however, it doesn't DELAY the signal and execute the handlers I have configured while it's in blocking mode as many references say it should. I know it's unblocking because I can send a SIGINT before or after the block or unblock command and it is respected.

OS: Linux 2.6.30 Perl version: 5.8.8

Code snippets:

#!/usr/local/bin/perl

use POSIX qw(:signal_h);

$SIG{'INT'} = 'gracefulExit';
sub gracefulExit { print "Caught Signal = GOOD\n"; exit; }

print "Recieving a SIGINT works here\n";
sleep 5;
my $sigset = POSIX::SigSet->new;
my $blockset = POSIX::SigSet->new(SIGINT);
sigprocmask(SIG_BLOCK, $blockset, $sigset) or die "dying at block...\n";
print "Recieving a SIGINT doesn't work here [GOOD!] and is NOT delayed [WHY!?].\n";
`/bin/sleep 5`;
sigprocmask(SIG_UNBLOCK, $blockset) or die "dying at unblock...\n";
print "Recieving a SIGINT works here again [GOOD!]\n";
sleep 5;
print "Exited without receiving a signal\n";
+1  A: 

I'm all but certain Randal nailed this in a comment above, but the proper test is to check with strace to verify that the signal syscalls you expect to be happening actually are. And more generally, when working at the system call level, you want to avoid mixing with library functions that are intended to abstract them.

Andy Ross
Thank you Andy and Randal! It's all done and good now.
The Mad Canudist