On 14 April 2014 08:42, Sami Kerola <kerolasa@xxxxxx> wrote: > On 13 April 2014 23:22, Bernhard Voelker <mail@xxxxxxxxxxxxxxxxxxx> wrote: >> 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 Hi Berny and others, Here is new set of tests, and they almost work. https://github.com/kerolasa/lelux-utiliteetit/tree/kill-tests-v2 The 'name_to_number' check[1] is giving random errors, and my wooden eyes does not observe where is the problem. Or if the problem is in kill itself, and random errors are a real bug. According to helper witness file the signal receiver is running, but kill does not find it. Some times the check passes without issues, but more often there is one that kind of error, sometime two. [1] https://github.com/kerolasa/lelux-utiliteetit/commit/516fa50baa0daf764a53063e44163e1c3328e110 Ideas, comments, help! -- 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
