Bug 90330 - System hangs in autofs, but without any NFS errors
System hangs in autofs, but without any NFS errors
Product: Red Hat Linux
Classification: Retired
Component: autofs (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jeff Moyer
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2003-05-06 19:52 EDT by Matthew Braithwaite
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-11 17:22:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Stack trace of a system having this problem (75.00 KB, text/plain)
2003-05-06 19:53 EDT, Matthew Braithwaite
no flags Details

  None (edit)
Description Matthew Braithwaite 2003-05-06 19:52:05 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; FreeBSD i386; U;) Gecko/0

Description of problem:
We have a number of systems that automount user home directories and a few other
filesystems with the following options:


With some frequency these systems become useless, in a way that suggests the
automounter is at fault.  `df' hangs, and nobody (including root!) can login via
ssh.  The only way we can get in is root login on the console, and that one
login session is extremely fragile, because many commands that root might wish
to run to investigate the problem will hang his session.

The best lead we have is the stack trace for every process on the system,
obtained through the SysRq feature.  I'll append this.

One might suspect that this is at root an NFS problem -- e.g. some NFS server
has gone away.  There are two difficulties with this hypothesis:  first, we have
only four NFS servers, and we know that none of them are having problems.  (They
were not to our knowledge down at the onset of the problem, and in any case were
definitely up by the time we started investigating.)  And second, the consoles
of machines that suffer from the problem, which we log, did not record any NFS

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

How reproducible:
Didn't try

Steps to Reproduce:
We've got NFS and autofs activity going on all day.  We just have to wait for it
to happen.

Additional info:
Comment 1 Matthew Braithwaite 2003-05-06 19:53:00 EDT
Created attachment 91527 [details]
Stack trace of a system having this problem
Comment 2 David Alden 2003-06-12 07:37:01 EDT
  Just wanted to add that I'm having a similar (maybe the same?) problem.
except I'm running Redhat 9 on the client that's having a problem.  For me,
I can login so long as I hit ^C.  So far, the problem has always occurred
on the same automount point -- /home/mail, which happens to be the only map
entry that contains mount options, the entry looks like:

mail  -rw,soft,bg  mail:/var/spool/mail

If I run strace agains the child automount daemon, all I get is "read(4,".
I can mount the partition without any problems:

# mount -o rw,soft,bg mail:/var/spool/mail /mnt
# umount /mnt

I'm going to wait until it locks up one more time, then I'm going to try
removing the mount options to see if that makes a difference. 

...dave alden
Comment 3 David Alden 2003-07-08 08:50:00 EDT
  Quick followup -- I changed the mount options in the auto.home file to
just rw,soft (I took out bg) and it hasn't locked up since.
Comment 4 Jeff Moyer 2004-03-22 15:10:25 EST
Please try with the latest distribution.  If you still have problems,
be sure to include the kernel version and the version of the autofs
user space.


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