Bug 65003 - autofs-3.1.7-28 - fs mounted twice, can only umount once
Summary: autofs-3.1.7-28 - fs mounted twice, can only umount once
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: autofs
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
: 55715 55931 (view as bug list)
Depends On:
Blocks: 107565
TreeView+ depends on / blocked
 
Reported: 2002-05-15 20:30 UTC by James Manning
Modified: 2016-09-30 19:18 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2006-04-05 14:05:28 UTC


Attachments (Terms of Use)
more robust version of /etc/rc.d/init.d/autofs (11.28 KB, text/plain)
2003-02-07 18:06 UTC, Adam Spiers
no flags Details
even more robust version of /etc/rc.d/init.d/autofs (10.51 KB, text/plain)
2003-02-21 17:36 UTC, 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 19:18 UTC

Description James Manning 2002-05-15 20:30:46 UTC
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 20:02:01 UTC
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 16:58:54 UTC
*** Bug 55715 has been marked as a duplicate of this bug. ***

Comment 3 James Manning 2002-05-26 17:00:21 UTC
copying over the cc list

Comment 4 James Manning 2002-08-01 14:44:33 UTC
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 18:06:31 UTC
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 17:36:58 UTC
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 12:04:00 UTC
Over a year later, and still in the NEW state ...

Comment 9 Jeff Moyer 2004-03-19 21:43:17 UTC
This is now fixed in rawhide.  The fix will also be available in AS2.1
U5, and RHEL 3 U3.

-Jeff

Comment 10 Jeff Moyer 2004-03-19 21:43:48 UTC
*** 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.