From tplate at acm.org  Tue Apr 27 16:36:17 2010
From: tplate at acm.org (Tony Plate)
Date: Tue, 27 Apr 2010 08:36:17 -0600
Subject: [Rd] 00LOCK and nfs
In-Reply-To: <y2le780c0971004261205i39f069dt379690211f8f8a7f@mail.gmail.com>
References: <s2le780c0971004260815we5156859v293d5b3a6ffd9890@mail.gmail.com>	<l2kc0177e5a1004261054k3775628fyb6c1fd154707dd91@mail.gmail.com>
	<y2le780c0971004261205i39f069dt379690211f8f8a7f@mail.gmail.com>
Message-ID: <4BD6F661.10409@acm.org>

I have some tools and an R package that together provide a solution to 
the problem of updating an R package while it is attached in one or more 
running R sessions (whether on the same machine or not.)  The technique 
is to always create a new directory for the newly installed package, so 
that existing installed packages are never overwritten.  The tricky part 
is to manage this in a way that is transparent to the user, which is 
what the package accomplishes.  If this is any interest in this I could 
make it available; email me privately or respond on the list.

-- Tony Plate

On 4/26/2010 1:05 PM, Kasper Daniel Hansen wrote:
> 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
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>



[Rd] 00LOCK and nfs
Tony Plate