On 04/12/2014 12:28 PM, Sami Kerola wrote:
> + $TS_HELPER_SIGRECEIVE &
> + TEST_PID=$(jobs -p)
> + # test_sigreceive needs time to start up
> + sleep 0.01
> + $TS_CMD_KILL -$SIG ${TS_HELPER_SIGRECEIVE##*/} >> $TS_OUTPUT 2>&1
> + wait $TEST_PID
> + if [ $? -ne $EXPECTED ]; then
> + echo "$SIG returned $? while $EXPECTED was expected" >> $TS_OUTPUT
> + all_ok=false
> + fi
This is racy. Although this might work in most cases, one can not
determine that the SIGRECEIVE process had enough time to startup
and register all signal handlers before the signal arrives.
Usually this would fail more likely with high system load,
e.g. on build servers with massive parallel builds.
The only chance is that the SIGRECEIVE program indicates that it
has fully come up, e.g. by creating a file which did not exist
beforehand. The second part of avoiding unwanted behavior is to
wait for such a witness file to appear in the parent test script
... but avoiding to wait infinitely (because other unknown reasons
may have prevented the creation of the witness file).
In the test-suite of coreutils, there are a few complex (and yet
necessary) snippets to do this:
a) test case waiting for the inspected program to be ready:
http://git.savannah.gnu.org/cgit/coreutils.git/tree/tests/tail-2/retry.sh#n45
b) utility function to retry with increasing delay until a
maximum number has reached:
http://git.savannah.gnu.org/cgit/coreutils.git/tree/init.cfg#n597
Maybe a solution like the above is too heavy for this situation (unless
it could be reused in other tests), so something like the following may
suffice here - assuming that $TS_HELPER_SIGRECEIVE will successfully
perform a 'creat("witnessfile", mode)':
rm -f witnessfile || fail=1
test -f witnessfile && fail=1
$TS_HELPER_SIGRECEIVE & TEST_PID=$!
up=0
while i in 0.01 0.1 1 2 ; do
test -f witnessfile && { up=1; break; }
sleep $i
done
test $up = 1 || fail=1
$TS_CMD_KILL -$SIG ${TS_HELPER_SIGRECEIVE##*/} >> $TS_OUTPUT 2>&1
...
WDYT?
Thank you & have a nice day,
Berny
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
