coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tests: make inotify-rotate more robust and efficient


From: Pádraig Brady
Subject: Re: [PATCH] tests: make inotify-rotate more robust and efficient
Date: Wed, 29 Oct 2014 21:20:35 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 10/29/2014 08:36 PM, Bernhard Voelker wrote:
> On 10/29/2014 03:15 PM, Pádraig Brady wrote:
>> * tests/tail-2/inotify-rotate.sh:
> 
> Wow, what coincidence: exactly today that test started failing
> for the first time in openSUSE's Build Service:
> 
> https://build.opensuse.org/package/show/Base:System/coreutils-testsuite
> https://build.opensuse.org/build/Base:System/openSUSE_Factory/x86_64/coreutils-testsuite/_log
> 
> Somehow I have the impression that this is some fallout of the
> recent update of glibc to 2.20.
> 
> Have a nice day,
> Berny
> 
> 
> [  736s] FAIL: tests/tail-2/inotify-rotate
> [  736s] =================================

> [  736s] + for i in '$(seq 50)'
> [  736s] + echo 1
> [  736s] 1
> [  736s] + rm -rf k x out
> [  736s] + pid=24570
> [  736s] + sleep .1
> [  736s] + timeout 40 tail -F k
> [  736s] + echo b
> [  736s] + grep_timeout b out
> [  736s] + local j
> [  736s] ++ seq 150
> [  736s] + for j in '$(seq 150)'
> [  736s] + grep b out
> [  736s] + return 0
> [  736s] + :
> [  736s] + grep b out
> [  736s] + break
> [  736s] + mv x k
> [  736s] + grep_timeout tail: out
> [  736s] + local j
> [  736s] ++ seq 150
> [  736s] + for j in '$(seq 150)'
> [  736s] + grep tail: out
> [  736s] + return 0

> [  736s] + echo ok
> [  736s] + found=0

> [  736s] + grep_timeout ok out
> [  736s] + for j in '$(seq 150)'
> [  736s] + grep ok out
> [  736s] + sleep 0.1
> [  736s] + return 1
> [  736s] + kill 24570
> [  736s] ./tests/tail-2/inotify-rotate.sh: line 65: kill: (24570) - No such 
> process

I was wonderomg did the timeout 40 kill the tail process before it could 
propagate the "ok"
I.E. that something recent was slowing down this test causing the false 
positives?
Though the the above happened on the first time through the loop so that's not 
likely.

In the hydra case, tail did output but not fast enough so it seemed to be a 
genuine race.
Also it seems glibc 2.19 is used in the hydra case:
http://hydra.nixos.org/build/16546517#tabs-runtime-deps

BTW I must look into why the verbose logs aren't output by hydra
even though VERBOSE=yes is set in the hydra scripts.

thanks,
Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]