Red Hat Bugzilla – Bug 57286
umount changes /etc/mtab in case of a failure
Last modified: 2007-04-18 12:38:37 EDT
Description of Problem:
umount fails but changes /etc/mtab
Version-Release number of selected component (if applicable):
but versions before this too
umount -f -a -t nfs 2>/dev/null
Steps to Reproduce:
1. Mount a nfs share
2. Now use a file on this share on keep on using it.
This will make the kernel syscall fail with EBUSY.
3. try to umount with 'umount -f -a -t nfs 2>/dev/null'
don't forget 2>/dev/null it's needed for the failure to
umount fails but alters /etc/mtab
the entry for the nfs share will have disappeared
/etc/mtab should not have changed
Created attachment 40147 [details]
I can also confirm this problem with mount-2.11g-5.
This also happens when mount is run from initlog, which happens in the
initscripts. Therefore it is not a rarely occuring bug.
As a consequence the "netfs stop" script does not work correctly and leaves NFS
mounts alive when a process is using the mount. The first umount attempt will
erroneously delete the mount entry from /etc/mtab (without having umounted the
fs since it's busy), then the script goes on killing the problematic process,
and the successive "mount -f -a -t nfs" calls will do nothing since no NFS entry
appears in /etc/mtab any longer, leaving the NFS mount alive.
This is serious since, because of this bug, the "netfs stop" script will leave
"hidden" NFS mounts lurking. By "hidden" I mean that mount will not show them,
but they appear in /proc/mounts.
I'm using RedHat 7.2 on a laptop and this is biting me very often (since apm
suspend runs netfs stop). I would appreciate very much if it got fixed and a new
RPM got released for 7.2 and all other versions suffering from this.
Thanks in advance.
Created attachment 66564 [details]
Improved, less intrusive fix (against mount-2.11g-5).
This fix appears to be in util-linux-2.11y, so the latest dist release should be fine. I don't
plan on releasing a 7.x erratum with the fix.
Apologies for the loooong delay.