I often need to make sure that a specific assert is only checked when the system under test is ready to be tested. Typically test has to be run after setup is finished. E.g. a service needs some time for initiation, doing rlServiceStart service rlRun "check service" fails because the service needs some "warm up" time. Quick and dirty "solution" is to run sleep before the test but that's unreliable - you either don't wait long enough and run the check too soon or wait for too long and waste time. I propose a synchronization function that would block until the test and SUT are in sync. I believe test-SUT synchronization is an use-case common enough to warrant a beakerlib function. This is what I currently use for samba testing: sb_tries(){ local COMMAND=$1 local COUNT=${2:-10} local PAUSE=${3:-10} local RESULT=${4:-0} local DESCRIPTION=${5:-$COMMAND} local ECODE=0 while [ "$COUNT" -gt 0 ] ; do echo "tries: COUNT=$COUNT PAUSE=$PAUSE RESULT=$RESULT COMMAND=$DESCRIPTION" eval $COMMAND ECODE=$? [ $ECODE -eq "$RESULT" ] && return 0 echo "ecode: $ECODE" sleep "$PAUSE" COUNT=$(( $COUNT -1 )) done return $ECODE } Example usage: rlServiceStart smb #run the command repeatedly with 10 second pause in between runs unless it returns 0 or 10 iterations sb_tries "smbclient -N -L 127.0.0.1" rlRun "the real test"
*** Bug 879260 has been marked as a duplicate of this bug. ***
I'm working on a generic set of routines for process synchronisation, and I'm wondering if just waiting for network or UNIX sockets wouldn't be enough? Other than that, I think a timeout-based approach would be better. Because if the test command blocks, we can still continue with the test execution. This way the cleanup phase has a chance to run.
(In reply to Hubert Kario from comment #2) > I'm working on a generic set of routines for process synchronisation, and > I'm wondering if just waiting for network or UNIX sockets wouldn't be enough? AFAIK doesn't work for my use-case from comment#0 > > Other than that, I think a timeout-based approach would be better. Because > if the test command blocks, we can still continue with the test execution. > This way the cleanup phase has a chance to run. additional timeout parameter can be added, or, better, you should be able to wrap the rlWaitUntilReady in rlWatchdog.
I've created a new routine, rlWaitForCmd, details on mailing list: https://lists.fedorahosted.org/pipermail/beakerlib-devel/2013-November/000043.html Usage: rlWaitForCmd command [-p PID] [-t time] [-m count] [-d delay] [-r retval] =item command Command that will be executed until its return code is equal 0 or value speciefied as option to `-r'. =item -t time Timeout in seconds, default=120. If the command doesn't return 0 before time elapses, the command will be killed. =item -p PID PID of the process to check before running command. If the process exits before the socket is opened, the command will log a WARNING. =item -m count Maximum number of `command' executions before continuing anyway. Default is infite. =item -d delay Delay between `command' invocations. Default 1. =item -r retval Expected return value of command. Default 0.
*** This bug has been marked as a duplicate of bug 1032123 ***