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-linux	Assignee:	Karel Zak <kzak>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	18	CC:	horsley1953, jonathan, kzak, mluscon
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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:
Embargoed:

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
 util-linux-2.21.2-2.fc17.x86_64

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

Please, send me output from

 strace -f umount -f /mountpoint

and

 LIBMOUNT_DEBUG=0xffff umount -f /mountpoint

Thanks.

Comment 2 David Woodhouse 2012-10-16 13:23:47 UTC

[root@shinybook ~]# rpm -q util-linux
util-linux-2.22.1-1.fc18.x86_64
[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
stat("/twosheds",

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:

util-linux-2.22.2-6.fc18.x86_64
nfs-utils-1.2.7-6.fc18.x86_64

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.