On 13 April 2014 23:22, Bernhard Voelker <mail@xxxxxxxxxxxxxxxxxxx> wrote:
> 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?
Hi Berny,
I wish I had though witnessfile before sending the patches, thanks for
the idea. I have feeling it might solve various parallel test issues I
had while doing test runs earlier. Version that used combined with
mktemp symlinks to sigreive helper to alter name of the killed program
was an attempt to make parallel runs to work, but it was flaky
probably due reasons you gave. The symlink approach with witnessfile
might allow to get rid of flock that makes the kill tests to run
sequentially. Let me try that.
Karel please for completion of the second try. I will keep these
patches untouched in
git://github.com/kerolasa/lelux-utiliteetit.git kill-tests
The witnessfile version goes this branch, once I have something to push.
git://github.com/kerolasa/lelux-utiliteetit.git kill-tests-v2
--
Sami Kerola
http://www.iki.fi/kerolasa/
--
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
