[OmniOS-discuss] cannot remove temp dir

[Matthieu Paindavoine]

Hello,

Following Paul's suggestion, I did the following:
#> cd /tmp
#> unlink cabal-install ...
#> ls (-> nothing)
#> cd ..
#> umount /tmp
#> zfs create rpool/export/tmp
#> zfs set mountpoint=/tmp rpool/export/tmp
#> cd /tmp; touch foo (-> ok, foo is there)
#> cd ~; cabal install --global cabal-install
tada! It's working

It's probably a problem with tmpfs then...

Hope this helps.

Matthieu


________________________________
 De : Paul B. Henson <henson at acm.org>
À : omnios-discuss at lists.omniti.com 
Envoyé le : Vendredi 10 mai 2013 2h50
Objet : Re: [OmniOS-discuss] cannot remove temp dir
 

> On 5/9/2013 7:28 AM, Matthieu Paindavoine wrote:
>
>> I am new to OmniOS. I am trying to setup a Haskell development
>> environment and ran against a bump that's preventing me from completing
>> the task. I mentioned this problem yesterday on IRC and got some help,
>> but no definitive solution.
> [...]
>> execve("/usr/gnu/bin/rm", 0x08047D24, 0x08047D34)  argc = 3
> [...]
>> rmdir("cabal-install-1.16.0.2-21814")        Err#17 EEXIST

Matthieu provided remote access to the system he was working on, and I 
took a look at this.

On the one hand, it's fairly clear why the directory can't be deleted:

# ls -ld cabal-install-1.16.0.2-21814
drwx------ 3 root root 117 May 10 02:00 cabal-install-1.16.0.2-21814
           ^^^

It's got a link count of 3, and per the tmpfs code:

tmp_rmdir(
[...]
         if (self->tn_nlink > 2) {
                 mutex_exit(&self->tn_tlock);
                 error = EEXIST;

If a directory has a link count greater than two, it returns EEXIST.

It's also fairly easy to replicate the scenario:

# mkdir test
# ls -ld test
drwxr-xr-x 2 root root 117 May 10 02:27 test

# link test test2
# ls -ld test test2
drwxr-xr-x 3 root root 117 May 10 02:27 test
drwxr-xr-x 3 root root 117 May 10 02:27 test2

# rmdir test
rmdir: failed to remove 'test': File exists

# unlink test2
# rmdir test

What's not so obvious is where the other link to the directory 
cabal-install-1.16.0.2-21814 is. For my simple test:

# ls -lid test*
2675840857 drwxr-xr-x 3 root root 117 May 10 02:28 test
2675840857 drwxr-xr-x 3 root root 117 May 10 02:28 test2

The two links of course have the same inode, and if you search by inode:

# find . -inum 267584085
./test
./test2

They are both found. On the other hand, for the cabal directory:

# ls -lid cabal-install-1.16.0.2-21814
2677295311 drwx------ 3 root root 117 May 10 02:00 
cabal-install-1.16.0.2-21814

# find . -inum 2677295311
./cabal-install-1.16.0.2-21814

There appears to only be one link with that inode on the file system. 
This is all in /tmp, mounted on tmpfs:

# mount | grep tmp
/tmp on swap read/write/setuid/devices/xattr/dev=83c0002 on Thu May  9 
09:37:34 2013

So I don't really see that there's any other place a link could exist, 
it won't allow you to link across devices. Just for fun I tried a search 
starting at the root:

# find / -inum 2677295311
/tmp/cabal-install-1.16.0.2-21814

Just the one link.

So I'm a bit stumped. What I would probably do next is run whatever 
process generates the cabal directory under truss -f and see what's 
calling the link syscall. Matthieu, perhaps you could do that and make 
the output available?

I think I might post this to the developer list, and see if anybody has 
any idea where that other link disappeared to. Matthieu, I'd also be 
curious to see what would happen if you unmounted /tmp from tmpfs and 
used just a regular zfs filesystem, perhaps the build is doing something 
weird that's poking a bug in tmpfs resulting in a dangling reference?

_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20130510/8ec81c0f/attachment.html>