This is a very interesting situation. I have coded up the system call into fork/exec solution and ensured that the signal handler and alarm call are only happening within the parent. Even with this the child is still exiting with -1.
#!/usr/bin/perl
use strict; use warnings;
use Data::Dumper;
print "".localtime(),"\n";
my $pid = fork;
die "fork failed\n" if !defined $pid;
if ($pid == 0) { # child
print "child is $$\n";
exec "/bin/sleep", "4";
die "exec failed:$!\n";
}
else { # parent
# there is no code in the parent to kill the child if the alarm is
+ called
$SIG{ALRM} = sub {
print( "Alarm triggered, making system call in $$\n" );
unlink('/doesnt/exist'); # this will definitely fail
};
alarm(2);
my $pid = wait;
my $status = $?;
print "return value from child is $pid and status was $status\n";
}
print "".localtime(),"\n";
The output of this code is-
Sat Sep 29 09:04:00 2007
child is 26171
Alarm triggered, making system call in 26170
return value from child is -1 and status was -1
Sat Sep 29 09:04:02 2007
It seems that the failed unlink is causing the return code from the child to be trashed too. This is just speculation, of course. In the perldocs there is talk of problems with signals and different versions of OS being a contributing factor, so I coded up the original code in C;
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <unistd.h>
void alarm_sig(int sig)
{
int rt;
puts("in alarm_sig");
if ((rt = unlink("/doesnt/exist")) == -1) {
perror("unlink failed");
}
}
int main()
{
int rt;
signal(SIGALRM, alarm_sig);
alarm(2);
rt = system("sleep 4");
printf("return value from system %d\n", rt);
}
The output of this is -
in alarm_sig
unlink failed: No such file or directory
return value from system 0
So it doesn't look like it's a problem with my operating system. Need to have a look at this further, later on.