[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#508867: marked as done (libxau6: ESTALE on nfs mounts)

Your message dated Mon, 4 Apr 2011 05:41:16 +0200
with message-id <20110404034116.GA941@debian.org>
and subject line Re: Bug#508867: stale nfs filehandle
has caused the Debian Bug report #508867,
regarding libxau6: ESTALE on nfs mounts
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
508867: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508867
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libxau6
Version: 1:1.0.3-3
Severity: normal

There is a bug in >= 2.6.24 kernels[1], where a stat() in the nfs client
may return -ESTALE on an .Xauthority file that has been atomically
renamed from another host (ie, .Xauthority now has a different inode;
this happens when sshing to another host for example).  A subsequent
open on the file without stat()ing it first (eg, with 'xauth list' on
the client) will succeed, and will update the nfs client's attribute
cache.

This bug can probably be worked around in the xauthority library (as
well as fixed in the kernel, since some people will be able to upgrade
one and not the other in a production environment) such that if stat()
returns -ESTALE, it should be reopened (and perhaps read from) before
closing and retrying the stat() again.

See the following[2] trace of an xterm on the nfs client.

The bug is rare enough (although it's happened to me 3 times today)
that I haven't yet seen the exact sequence necessary to recreate it -
I suspect it involves an X operation on the nfs client, followed
quickly (within the nfs cache timeout) by an ssh into a remote host,
followed by quickly opening a new xterm on the client.  Although I say
"quickly", it seems that the buggy nfs client may be caching the stale
handle longer than it's meant to.

[1] debian bug 508866 and ubuntu bug 269954:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/269954


[2]
open("/proc/meminfo", O_RDONLY)         = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4cd0a2a000
read(3, "MemTotal:      3096244 kB\nMemFree"..., 1024) = 774
close(3)                                = 0
munmap(0x7f4cd0a2a000, 4096)            = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 3
getsockopt(3, SOL_SOCKET, SO_TYPE, [68719476737], [4]) = 0
connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"...}, 110) = 0
getpeername(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"...}, [139964394242068]) = 0
uname({sys="Linux", node="aatpc2", ...}) = 0
access("/home/aatlxz/twc/.Xauthority", R_OK) = -1 ESTALE (Stale NFS file handle)
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
select(4, [3], [3], NULL, NULL)         = 1 (out [3])
writev(3, [{"l\0\v\0\0\0\0\0\0\0"..., 10}, {"\0\0"..., 2}], 2) = 12
read(3, 0x198e160, 8)                   = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "\0\26\v\0\0\0\6\0"..., 8)      = 8
read(3, "No protocol specified\n\0\0"..., 24) = 24
write(2, "No protocol specified\n"..., 22No protocol specified
) = 22
close(3)                                = 0
open("/usr/lib/X11/XtErrorDB", O_RDONLY) = -1 ENOENT (No such file or directory)


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libxau6 depends on:
ii  libc6                         2.7-16     GNU C Library: Shared libraries

libxau6 recommends no packages.

libxau6 suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
Hi,

Julien Cristau <jcristau@debian.org> (18/03/2009):
> If there's a bug here, I don't think it warrants 'grave' severity.
> Also the initial bug is being fixed in the kernel in 2.6.29
> (#508866), so this one should probably be retitled.

this bug's been tagged moreinfo in 2009, the kernel bug's long fixed
now, so I guess this bug against libxau can be closed now. Doing so
with this mail.

KiBi.

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: