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)
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
*** Bug 55715 has been marked as a duplicate of this bug. ***
copying over the cc list
From: Alan Cox <alan> I'd say its a bug in autofs, because autofs should have realised the mount was already there
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.
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.
Over a year later, and still in the NEW state ...
This is now fixed in rawhide. The fix will also be available in AS2.1 U5, and RHEL 3 U3. -Jeff
*** Bug 55931 has been marked as a duplicate of this bug. ***