public inbox for bunsen@sourceware.org
 help / color / mirror / Atom feed
From: "Arsen Arsenović" <arsen@aarsen.me>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: bunsen@sourceware.org, builder@sourceware.org
Subject: Re: Automake dist-check and log extraction: runtest --outdir
Date: Wed, 18 Jan 2023 00:57:25 +0100	[thread overview]
Message-ID: <86ilh4itbq.fsf@aarsen.me> (raw)
In-Reply-To: <20230117235107.GC10730@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]


"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ć

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

  reply	other threads:[~2023-01-18  0:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-17 23:00 Arsen Arsenović
2023-01-17 23:51 ` Frank Ch. Eigler
2023-01-17 23:57   ` Arsen Arsenović [this message]
2023-01-18 15:01     ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86ilh4itbq.fsf@aarsen.me \
    --to=arsen@aarsen.me \
    --cc=builder@sourceware.org \
    --cc=bunsen@sourceware.org \
    --cc=fche@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).