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 
user)
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.