linux-kernel - umount -f Device or resource busy; already tried: mount, lsof, fuser, exportfs, ps axf, dmsetup table, losetup -a

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <023501cf6329$047a8120$0d6f8360$@nor-consult.com>
Date:	Mon, 28 Apr 2014 14:30:03 -0700
From:	"Michael Evans" <michael.evans@...-consult.com>
To:	<linux-kernel@...r.kernel.org>
Subject: umount -f Device or resource busy; already tried: mount, lsof, fuser, exportfs, ps axf, dmsetup table, losetup -a

I am posting with hope to improve the reliability and usability of
unmounting 'busy' filesystems (for which umount -f doesn't work and no
remedy is known).

There are no apparent resource holders but the device is still 'busy'. (
http://serverfault.com/questions/591406/umount-device-or-resource-busy-alrea
dy-tried-mount-lsof-fuser-exportfs-ps ), including:

* mount | grep /tmp/
* lsof | grep /tmp/
* fuser -m /tmp/...
* exportfs -rv | grep /tmp/
* Restarting the daemon which runs the creation scripts anyway...
* ps axf | grep /tmp/
* dmsetup table
* losetup -a
* fuser -vm /tmp/tmp.random-chars/ (yields two lines)
##                        USER PID    ACCESS COMMAND
## /tmp/tmp.random-chars: root kernel mount  /tmp/tmp.random-chars

Is there /any other/ test which might reveal what is keeping the device busy
(so I can end their existence)?
Is there anything more forceful than 'umount -f' to really just sync what's
possible to a specific device and invalidate all remaining file handles,
buffers, etc?

Failure is always be an option.  However in this case failing to allow
failure would require an entire VM host reboot during the next maintenance
window.

Thank you in advance for your time and ideas.  Please either reply to my
work email address <michael.evans@...-consult.com> or at the above
serverfault link; optionally CC the list for the archives.  I'll also update
the main post on the serverfault page with any additional tests and
highlight any that yield useful information for future search engine users.

PS: Even if your reply is after our next maintenance window, I'll continue
updating the serverfault post with test for future users (more quickly if
directly emailed as well).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/