7.10 test issues in jhalfs

Bruce Dubbs bruce.dubbs at gmail.com
Tue Sep 6 13:28:42 PDT 2016


Pierre Labastie wrote:
> On 06/09/2016 19:14, Bruce Dubbs wrote:
>> Last night I did a jhalfs run of LFS to get timing data fo 7.10 (and to check
>> gcc failures (they were OK)).
>>
>> What I got was a hang in coreutils.  The specific test was
>> tests/misc/seq-precision.sh where it does:
>>
>> seq 999999 inf | head -n2 > out || fail=1
>> seq 1 .1 inf | head -n2 > out || fail=1
>> seq inf inf | head -n2 | uniq > out || fail=1
>>
>> If you run these from the command line, there is no problem.  Something
>> happens when running jhalfs that seems to be intercepting the sigpipe signal
>> when head exits and seg runs forever making the script hang.
>>
>> Running the build/test from the command line seems OK.
>>
>> When running jhalfs, I'd suggest editing lfs-commands/chapter06/116-coreutils
>> and adding
>>
>> rm tests/misc/seq-precision.sh
>>
>> I've not tested this.  What I did was a 'ps -ef |grep nobody' and saw the seq
>> command running.  I killed that and then did it twice more for the other two
>> calls and then the test completed.
>>
>> ---
>>
>> In a second minor issue, when running jhalfs the tar extraction of packages
>> writes a sequence like:
>>
>>   Building target 133-man-db
>> tar: write error
>>
>> The actual extraction seems to be OK.  It does not happen on every file but
>> does for most.
>>
>> Upon reflection it may be due to my disk setup.  My drive is an SSD and I have
>> noatime as a part of the mount options.  That may be the reason for the
>> message.  However I don't get that message from the command line when working
>> from the SSD drive.

> I've just rebuilt 7.10-rc1 on real hardware, and have none of those issues.
> For the coreutils test:
> PASS: tests/misc/seq-precision.sh
> The SBU is rather long (13.8), but binutils was run at -j5, while coreutils is
> run at -j1, so I do not think the test hanged for me.
>
> What I know is that some test results are different in coreutils depending
> whether the terminal is an X terminal or a linux console (the test
> ssty-pairs.sh for example, does not pass on linux console). I have built in an
> X terminal (LXTerminal).

Yes.  For some reason the 'seq inf' problem seems intermittent.  To me, 
that points to a race condition, possibly in the kernel.  My system is 
pretty fast, but I don't know why that would cause a signal to be lost.

> Thinking about it, we do intercept some signals in jhalfs, that might be the
> reason. I am almost sure I have seen something similar to what you report in
> the past. But now, what I usually do is to first configure jhalfs whithout
> ticking "Run the Makefile", then manually type: make -C /mnt/lfs/jhalfs. This
> way, no signals are intercepted... Maybe it'd be better to remove the
> capability to automatically run the Makefile, and just have an informational
> message "Configuration is now finished. Type "make -C /mnt/lfs/jhalfs" to
> begin the build".

Right.  I never have jhalfs run the makefile automatically.  I always

cd /mnt/lfs/jhalfs
make

I do run over ssh though.

> For the second issue, I am almost sure I do not see that, but since this part
> is not logged, I cannot be totally affirmative. I have seen that on old debian
> (6 maybe) versions, though.

In this case, the host was 7.10-rc1.  I'll note that this never happens to 
me from the terminal.  Only in a script.

I posted to get it in the mailing lists.  I'm not asking for changes.

   -- Bruce


More information about the alfs-discuss mailing list