Bug 70967 - ftp login hangs while nfs is waiting to reconnect remote offline filesystem
Summary: ftp login hangs while nfs is waiting to reconnect remote offline filesystem
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: wu-ftpd (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: i686 Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-08-07 12:26 UTC by Mike Emmott
Modified: 2007-04-18 16:45 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-27 16:48:54 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Mike Emmott 2002-08-07 12:26:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
How did it fail?  Typing in 'ftp machinename' brought back a login prompt.  
Responding to the login prompt with 'username' brought back a password prompt.  
Responding with a correct password brought back no prompt at all for several 
minutes.  (Meanwhile telnet sessions to the server over the LAN could be 
started without apparent difficulty).

One day ftp into server works, the next it fails.  What has changed?  Answer 
seems to be, 'power failure in neighbouring office switched off machine hosting 
an nfs volume mounted on the server's filesystem'.  The nfs volume (running on 
RH7.2 itself), was mounted using default options and explicit 'rw'.  There was 
an outstanding cron job trying to access the mounted filesystem to copy files 
to it from the server.
Acting as root, unable to kill -9 pid for any of hung ftp sessions on the 
server.  Reading 'man' for fstab, mount, nfs, found that a 'hard' nfs mount 
which isn't responding is doggedly chased down by the system, to the extent 
that related processes 'cannot' be killed.  I get the impression that something 
is tying itself up in knots trying to re-establish the nfs mount, and is 
blocking the ftpd.

The following might or might not be diagnostic:  Whenever I reboot this server 
I have to go to both this one and the one hosting the nfs volume and 
do '/etc/rc.d/init.d/portmap stop', '/etc/rc.d/init.d/nfs stop' and the 
corresponding 'start's, to get the mount working again.  Whenever I do the nfs 
stop, 3 of the 4 items listed are marked as 'failed' rather than 'OK'

The bug is 'failed nfs mount shouldn't preclude ftp login'.

Version-Release number of selected component (if applicable): 2.6.1-18

How reproducible:
Didn't try

Steps to Reproduce:
1.Create a working mount of an nfs filesystem on another RH7.2 server
2.Kill power to the remote server
3.Have cron start a file copy job to the remote server (acting as a non-root 
4.Try to log in to the ftpd on the local host from another host (used Windows 
NT, but don't think this is significant).
5.Log in from other host hangs and ftpd processes are unkillable (even -9).

Actual Results:  After typing in password, get endless wait for an ftp prompt.

Expected Results:  Get ftp prompt from the server

Additional info:

It would be nice if this feature could be removed.  The evidence of the problem 
doesn't point out the problem itself very directly.  Only when I gave up and 
tried to shutdown did I get an idea of what was wrong.  Shutdown messages 
reporting nfs busy and prevented shutdown completing.  Only this alerted me to 
explore the status of the remote nfs server.

Comment 1 Need Real Name 2003-01-29 04:24:06 UTC
I see the same problem on a fully patched 7.3 system.

Comment 2 Thomas Woerner 2004-01-27 16:48:54 UTC
This is no wu-ftpd bug.

Note You need to log in before you can comment on or make changes to this bug.