Bug 65003 - autofs-3.1.7-28 - fs mounted twice, can only umount once
autofs-3.1.7-28 - fs mounted twice, can only umount once
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: autofs (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Brock Organ
:
: 55715 55931 (view as bug list)
Depends On:
Blocks: 107565
  Show dependency treegraph
 
Reported: 2002-05-15 16:30 EDT by James Manning
Modified: 2016-09-30 15:18 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-05 10:05:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
more robust version of /etc/rc.d/init.d/autofs (11.28 KB, text/plain)
2003-02-07 13:06 EST, Adam Spiers
no flags Details
even more robust version of /etc/rc.d/init.d/autofs (10.51 KB, text/plain)
2003-02-21 12:36 EST, Adam Spiers
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 65003 master MERGED tests: Streamline resourceManager import 2016-09-30 15:18 EDT

  None (edit)
Description James Manning 2002-05-15 16:30:46 EDT
Description of Problem:
Looks like if autofs restarts and one of its mounts isn't allowed to umount,
then it'll do a second mount (or appears to) and while this second one is
umountable, the first lingers

Version-Release number of selected component (if applicable):
jmm@jmm /misc/public/oracle_archive> rpm -q autofs kernel
autofs-3.1.7-28
kernel-2.4.18-3

How Reproducible:
100%


Steps to Reproduce:
1. have an autofs'd directory (/misc/mp3 in my case, an NFS mount) used (xmms
was playing from there)
2. restart autofs (will include some error messages)
3. post-restart, directory's still mounted, but current autofs didn't do it
4. next entry into /misc/mp3 (or whatever) gets a second mount
5. on umount attempt, second mount leaves
6. successive umount attempts (even with -f), first mount is still around

Actual Results:
the double-mount with the "first mount" impervious to umount

Expected Results:
ideally, autofs should skip the second mount.  worst-case, both should be umountable

Additional Information:
I'd imagine this was less of an issue for autofs before "supermount" or whatever
it's called was available (heh, thx Al)
Comment 1 James Manning 2002-05-17 16:02:01 EDT
still broken with kernel-2.4.18-4

jmm@jmm /home/jmm> df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2             1.9G  1.8G   67M  97% /
/dev/hda3             1.9G  1.6G  271M  86% /beta
/dev/hda1             9.6G  5.6G  3.6G  61% /home
none                  188M     0  188M   0% /dev/shm
jmm@jmm /home/jmm> cd /misc/mp3
jmm@jmm /misc/mp3> xmms &
[1] 1632
jmm@jmm /misc/mp3> cd
jmm@jmm /home/jmm> sudo service autofs restart
Password:
umount2: Device or resource busy                           [  OK  ]
umount: automount(pid834): not found
umount: /misc: Illegal seek

Starting automount:                                        [  OK  ]
jmm@jmm /home/jmm> df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2             1.9G  1.8G   67M  97% /
/dev/hda3             1.9G  1.6G  271M  86% /beta
/dev/hda1             9.6G  5.6G  3.6G  61% /home
none                  188M     0  188M   0% /dev/shm
booch:/home/wrb/mp3   9.1G  4.7G  4.0G  54% /misc/mp3
jmm@jmm /home/jmm> cd /misc/mp3
jmm@jmm /misc/mp3> df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2             1.9G  1.8G   67M  97% /
/dev/hda3             1.9G  1.6G  271M  86% /beta
/dev/hda1             9.6G  5.6G  3.6G  61% /home
none                  188M     0  188M   0% /dev/shm
booch:/home/wrb/mp3   9.1G  4.7G  4.0G  54% /misc/mp3
booch:/home/wrb/mp3   9.1G  4.7G  4.0G  54% /misc/mp3
jmm@jmm /misc/mp3> cd
jmm@jmm /home/jmm> kill %1
jmm@jmm /home/jmm>
[1]+  Terminated              xmms  (wd: /misc/mp3)
(wd now: ~)
jmm@jmm /home/jmm> sudo umount /misc/mp3
jmm@jmm /home/jmm> df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2             1.9G  1.8G   67M  97% /
/dev/hda3             1.9G  1.6G  271M  86% /beta
/dev/hda1             9.6G  5.6G  3.6G  61% /home
none                  188M     0  188M   0% /dev/shm
booch:/home/wrb/mp3   9.1G  4.7G  4.0G  54% /misc/mp3
jmm@jmm /home/jmm> sudo umount /misc/mp3
jmm@jmm /home/jmm> df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2             1.9G  1.8G   67M  97% /
/dev/hda3             1.9G  1.6G  271M  86% /beta
/dev/hda1             9.6G  5.6G  3.6G  61% /home
none                  188M     0  188M   0% /dev/shm
booch:/home/wrb/mp3   9.1G  4.7G  4.0G  54% /misc/mp3
jmm@jmm /home/jmm> sudo umount -f /misc/mp3
jmm@jmm /home/jmm> df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2             1.9G  1.8G   67M  97% /
/dev/hda3             1.9G  1.6G  271M  86% /beta
/dev/hda1             9.6G  5.6G  3.6G  61% /home
none                  188M     0  188M   0% /dev/shm
booch:/home/wrb/mp3   9.1G  4.7G  4.0G  54% /misc/mp3
Comment 2 James Manning 2002-05-26 12:58:54 EDT
*** Bug 55715 has been marked as a duplicate of this bug. ***
Comment 3 James Manning 2002-05-26 13:00:21 EDT
copying over the cc list
Comment 4 James Manning 2002-08-01 10:44:33 EDT
From: Alan Cox <alan@redhat.com>

I'd say its a bug in autofs, because autofs should have realised the mount
was already there
Comment 5 Adam Spiers 2003-02-07 13:06:31 EST
Created attachment 89931 [details]
more robust version of /etc/rc.d/init.d/autofs

This version of /etc/rc.d/init.d/autofs refuses to shutdown/restart
if there are still directories automounted under the automounter
points.  It also refuses to start if there are automount processes
running, so it should hopefully fix both this bug and bug 55931.

I changed the default stopping order number (rc?.d/Knnautofs) to 80
in the hope that all automounts will have been unmounted by that
stage of shutdown.

I have not (yet) submitted this to the autofs mailing list.
Comment 6 Adam Spiers 2003-02-21 12:36:58 EST
Created attachment 90250 [details]
even more robust version of /etc/rc.d/init.d/autofs

I just noticed that the reload section of the init script is
also guilty of starting new automount processes whether the
old ones died or not.  If you look at the sample init script
in the original autofs source from which this rpm is based,
you'll see it makes no distinction between restart and reload,
nor do I see any reason why it should, given that it is not
possible to signal a running daemon to reload its configuration
files.

Hence I'm attaching a newer version which treats reload like
restart.
Comment 8 Adam Spiers 2004-03-02 07:04:00 EST
Over a year later, and still in the NEW state ...
Comment 9 Jeffrey Moyer 2004-03-19 16:43:17 EST
This is now fixed in rawhide.  The fix will also be available in AS2.1
U5, and RHEL 3 U3.

-Jeff
Comment 10 Jeffrey Moyer 2004-03-19 16:43:48 EST
*** Bug 55931 has been marked as a duplicate of this bug. ***

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