Bug 56165

Summary: autofs process shuts down shortly after boot up
Product: [Retired] Red Hat Linux Reporter: John Strauss <jms>
Component: autofsAssignee: Jeff Moyer <jmoyer>
Status: CLOSED WORKSFORME QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
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-21 15:33:58 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:

Description John Strauss 2001-11-13 15:52:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1)
Gecko/20010607 Netscape6/6.1b1

Description of problem:
when the system boots up, one of our five autofs processes shuts down.
the message in /var/log/messages is "shutting down, path = /auto/usr/local".

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


How reproducible:
Sometimes

Steps to Reproduce:
1. our /et/auto.master:
/auto/people            /etc/auto.people        rsize=8192,wsize=8192
/auto/millfilm          /etc/auto.millfilm      rsize=8192,wsize=8192
/auto/nreal             /etc/auto.nreal         rsize=8192,wsize=8192
/auto/usr/local         /etc/auto.local         rsize=8192,wsize=8192
/auto/hosts             /etc/auto.hosts         rsize=8192,wsize=8192

2. /etc/auto.local:
lsf.logs        -rw,soft,intr   lsflogs:/usr/local/&
oracle          -rw,soft,intr   nobby:/usr/local/&

3. reboot!
	

Actual Results:  9 times out of ten, there is no process for
/auto/usr/local.  there is no entry for it in /etc/mtab.

Expected Results:  there should be an automount process running for
/auto/usr/local

Additional info:

this snippet from /var/log/messages when we are booting up:
Nov 13 12:43:51 alpha automount[664]: starting automounter version 3.1.7,
path = /auto/people, maptype = file, mapname = /etc/auto.people
Nov 13 12:43:51 alpha automount[677]: starting automounter version 3.1.7,
path = /auto/millfilm, maptype = file, mapname = /etc/auto.millfilm
Nov 13 12:43:51 alpha automount[698]: starting automounter version 3.1.7,
path = /auto/nreal, maptype = file, mapname = /etc/auto.nreal
Nov 13 12:43:51 alpha automount[719]: starting automounter version 3.1.7,
path = /auto/usr/local, maptype = file, mapname = /etc/auto.local
Nov 13 12:43:51 alpha automount[748]: starting automounter version 3.1.7,
path = /auto/hosts, maptype = file, mapname = /etc/auto.hosts

this snippet comes a few minutes later:
Nov 13 12:47:38 alpha automount[677]: attempting to mount entry
/auto/millfilm/plate
Nov 13 12:47:38 alpha automount[677]: attempting to mount entry
/auto/millfilm/pinback
Nov 13 12:48:27 alpha ntpd[587]: time reset 0.333314 s
Nov 13 12:48:27 alpha ntpd[587]: kernel pll status change 41
Nov 13 12:48:27 alpha ntpd[587]: synchronisation lost 
Nov 13 12:50:01 alpha automount[677]: attempting to mount entry
/auto/millfilm/mutha
Nov 13 12:50:50 alpha automount[719]: shutting down, path = /auto/usr/local

additional comments:
this mount always succeeds for RH versions < 7.1
appears to be more severe for 7.1sbe than 7.1
the workaround is easy; just run autofs reload when the mount falls over. 
but it is not something one wants to babysit when there are a couple of
hundred systems of various platforms to administer.

Comment 1 Jeff Moyer 2004-03-19 21:47:20 UTC
Do you still observe this behaviour with the current version of the
automounter?