Bug 135114 - autofs init script start/restart doesn't check for existing busy mounts
Summary: autofs init script start/restart doesn't check for existing busy mounts
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-08 18:51 UTC by Anonymous
Modified: 2007-11-30 22:07 UTC (History)
0 users

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

Attachments (Terms of Use)
My suggested fix for this bug (892 bytes, patch)
2004-10-08 18:53 UTC, Anonymous
no flags Details | Diff

Description Anonymous 2004-10-08 18:51:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040823

Description of problem:
When "service autofs stop" or "service autofs restart" is run, busy
mounts do not get stopped.  When the "start" function is called, it
does not check to see if any of these busy mounts still exist.  The
result is that "service autofs restart" frequently causes two
automount processes to operate on the same mount point, which can
result in an unstable system.

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

How reproducible:

Steps to Reproduce:
1. set up an automount controlled directory

auto.master contains:  /home   /etc/auto.home
auto.home contains:    zillabug   nfsserver:/home/zillabug

2. service autofs start
3. cd /home/zillabug
4. service autofs stop

the automount process for /home is still running at this point

5. service autofs start

Actual Results:  There are now two automount processes trying to
control /home and everything underneath it.

Expected Results:  the initscript (in step 5) should realize that
/home is already controlled by automount, and refuse to start that
particular map.

Additional info:

Comment 1 Anonymous 2004-10-08 18:53:35 UTC
Created attachment 104956 [details]
My suggested fix for this bug

Comment 2 Jeff Moyer 2004-11-01 22:04:12 UTC
This is something that the daemon should already handle.  This code exists in
the automount startup:

	if ((ap.state != ST_INIT) || is_mounted(path)) {
		/* This can happen if an autofs process is already running*/
		error("mount_autofs: already mounted");
		return -1;

Are there any autofs messages in /var/log/messages?  What do /proc/mounts and
/etc/mtab look like both before and after the subsequent autofs start?

Comment 3 Anonymous 2004-11-05 17:27:03 UTC
My mistake.  The server I tested this on must have still been running
autofs 3.  After reading this, I went to a few servers running autofs
4 and was not able to reproduce.

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