Bug 866303

Summary: umount -f (and -l) doesn't work, hangs indefinitely on unreachable NFS server.
Product: [Fedora] Fedora Reporter: David Woodhouse <dwmw2>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: horsley1953, jonathan, kzak, mluscon
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-22 10:58:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description David Woodhouse 2012-10-15 04:45:59 UTC
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 10:06:01 UTC
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 13:23:47 UTC
[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 13:24:43 UTC
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 13:27:07 UTC
Fixing distro version; apologies.

Comment 5 Karel Zak 2012-10-16 15:20:37 UTC
(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 10:58:16 UTC
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 11:43:53 UTC
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.