Bug 866303 - umount -f (and -l) doesn't work, hangs indefinitely on unreachable NFS server.
Summary: umount -f (and -l) doesn't work, hangs indefinitely on unreachable NFS server.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-15 04:45 UTC by David Woodhouse
Modified: 2013-07-01 11:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-11-22 10:58:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


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