Hi Kenneth,
> >- The EasyBlock in `intelbase.py` is using this temporary directory tree
> > as a "redirect" for stuff that the Intel installer would put into
> > `$HOME/intel`. While I appreciate the effort to keep the home
> > directory clean, it does not AFAICT fulfill its stated purpose
> > ("enable parallel builds"): there can only be one symlink at a time so
> > you cannot install two different intel toolchains at the same time.
>
> It actually *does* fulfill the purpose, because the assumption is that the
> temporary directory is the same path across systems where Intel
> installations are being performed, and that $HOME is a shared filesystem.
> [...]
> I do admit this is not perfect though, since this approach will fail when
> you're running multiple Intel installations on the same system at the same
> time.
What does the comment "enable parallel builds" mean then? The Intel
installer is not parallel by any reasonable sense of the word, so if you
cannot run many of them simultaneously (in parallel), what's the point?
> >- The `intelremotemond` cannot be easily disabled during the
> > installation process, as it is embedded in a gzip'ed tarball within
> > the Intel Parallel Composer XE tarball ...
>
> My main question is why the intelremotemond stays behin; it doesn't happen
> for us...
> I guess this is related to it being started from an NFS directory (some kind
> of locking problem, maybe)?
Please see the email that started this thread. The issue is that Linux'
NFS client maps the `unlink()` operation on an open inode to a rename,
i.e., translates `rm <OPEN FILE>` to `mv <OPEN FILE> .nfs<RANDOM NUMBER>`.
This causes the `shutil.rmtree()` call in `Intelbase.cleanup_*()` to
fail: directories containing open files will not be empty even after all
those files have been `rm`'ed, so `rmdir` will fail, etc.
Apparently this is specific to NFS-mounted file systems; local
filesystems do not exhibit the same behavior.
> In any case: using an NFS-mounted directory as tmpdir is not wise, it's
> likely it'll get you into trouble in other places too...
Well, I have no other option if the directory has to be shared across
nodes. But apparently that is *not* required for Intel stuff (unless
one uses `--job`, I guess).
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
