What this bug says is that if a command if being executed through a subprocess,
the signal handler isn't called until the subprocess returns.
What happened in this specific instance of the problem is that the utah client
was being executed through ssh and the signal was already triggered, but the
handler wasn't called.
I've attached a sample script to reproduce the problem. When `signal.alarm` is
used, the handler isn't called until the ssh command is done. However if the
timeout is set using `channel.settimeout` a `socket.timeout` exeception is
raised at the expected time.
After some testing, the behavior I've seen confirms the following python bug: bugs.python. org/issue9504
http://
What this bug says is that if a command if being executed through a subprocess,
the signal handler isn't called until the subprocess returns.
What happened in this specific instance of the problem is that the utah client
was being executed through ssh and the signal was already triggered, but the
handler wasn't called.
I've attached a sample script to reproduce the problem. When `signal.alarm` is settimeout` a `socket.timeout` exeception is
used, the handler isn't called until the ssh command is done. However if the
timeout is set using `channel.
raised at the expected time.