"Frank Ch. Eigler" <fche@redhat.com> writes:

> Hi -
>
>> The make_distcheck_test_suite_step uses a logfiles= keyword arg, which
>> in turn uses inotify (presumably) to watch a file for a logfile creatd
>> on it, and to collect info from it.
>
> buildbot buildbot_worker runprocess.py appears to use fstat
> ctime/mtime/size polling to query in-progress files.

Ah, okay.  I couldn't find where exactly it was implemented, so I took
that shot in the dark :)

> bunsen only collects final files.
>
>> [...]
>> DejaGnu provides a way for the directory in which log and sum files are
>> stored to be altered, see --outdir in
>> [...]
>> This, indeed, resulted in a poke.log and poke.sum in the /tmp/outtest
>> directory.
>> I believe we should replace the inotify-based mechanism with this method
>> of redirecting logs.
>
> I'm afraid I don't quite understand how this should improve on
> anything, even if buildbot-worker were to use inotify instead of fstat
> polling.  It's just a different pathname for the files.

Yes, but they could, as a result, land outside of distchecks rm -r
jurisdiction.

I didn't mean to emphasize the role of inotify at all, rather the role
of distchecks cleanup of the build directory, which acts as a limit on
the lifetime of the testsuite results file.

The builder could avoid testsuite files being deleted altogether by
specifying an outdir outside of distchecks temporary directory.

... but maybe I'm overthinking this.  The buildbot worker holds the file
open and just reads new data as it gets appended to the file, which
should be enough to keep the file alive after rm gets to it, so the only
edge case might be that distcheck could somehow conclude in less time
than the polling period, assuming that LoopingCall#start delays first
invocation, or otherwise that the log files might be created and cleaned
up inbetween poll intervals.
-- 
Arsen Arsenović