Note that this patch is incomplete: there are three separate branches
in install.packages() where R CMD INSTALL is used, and one already
uses --pkglock. (So a short-term solution for you is to set Ncpus >
1.)
However, I think this request has been subsumed by a more general need
to be able to pass options to INSTALL, and R-devel now has an
INSTALL_opts argument to install.packages(). So I believe you could
just use install.packages( ... , INSTALL_opts = "--pkglock") .
On Tue, 1 Jun 2010, Kasper Daniel Hansen wrote:
Further experimentation using this patch to install.packages shows
that I sometimes have remaining 00LOCK-pkgname directories after doing
a massive update on a multi-user system with R installed on NFS.
However, I have never had install.packages/update.packages stop midway
because of an unremovable 00LOCK directory. I therefore consider the
patch to be big improvement for people like me, having a multi-user R
installed on NFS. Private followups to my original email shows that I
am not the only one with this problem.
But I should point out that others with well-tuned NFS do not have the
problem -- my sysadmins say that it was common with NFSv3 but they've
hardly seen it with NFSv4.
I would very much like the patch (or some variant hereof) to be
considered for inclusion in R-devel.
Kasper
On Tue, May 18, 2010 at 11:59 AM, Kasper Daniel Hansen
<kasperdanielhan...@gmail.com> wrote:
This is a follow-up to an old thread with kind of solution to the
00LOCK problem on NFS.
I have made a patch to install.packages to accept a new argument
locktype = c("lock", "no-lock", "pkglock")
which is passed to R CMD INSTALL. This addition might have
independent interest aside from the NFS problem, as it exposes
functionality from R CMD INSTALL to install.packages and the very
convenient update.packages. Patches are at
http://www.biostat.jhsph.edu/~khansen/packages2.R-patch
http://www.biostat.jhsph.edu/~khansen/install.packages.Rd-patch
(patches to files in the utils package) and both
R-devel (R version 2.12.0 Under development (unstable) (2010-05-17 r52025))
and
R-2.11 (R version 2.11.0 Patched (2010-05-17 r52025))
passed make check-all with these two patches applied. I thought about
adding a note describing my findings below to the details section, but
decided against it.
Regarding the 00LOCK problem. In my testing, using the patches above
and setting locktype = "pkglock", makes it possible to deal with the
NFS problem. Specifically, I have not been able to make
update.packages() fail midway, due to a un-removable 00LOCK file
(which is not too surprising, as I now have a per-package lock).
However, sometimes (but far less frequently than before), a
00LOCK-pkgname directory remains after update/install.packages.
Sometimes this 00LOCK-pkgname directory does not contain any .nfs*
files (!?) and sometimes it does. For this reason, I still precede any
install/update.packages with a check for the existence of a
00LOCK-pkgname directory and an attempt to remove it.
The difference between using locktype = "pkglock" and not is
specifically that without, it was possible for update.packages to fail
midway even though there were no 00LOCK* files at the start of the
update process.
Originally I hypothesized that the presence of the .nfs* files in the
00LOCK directory had to do with synchronization issues between the
file server and the compute node. In order to approach this I tried
to insert a
system("sleep 10")
at the beginning of
do_cleanup
in
tools/R/install.R
but that did not work.
Since the pkglock approach described above seems to solve this issue
for me, I have not pursued the synchronization issue further.
Kasper
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
