Bug 132709

Summary:	NFS client can't reconnect after server reboots
Product:	[Fedora] Fedora	Reporter:	Alexandre Oliva <oliva>
Component:	kernel	Assignee:	Dave Jones <davej>
Status:	CLOSED CANTFIX	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	3	CC:	dgunchev, pfrields, steved, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-10-03 00:48:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	123268, 136451

Description Alexandre Oliva 2004-09-16 04:43:49 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040809

Description of problem:
If you mount one (or several) filesystems from one server running
FC3test2-ish on a client running the very same software, and the
server reboots because you typed reboot on the wrong window, even
after the server comes back up, the client won't ever regain access to
the previously-mounted mount point.  You have to explicitly umount it
and then mount it again.  Kind of a problem if the client was in the
middle of an NFS install and you can't even switch to VT2 to attempt
to remount it :-)

I've experienced the same problem with autofs-mounted NFS mounts as well.

Version-Release number of selected component (if applicable):
kernel-2.6.8-1.541

How reproducible:
Always

Steps to Reproduce:
1.Mount a filesystem over NFS from an FC3test2 server on an FC3test2
client
2.Reboot the server
3.Try to access the filesystem after the server comes back up

Actual Results:  mount point will be stale, or will block, depending
on some conditions I can't figure out

Expected Results:  It should reconnect after some time, but it doesn't
even seem to have tried, after more than half an hour

Additional info:

Comment 1 Alexandre Oliva 2004-09-28 11:14:02 UTC

FWIW, I have some evidence that the problems I'm experiencing have to
do with iptables connection tracking.  I have iptables set up to let
UDP packets from port 2049 pass through from the server, as well as
TCP syn packets from port 2049, as well as established tcp
connections.  Whenever I run into the problem, the mount point has
been idle for quite some time (hours; no clue on why autofs wouldn't
have unmounted it), and attempts to access the filesystem will trigger
log messages from iptables on the client, denying server replies from
making it to the NFS client code in the kernel.  Sometimes, after a
time out, the connection is restablished.  But not always.

I think it's safe to disregard this as a kernel problem.  I have now
to figure out how to get autofs to use some keepalive NFS mount
option, or to force the use of udp, or maybe let tcp packets in
regardless of conntrack.

Comment 2 Dave Jones 2004-11-27 21:48:12 UTC

the current 2.6.9 based update has quite a few NFS related fixes, can you see if
this problem is repeatable there ?

Comment 3 Dave Jones 2005-07-15 20:08:28 UTC

An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 4 Dave Jones 2005-10-03 00:48:45 UTC

This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.

There are a large number of inactive bugs in the database, and this is the only
way to purge them.

Thank you.