Bug 149894 - `umount -f` does not appear to actually work
Summary: `umount -f` does not appear to actually work
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: util-linux
Version: 3.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Ben Levenson
URL:
Whiteboard:
: 159013 (view as bug list)
Depends On:
Blocks: 156320 156322
TreeView+ depends on / blocked
 
Reported: 2005-02-28 17:34 UTC by Paul Waterman
Modified: 2007-11-30 22:07 UTC (History)
4 users (show)

Fixed In Version: RHBA-2005-669
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-05 16:50:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Proposed updates to the umount.8 man page (341 bytes, patch)
2005-05-26 22:49 UTC, Paul Waterman
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:626 0 qe-ready SHIPPED_LIVE util-linux and mount bug fix update 2005-09-28 04:00:00 UTC
Red Hat Product Errata RHBA-2005:669 0 qe-ready SHIPPED_LIVE util-linux bug fix update 2005-10-05 04:00:00 UTC

Description Paul Waterman 2005-02-28 17:34:15 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3)
Gecko/20040910

Description of problem:
Running /bin/umount -f [filesystem] SHOULD be able to forcibly unmount
an NFS-mounted filesystem, even if there are open file handles, etc.,
on that filesystem or if the mount is stale due to the remote server
or filesystem no longer being available.

However, the -f option doesn't appear to make any difference. For example:

% umount /mnt/x
umount: /mnt/x: device is busy

% umount -f /mnt/x
umount2: Device or resource busy
umount: /mnt/x: device is busy

I have tested this with various mount options, with NFS exports from
Network Appliance NAS servers as well as other Linux systems, and with
the NFS mount being kept "busy" both via shell simply sitting in the
directory and via a file open on the filesystem -- none of this
appears to make any difference.

Needless to say, the ability to forcibly unmount NFS mounts in large
enterprise configurations is fairly important.

Version-Release number of selected component (if applicable):
mount-2.11y-31.1, mount-2.11y-31.2

How reproducible:
Always

Steps to Reproduce:
1. mount nfsserver:/remote/filesystem /local/mount/point
2. cd /local/mount/point
3. umount -f /local/mount/point
    

Actual Results:  umount2: Device or resource busy
umount: /local/mount/point: device is busy

Expected Results:  /local/mount/point should unmount.

Comment 1 Paul Waterman 2005-03-24 22:16:41 UTC
Turns out that this isn't actually a problem with the umount command as much as
it's a matter of unclear documentation.

The -f (force) option does NOT actually unconditionally force an unmount. It
still requires that the file system be idle -- if the file system is busy, the
umount will fail even with a -f option. The -f option is ONLY useful in the
instance where the NFS server is no longer available and the file system is idle.

The -l (lazy) option is what I was looking for. This actually forces the unmount
regardless of whether or not the file system is busy.

This is extremely likely to trip up people working in a mixed Solaris/Linux
environment or coming from a Solaris background, as the -f (force) option was a
highly touted feature of Solaris 8 and beyond that actually *forces* the unmount
regardless of whether or not the file system is idle.

The umount man page should be updated to make the distinction between -f and -l
more clear.

Comment 2 Paul Waterman 2005-05-26 22:49:37 UTC
Created attachment 114896 [details]
Proposed updates to the umount.8 man page

The following attachment provides diffs for a proposed update to the umount.8
man page. This update will provide further clarification to the -f and -l
umount options, making it clear that the -f option cannot be used to umount
busy filesystems and that the -l option should be used instead for that
purpose.

Comment 3 Joshua Jensen 2005-05-27 17:47:39 UTC
No response for almost 3 months?  This is a good idea... -f vs -l needs to be
better explained.  When can this find it's way into the umount manpage for RHEL3
and REHL4 ?

Comment 4 Karel Zak 2005-05-27 18:59:56 UTC
Don't worry, we read user's comments in bugzilla. We're just selecting things
for next RHEL updates. You will be informed. Thanks.

Comment 7 Paul Waterman 2005-05-31 16:02:54 UTC
I'm curious as to why this has become a private bug...

Comment 11 Karel Zak 2005-07-18 08:18:13 UTC
Moving from "mount" to "util-linux" bugzilla component. The separate mount
package is in AS2.1 only. In RHEL3 we have util-linux.

Comment 12 Karel Zak 2005-07-18 10:20:55 UTC
*** Bug 159013 has been marked as a duplicate of this bug. ***

Comment 13 Paul Waterman 2005-07-18 18:19:13 UTC
Comment #11 is incorrect. In RHEL 3.0, the /bin/mount command is contained in
the mount RPM. This changed to util-linux in RHEL 4.0 (not 3.0). Since this bug
is against RHEL 3.0, the component should remain mount.

% cat /etc/redhat-release; rpm -qf /bin/mount
Red Hat Enterprise Linux WS release 3 (Taroon Update 5)
mount-2.11y-31.6

% cat /etc/redhat-release; rpm -qf /bin/mount
Red Hat Enterprise Linux WS release 4 (Nahant Update 1)
util-linux-2.12a-16.EL4.6

Comment 14 Karel Zak 2005-07-19 05:40:44 UTC
The basic buzilla components are connected with source rpm packages:

$ cat /etc/redhat-release; rpm -q --qf "%{SOURCERPM}\n" mount;
Red Hat Enterprise Linux AS release 3 (Taroon Update 5)
util-linux-2.11y-31.6.src.rpm


Comment 18 Red Hat Bugzilla 2005-09-28 15:52:03 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-626.html


Comment 19 Red Hat Bugzilla 2005-10-05 16:50:30 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-669.html



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