Bug 866303 - umount -f (and -l) doesn't work, hangs indefinitely on unreachable NFS server.
umount -f (and -l) doesn't work, hangs indefinitely on unreachable NFS server.
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Karel Zak
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-10-15 00:45 EDT by David Woodhouse
Modified: 2013-07-01 07:43 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-11-22 05:58:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2012-10-15 00:45:59 EDT
I have a stuck NFS mount; the server is no longer reachable.

I would like to unmount it by using 'umount -f' or perhaps if that doesn't work I could try 'umount -l'. But neither works. It seems that umount(8) is calling stat(2) on the path to be unmounted, before doing so. So it ends up stuck in D state. If it wasn't bloody unreachable, I wouldn't need to use '-f', now would I?
Comment 1 Karel Zak 2012-10-16 06:06:01 EDT
I can reproduce this problem only on f16. The libmount in Fedora 17

 rpm -q util-linux nfs-utils

should be more careful with readlink() and stat().

Please, send me output from

 strace -f umount -f /mountpoint


 LIBMOUNT_DEBUG=0xffff umount -f /mountpoint

Comment 2 David Woodhouse 2012-10-16 09:23:47 EDT
[root@shinybook ~]# rpm -q util-linux
[root@shinybook ~]# LIBMOUNT_DEBUG=0xffff umount -f /twosheds
libmount: debug mask set to 0xffff.
18966: libmount:      CXT: [0x7f204c0f2050]: ----> allocate 
18966: libmount:    UTILS: mtab: /etc/mtab
18966: libmount:    UTILS: /etc/mtab: irregular/non-writable
18966: libmount:    UTILS: utab: /run/mount/utab
18966: libmount:      CXT: [0x7f204c0f2050]: enabling flag 0100
18966: libmount:      CXT: [0x7f204c0f2050]: umount: /twosheds
18966: libmount:      CXT: [0x7f204c0f2050]: umount: lookup FS
Comment 3 David Woodhouse 2012-10-16 09:24:43 EDT
strace ends with...

getegid()                               = 0
prctl(PR_GET_DUMPABLE)                  = 1
lstat("/etc/mtab", {st_mode=S_IFLNK|0777, st_size=12, ...}) = 0
getuid()                                = 0
geteuid()                               = 0
getgid()                                = 0
getegid()                               = 0
prctl(PR_GET_DUMPABLE)                  = 1
stat("/run", {st_mode=S_IFDIR|0755, st_size=1560, ...}) = 0
lstat("/run/mount/utab", {st_mode=S_IFREG|0644, st_size=146, ...}) = 0
open("/run/mount/utab", O_RDWR|O_CREAT, 0644) = 3
close(3)                                = 0
Comment 4 David Woodhouse 2012-10-16 09:27:07 EDT
Fixing distro version; apologies.
Comment 5 Karel Zak 2012-10-16 11:20:37 EDT
(In reply to comment #4)
> Fixing distro version; apologies.

Ah, it should be already fixed in upstream tree, I'll prepare an update for Fedora 18 and ask you for test. Thanks!
Comment 6 Karel Zak 2012-11-22 05:58:16 EST
Ah, I forgot to update this bugzilla, the problem should be already fixed in Fedora 18 (util-linux >= 2.22.1-2).
Comment 7 Tom Horsley 2013-07-01 07:43:53 EDT
Not fixed. I have these rpms on my fedora 18 box:


This morning I found I was timing out incessantly because one of the remote NFS servers was down, so I tried both umount -l and umount -f and all I get is a message about stale NFS file handle (which I $#@! knew already :-) and the umount does not work, the dadgum mount is still there.

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