[Rd] 00LOCK and nfs

Kasper Daniel Hansen kasperdanielhansen at gmail.com
Mon Apr 26 21:05:20 CEST 2010


2010/4/26 Christian Brechbühler <brechbuehler at gmail.com>:
>
>
> On Mon, Apr 26, 2010 at 11:15 AM, Kasper Daniel Hansen
> <kasperdanielhansen at gmail.com> wrote:
>>
>> I am running into a problem with the 00LOCK file and .nfs files.  It
>> seemed to be caused by the following
>>  R is installed on NFS
>>  user A has loaded pkg_A containing a dynamically loaded library
>>  user B (the administrator) runs install.packages("pkg_A")
>>  as the final part of the installation process the 00LOCK directory is
>> removed
>>  this creates a .nfs file because user A has the dynamic library open
>>  this .nfs file cannot be removed until user A exits R
>>  because of this, 00LOCK cannot be removed, and if the
>> install.packages call is going to install packages after pkg_A, they
>> fail
>
> Yup, I've seen that.  The program "lsof" can be useful to find which process
> has the library open.
> User A does not need to exit R; it's enough to detach(package:pkg_A);
> library(pkg_A);.

I have now done more careful experimentation with a colleague so I
have more than 1 user, and my earlier description was wrong.  I can
reliably trigger this 00LOCK problem if a single user does
library(pkg_A) and then in a separate R session does
install.packages(pkg_A).

I cannot reliable trigger it if
1) the library() and install.packages() were done by the same user,
but on different nodes
2) the library() and install.packages() were done by different users, same node
3) the library() and install.packages() were done by different users,
different nodes

I believe I have run into this problem with 00LOCK when I only had one
R session running (the one doing the install.packages), so I am
beginning to believe that what I seem to run into is a race problem.
But I could of course be wrong.

Kasper



More information about the R-devel mailing list