This may be similar to #210641.  Example (Python 2.4.1,
Fedora Core 4 GNU/Linux):

sh-3.00$ python
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import signal
>>> signal.alarm(1)      # 1 second passes...
0
>>> Alarm clock
sh-3.00$   # python has exited

Doing the same thing in IDLE results in the subprocess
restarting.

IMO the correct behavior would be to raise an exception
that the outer shell would catch.

Logged In: YES 
user_id=21627

This is not a bug. It is documented that way: the default
handler is SIG_DFL, which in turn does the system default
for the signal. For Sigalarm, it is to terminate the process.

If you want an exception raised, you need to install a
signal handler:

>>> def doalarm(signum,frame):
...   raise "alarm"
...
>>> signal.signal(signal.SIGALRM, doalarm)
<function doalalarm at 0xb7d897d4>
>>> signal.alarm(3)
0
>>>
Traceback (most recent call last):
  File "<stdin>", line 0, in ?
  File "<stdin>", line 2, in doalarm
alarm

Logged In: YES 
user_id=72053

How would you feel about an RFE proposing to add a default
SIGALRM handler that raises some new exception like
'AlarmInterrupt', analogous to KeyboardInterrupt that gets
raised if the user hits ^C.  I think that's more in the
Python spirit of maintaining a controlled environment where
at worst, if there's an unhandled exception, the interpreter
prints a stack trace and shuts down cleanly instead of just
blipping out of existence with i/o pending and whatnot. 
There might be some other signals that should also be caught
like that.  In fact KeyboardInterrupt, AlarmInterrupt, etc.
could all be subclasses of an Interrupt class of exceptions.

Paul,
I agree with you, this default behavior is painful. And in fact even the author of the test_socket case for the python regression suite agree with us (maybe even implicitly and by mistake, but regardless...) See Issue17085 for details