Bug 55932

Summary:	"/etc/init.d/autofs stop" has problems
Product:	[Retired] Red Hat Linux	Reporter:	Michael Schwendt <bugs.michael>
Component:	autofs	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Brock Organ <borgan>
Severity:	low	Docs Contact:
Priority:	low
Version:	9	CC:	pto, p.van.egdom
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-09-20 21:19:11 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 Michael Schwendt 2001-11-09 00:59:51 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012

Description of problem:
Run "service autofs stop" on a running automount service and observe how
the [  OK  ] turns to [Failed] almost immediately, although the shutdown
succeeds.

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

How reproducible:
Always

Steps to Reproduce:
1. service autofs start
2. service autofs stop
3. Observe the status output of the service script.


Actual Results:  "service autofs stop" prints [  OK  ] and almost
immediately changes it to [FAILED].

Expected Results:  "service autofs stop" should print [  OK  ] only.

Additional info:
I think the problem here is that "automount" forks a child process upon
shutdown which confuses the "stop" code in the "autofs" service script.
After sending a USR2 signal to the single automount process, the script 
checks /sbin/pidof /usr/sbin/automount which returns the daemon's PID plus
a second PID as long as automount has not shutdown yet. This causes the
script to enter a special shutdown loop which fails to terminate automount
which has finished its shutdown code meanwhile.

Comment 1 Jesse Keating 2002-04-19 05:57:19 UTC

Again, do you have to have mountpoints defined for this to work?  I am unable to
reproduce this problem.

Comment 2 Michael Schwendt 2002-04-19 11:42:28 UTC

Yes. Running automount without any mount-points makes no sense.

On Enigma (reproducible on Skipjack-beta2), see description above:

# /etc/auto.master
/home/ftp/pub/mnt/enigma     /etc/auto.enigma  -timeout 600

# /etc/auto.enigma
disc1       -fstype=iso9660,ro,loop :/home/ftp/pub/rh72/iso/enigma-i386-disc1.iso
disc2       -fstype=iso9660,ro,loop :/home/ftp/pub/rh72/iso/enigma-i386-disc2.iso

# the long lines above probably get wrapped by bugzilla (don't know)


# service autofs start
Starting automount:                                        [  OK  ]

The following first reads [  OK  ] and then immediately turns into [FAILED]:

# service autofs stop 
Stopping automount:                                        [FAILED]

Comment 3 Michael Schwendt 2003-01-25 18:42:33 UTC

Original report was about Red Hat Linux 7.2 (Enigma). Reproducible on Phoebe
(8.0.93).

What is written in "Additional info:" is still true.

# service autofs start
Starting automount:                                        [  OK  ]
# pidof /usr/sbin/automount
2279 2255
# service autofs stop
Stopping automount:                                        [FAILED]
# service autofs start
Starting automount:                                        [  OK  ]
# service autofs stop
Stopping automount:                                        [  OK  ]
# service autofs start
Starting automount:                                        [  OK  ]
# service autofs stop
Stopping automount:                                        [FAILED]

Comment 4 Jeff Moyer 2004-03-19 22:56:05 UTC

*** Bug 70707 has been marked as a duplicate of this bug. ***

Comment 5 Jeff Moyer 2004-03-22 15:11:16 UTC

I will push a fix for this into rawhide, once the pool opens up.