[PATCH 2/2] tests/threads-execve: force clock_nanosleep syscall

[Dmitry V. Levin]

On Wed, May 05, 2021 at 01:48:18AM +0000, Alyssa Ross wrote:
> On Wed, May 05, 2021 at 03:21:46AM +0300, Dmitry V. Levin wrote:
> > On Tue, May 04, 2021 at 05:57:43PM +0000, Alyssa Ross wrote:
> > > Using clock_nanosleep here means that these sleeps won't show up in
> > > the test result, which only monitors for nanosleep.  But on Musl,
> > > clock_nanosleep(CLOCK_REALTIME, 0, ...) will use the nanosleep
> > > syscall, so on Musl these extra sleeps would appear in the test output
> > > and break the tests.
> > > ---
> > > As an aside, by default if they fail, threads-execve* tests will be
> > > rerun repeatedly for 1.2 hours, in the hope that they will pass.  It
> >
> > There is an environment variable TIMEOUT_DURATION that controls how long
> > each test is allowed to run.  It's default value is 1500 (seconds), and
> > it's implemented using timeout(1).  Please make sure your environment
> > provides timeout(1), otherwise TIMEOUT_DURATION has no effect.
> 
> Yeah, that's what I was talking about, although I got my maths wrong.
> 
> 1500 seconds is 24 minutes.  These tests retry for half of
> TIMEOUT_DURATION, so they keep retrying for 12 minutes each.  That seems
> like an absurdly long time to keep retrying for, especially since
> running the test once takes less than a second (for me at least), so by
> the time that timeout elapses, they'll have retried hundreds of times.

Looking at the history of tests/threads-execve.test file, it was first
introduced with a single invocation, later a loop for up to 20 iterations
was added, and, finally, it was replaced with the $TIMEOUT_DURATION/2
timeout.  The commit message of that change says:
Give threads-execve.test more chances to succeed

I don't remember any details, but, apparently, 20 iterations were not
enough.

Anyway, your patch is now applied, thanks.


-- 
ldv