Hello,
On Sunday 09 November 2008 04:11, zooko wrote:
> My Mac buildslave was running at max CPU (I always notice, because
> the fan comes on). "top" tells me that the "yes" command is using
> max CPU for an hour straight. The buildbot test log says that it is
> in the middle of a test named "issue1017_whatsnew_stack.sh". I
> finally killed that "yes" command and seconds later another one
> started. I killed that one too, and then the buildbot tests completed.
Thanks a lot, this description reminded me of a similar problem that existed
for the GHC buildbots and this time, I seem to have gotten to the bottom: The
problem is demonstrated by the command
> $ yes | head -n 2
> y
> y
> $
which is used (with larger counts) to generate test files in
"issue1017_whatsnew_stack.sh". When run via the command line, this works fine
and the test succeeds. When run via the Python os.system call on a Mac OS X,
however, the command never terminates. Here is a demonstration of that
behaviour:
> $ cat runCmd.py
> import os
> os.system('yes | head -n 2');
> $ python runCmd.py
> y
> y
> ^C$
So, the two ys appear, a looping yes program can be observed with top, and C-c
is needed to terminate. The point of this is that buildbot, as far as I know,
is a Python program, so this may be the reason why we see this looping
behaviour on the Mac OS X buildbot slaves.
As a side note, on a Linux system, the same Python program reacts like this:
> $ python runCmd.py
> y
> y
> yes: standard output: Broken pipe
> yes: write error
> $
So the loop is avoided, but yes nevertheless reacts differently from when it
is run directly from the command line.
I will submit a patch for "issue1017_whatsnew_stack.sh" that generates test
files using a different mechanism shortly.
> ...
Thanks and best regards
Thorkil
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users