nested alarm signals

John R. Comeau comeaujr at
Thu Jun 15 15:08:07 CDT 2000

I've been using an alarm signal in my large Perl project to spawn
processes that I want to happen in the background.  In the process of
debugging this code, I found some unexpected behavior.  It seems that,
when a new process is launched within the alarm signal handler, the
new process can't respond to an alarm signal itself.  I wrote a simple
test case consisting of two files.  If you're on, they
are located in my home directory:


Here are the two files, followed by

-------------------- cut here --------------------

$SIG{ALRM} = sub {die 'ALARM'};

alarm 10;

-------------------- cut here --------------------

$SIG{ALRM} = sub {warn "calling\n"; ``};

# $SIG{ALRM}->();

alarm 10;

-------------------- cut here --------------------

When I run by itself, I get the following results:

    ALARM at line 3. waits for STDIN but dies when the alarm occurs.  But when
I run, I get results I didn't expect:


Neither nor because is
waiting for STDIN.  It somewhow does not respond to the alarm it sets
(or doesn't successfully set the alarm).  I've never heard of this
behavior.  Is there some kind of Unix rule that you can't have nested
alarm signals?  Even if there was such a rule for a single process, it
seems odd to me that the child process for would be
affected by the fact that it was run from within an alarm signal

When is spawned from outside a signal handler, by
uncommenting line 5 of, runs as
expected; it dies from the alarm.

Sorry that this is more of a Unix question than Perl, but it is kind
of Perl, isn't it?

I spent several hours last night going crazy before I isolated this
problem to these nested alarm signals.

John Comeau (john.comeau at 858-713-3593 (W)
Jeder Fallschirmspringer muss der Gefahr ins Auge

Every parchutist has to face the danger.

The posting address is: san-diego-pm-list at

List requests should be sent to: majordomo at

If you ever want to remove yourself from this mailing list,
you can send mail to <majordomo at> with the following
command in the body of your email message:

    unsubscribe san-diego-pm-list

If you ever need to get in contact with the owner of the list,
(if you have trouble unsubscribing, or have questions about the
list itself) send email to <owner-san-diego-pm-list at> .
This is the general rule for most mailing lists when you need
to contact a human.

More information about the San-Diego-pm mailing list