Hi Raik,
On Dec 4, 2013, at 9:42 AM, <[email protected]>
<[email protected]> wrote:
> parse_cmd_output): cmd "tar xjf /home/eb/.local/easybuild/sources/g/GCC/
> gmp-5.0.4.tar.bz2" exited with exitcode 2 and output:
> bzip2: (stdin) is not a bzip2 file.
> tar: Child returned status 2
> tar: Error is not recoverable: exiting now
> ---
>
> Somebody an idea?
I often get these kind of errors as well, it universally reduces to the
following situation:
* the cause is my bad, because if running multiple concurrent builds (via xargs
or parallel)
* I manually try to bunzip/untar, to verify that the sourceball is indeed
corrupted
* generally it is, so I simply remove it, and run eb exactly once, to
re-download it
* eb should go through the extract step unobstructed, that's your green light
* by this moment you can now spawn 10+ builds over the same source w/out issues
The good news are, that as you progress in the effort over multiple weeks,
and build your "source" dir, it becomes less and less probable to hit this
issue.
Potential solutions for the community:
* (short-term) add md5/sha hashes, to warn the user gracefully about this issue
* (long-term) use some scheduling of short that prevents parallel downloads
(ie. either make each write step atomic or, simply re-schedule builds)
I am totally interested to heat if anybody has to propose a way
to avoid certain parallel builds, because it also solves some other issues
(some packages eg. NCBI vs BLAST do not like to be build alongside each other)
cheers,
Fotis
--
echo "sysadmin know better bash than english" | sed s/min/mins/ \
| sed 's/better bash/bash better/' # Yelling in a CERN forum
