2008/4/22, Dan Fandrich wrote:

> [...] Since the remote case currently requires some customizing
> of runtests.pl anyway, it's probably not worth putting too much effort into
> this case, but concentrate on making the single machine case reliable.

Even something as simple as I've suggested has its own problems in the
'single machine case' due to test harness and tests peculiarities.

I've implemented the simple mechanism, and some facts have aroused.

Tests that use the ssh server cannot benefit from any cooperative
synchronization mechanism, we don't have control over the sshd source
code, so at most we are only capable of introducing the small delay in
the postcheck section for tests that would certainly need it.

As a positive note. Current tests that use the sws and tftpd server do
benefit from it.

Current FTP tests also benefit from it, but there is a problem with
test # 190. It works letting curl client time out and killing
(SIGKILL) the test ftp server. As it is right now this implies that
the 'lock file' would not be removed by the server, and runtests.pl
waits the full defined timeout for the 'lock file' to disappear. Even
in this case everything works as expected.

The same kind of problem would exist for any test that instructs the
server to wait for a time greater than the time allowed by runtests.pl
for the 'lock file' to disappear.

.How much time should be allowed for the 'lock file' to be removed by
the server, before runtests.pl continues execution even when the 'lock
file' has not disappeared ?

I feel like setting a 300 seconds value, throwing it at the autobuilds
find out the maximum time used, not taking in account test #190,
increment it probably in some amount and finally use that as a
reasonable value.

-- 
-=[Yang]=-