Description of Problem: umount fails but changes /etc/mtab Version-Release number of selected component (if applicable): mount-2.11m-1 but versions before this too How Reproducible: 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 happen !!! Actual Results: umount fails but alters /etc/mtab the entry for the nfs share will have disappeared Expected Results: /etc/mtab should not have changed Additional Information:
Created attachment 40147 [details] fix
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.