tests: avoid signal issues in timeout-group
authorPádraig Brady <P@draigBrady.com>
Thu, 3 Nov 2011 01:42:43 +0000 (01:42 +0000)
committerPádraig Brady <P@draigBrady.com>
Thu, 3 Nov 2011 18:36:28 +0000 (18:36 +0000)
These issues were seen on an OpenSuse 10.3 system
(kernel 2.6.22.5 x86_64, glibc 2.6.1-18, bash updated to 4.2),
and also on a 64 bit SLES system with a 2.6.16 kernel.
Both systems had 2 CPUs.

There were two issues seen.  1. Occasionally the
timeout.cmd shell script would block SIGINT until
the sleep command exited.  2. Much less frequently the
signal handler in the timeout command itself was ignored,
causing SIGALRM to kill the process.

* tests/misc/timeout-group: Detect the above two cases,
and skip rather than fail.  Note only issue 2. causes
a failure unless skipped, but we skip for case 1. also,
for diagnostic purposes.

tests/misc/timeout-group

index 5d31551..4c4bbaa 100755 (executable)
@@ -73,14 +73,25 @@ rm -f int.received timeout.running
 # commands that create their own group
 # This didn't work before 8.13.
 
+start=$(date +%s)
+
 # Note the first timeout must send a signal that
 # the second is handling for it to be propagated to the command.
 # SIGINT, SIGTERM, SIGALRM etc. are implicit.
 timeout -sALRM 30 timeout -sINT 25 ./timeout.cmd 20&
+pid=$!
 # Wait 6.3s for timeout.cmd to start
 retry_delay_ check_timeout_cmd_running .1 6 || fail=1
-kill -ALRM $! # trigger the alarm of the first timeout command
-wait
+kill -ALRM $pid # trigger the alarm of the first timeout command
+wait $pid
+ret=$?
+test $ret -eq 124 ||
+  skip_ "timeout returned $ret. SIGALRM not handled?"
 test -e int.received || fail=1
 
+end=$(date +%s)
+
+test $(expr $end - $start) -lt 20 ||
+  skip_ "timeout.cmd didn't receive a signal until after sleep?"
+
 Exit $fail