GNU bug report logs - #7198
ls-misc failure with Oct 10 snapshot

Previous Next

Full log

View this message in rfc822 format

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 7198 <at> debbugs.gnu.org
Subject: bug#7198: ls-misc failure with Oct 10 snapshot
Date: Wed, 13 Oct 2010 09:37:06 +0200

Paul Eggert wrote:
> On 10/12/10 10:57, Jim Meyering wrote:
>
>> What version of RHEL 5.N?  I.e., what's "N"?
>
> /etc/issue says "Red Hat Enterprise Linux Server release 5.5 (Tikanga)".
> uname -a says "Linux lnxsrv01.seas.ucla.edu 2.6.18-194.17.1.el5 #1 SMP Mon Sep 20 07:12:06 EDT 2010 x86_64 GNU/Linux".
...
> Oh, and when running atop an NFS file system I found another problem,
> which occurs with both the standard gcc and with my GCC 4.5.1:
>
> FAIL: test-rename (exit: 134)
> =============================
>
> test-rename.h:121: assertion failed
>
> Here's the output of "strace ./test-rename" in gnulib-tests:
>
> mkdir("test-rename.tdir2", 0700)        = 0
> creat("test-rename.tdir/file", 0600)    = 4
> close(4)                                = 0
> rename("test-rename.tdir2", "test-rename.tdir") = -1 ENOTEMPTY (Directory not empty)
> rename("test-rename.tdir2/", "test-rename.tdir") = -1 ENOTEMPTY (Directory not empty)
> rename("test-rename.tdir2", "test-rename.tdir/") = -1 ENOTEMPTY (Directory not empty)
> rename("test-rename.tdir", "test-rename.tdir2") = 0
> stat("test-rename.tdir", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
> write(2, "test-rename.h:121: assertion fai"..., 36test-rename.h:121: assertion failed
> ) = 36

That's not good.  It looks like a race, where the client thinks the
source of the rename is still there for some short interval after the
rename succeeded.

What is the server running?

> The amusing thing is that, after the strace, "ls -l test-rename.t*"
> reports only this:
>
> $ ls -ltd test-rename.tdir*
> drwx------ 2 eggert csfac 4096 Oct 12 16:35 test-rename.tdir2
>
> Perhaps there's a bug in the RHEL 5.5 NFS client?

There's definitely something suspicious going on...

> That might
> conceivably explain the misc/ls-misc problem that started this thread.

First step for that one should be to avoid the warnings from perl,
e.g., via the patch I suggested.

> I'll try to look into this more latter; gotta run now.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.