Hello,
I'm trying to build the `intel-2016a` toolchain using EB. Installation
stop pretty soon at the end of the `icc` install with this error:
== 2016-05-04 17:24:09,107 build_log.py:152 ERROR Cleaning up intel dir
/scratch/rmurri/rmurri/easybuild_intel failed: [Errno 39] Directory not empty:
'/scratch/rmurri/rmurri/easybuild_intel/ism/rm' (at
easybuild/easyblocks/generic/intelbase.py:165 in clean_home_subdir)
Now, first question: why is this a *fatal* error? `icc` has been
unpacked, installed, and tested correctly. Failure to cleanup the
leftovers is annoying but should not be critical... Or is there
something I'm missing?
Then, the more interesting part is *why* did the failure happen?
Ostensibly, the directory to be removed is indeed empty:
$ ls -lAR /scratch/rmurri/rmurri/easybuild_intel/ism/rm
/scratch/rmurri/rmurri/easybuild_intel/ism/rm:
total 0
However, there are some hidden files in a sibling directory::
$ ls -lAR /scratch/rmurri/rmurri/easybuild_intel
/scratch/rmurri/rmurri/easybuild_intel:
total 4
drwxr-xr-x. 3 rmurri uzh 4096 4 mag 17.25 ism
/scratch/rmurri/rmurri/easybuild_intel/ism:
total 4
drwxr-xr-x. 3 rmurri uzh 4096 4 mag 17.25 bin
/scratch/rmurri/rmurri/easybuild_intel/ism/bin:
total 4
drwxr-xr-x. 2 rmurri uzh 4096 4 mag 17.25 intel64
/scratch/rmurri/rmurri/easybuild_intel/ism/bin/intel64:
total 640
-rwxr-xr-x. 1 rmurri uzh 621864 4 mag 17.24 .nfs0000000021cd01c80000691b
-rwxr-xr-x. 1 rmurri uzh 32128 4 mag 17.24 .nfs0000000021cd01c90000691c
$ fuser -v
/scratch/rmurri/rmurri/easybuild_intel/ism/bin/intel64/.nfs0000000021cd01c*
USER PID ACCESS COMMAND
/net/nfs4/nfs.hydra/scratch/rmurri/rmurri/easybuild_intel/ism/bin/intel64/.nfs0000000021cd01c80000691b:
rmurri 54634 ....m intelremotemond
/net/nfs4/nfs.hydra/scratch/rmurri/rmurri/easybuild_intel/ism/bin/intel64/.nfs0000000021cd01c90000691c:
rmurri 54634 ...e. intelremotemond
If I kill the `intelremotemond` process, the entire `easybuild_intel`
hierarchy can be successfully removed. So my guess is that either
(1) EasyBuild does not kill `intelremotemond` (what's its purpose, by
the way?), or (2) does not wait enough after killing it, or (3) everyone
else is using a filesystem that handles "delete an open inode" in a sane
way...
Is there a suggested fix?
Ciao,
R
--
Riccardo Murri
http://www.s3it.uzh.ch/about/team/#Riccardo.Murri
S3IT: Services and Support for Science IT
University of Zurich
Winterthurerstrasse 190, CH-8057 Zürich (Switzerland)
Tel: +41 44 635 4208
Fax: +41 44 635 6888
