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

Bug#447562: marked as done (nfs-common: Locks are only released after delay when using IP alias or secondary IP)

Your message dated Fri, 14 Aug 2009 01:01:39 +0200
with message-id <20090813230139.GA26678@galadriel.inutil.org>
and subject line Re: Bug#447562: nfs-common: Locks are only released after delay when using IP alias or secondary IP
has caused the Debian Bug report #447562,
regarding nfs-common: Locks are only released after delay when using IP alias or secondary IP
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.)


-- 
447562: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447562
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: nfs-common
Version: 1:1.0.10-6+etch.1
Severity: normal

I try to setup an NFS server in a Heartbeat configuration. The normal setup for this is to have an IP alias or secondary IP 
to which the NFS clients connect. Everything works, but when a client releases a file lock, the other client(s) (waiting for 
the lock to come free) is/are not notified. After 30 seconds the other client ask the server again about the lock, and it is 
granted the lock. (Max) 30 seconds to late, that is.

The fact that I use Heartbeat is not important here, this behaviour is perfectly reproducible on a simple (single) NFS 
server when the clients connect to an IP alias or secondary IP adress.

Clients that connect to a primary IP address ARE always notified about released file locks. Also if the client that releases 
the lock is connected to the IP alias or secondary IP.

I tested file locking with C fcntl and Perl flock. Both showed the behaviour described.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-vserver-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages nfs-common depends on:
ii  adduser  3.102                           Add and remove users and groups
ii  libc6    2.3.6.ds1-13etch2               GNU C Library: Shared libraries
ii  libcomer 1.39+1.40-WIP-2006.11.14+dfsg-2 common error description library
ii  libevent 1.1a-1                          An asynchronous event notification
ii  libgssap 0.10-4                          A mechanism-switch gssapi library
ii  libkrb53 1.4.4-7etch2                    MIT Kerberos runtime libraries
ii  libnfsid 0.18-0                          An nfs idmapping library
ii  librpcse 0.14-2                          allows secure rpc communication us
ii  libwrap0 7.6.dbs-13                      Wietse Venema's TCP wrappers libra
ii  lsb-base 3.1-23.2etch1                   Linux Standard Base 3.1 init scrip
ii  netbase  4.29                            Basic TCP/IP networking system
ii  portmap  5-26                            The RPC portmapper
ii  ucf      2.0020                          Update Configuration File: preserv

nfs-common recommends no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
On Fri, Dec 26, 2008 at 06:00:00PM +0100, Moritz Muehlenhoff wrote:
> On Mon, Oct 29, 2007 at 06:44:45PM +0100, Mark Hunting wrote:
> > reassign 447562 linux-image-2.6.18-5-686
> > stop
> >
> >> Hi,
> >>
> >> nfs-utils only deals with setting up the connection; the actual NFS serving
> >> is done by the kernel. Reassigning appropriately.
> >>
> >> /* Steinar */
> >>   
> > Thanks for your input. The bug is actually on the NFS server, using  
> > kernel linux-image-2.6.18-5-686, non-vserver. Only the clients are  
> > vservers, but that should not be the problem.
> 
> Does this error still occur with more recent kernel versions?
> 
> If you're running Etch, could you try to reproduce this bug
> with the 2.6.24 based kernel added in 4.0r4?
> http://packages.qa.debian.org/l/linux-2.6.24.html

No further feedback, closing the bug.

If anyone reencounters the problem, please reopen this bug.

Cheers,
        Moritz

--- End Message ---
Reply to: