☰

umount：设备正忙。为什么？

tag-icon • tag-icon mount
umount：设备正忙。为什么？

运行时umount /path我得到：

umount: /path: device is busy.

文件系统很大，所以lsof +D /path不是一个现实的选择。

lsof /path、lsof +f -- /path、 且fuser /path均不返回任何内容。fuser -v /path给出：

                  USER        PID ACCESS COMMAND
/path:            root     kernel mount /path

这对于所有未使用的已安装文件系统来说是正常的。

umount -l并且umount -f对于我的情况来说还不够好。

我如何找出内核认为该文件系统繁忙的原因？

答案1

我的问题的原因似乎是nfs-kernel-server导出目录。可能nfs-kernel-server位于正常打开的文件后面，因此未由lsof和列出fuser。

当我停止时，nfs-kernel-server我可以查看umount目录。

我已经制作了一个页面，其中包含迄今为止所有解决方案的示例：http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

答案2

要添加到布鲁斯·克兰的评论上面，我刚才出现这个问题的原因是陈旧环回安装。我已经检查了fuser -vm <mountpoint>/的输出lsof +D <mountpoint>，mount并且cat /proc/mounts检查了某些旧的 nfs-kernel-server 是否正在运行，关闭了配额，尝试了（但失败了）aumount -f <mountpoint>以及在最终检查输出之前放弃了 924 天的正常运行时间并losetup找到两个陈旧的已配置但未安装的环回：

parsley:/mnt# cat /proc/mounts 
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/mapper/stuff-root / ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
/dev/dm-2 /mnt/big ext3 rw,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user 0 0

然后

parsley:/mnt# fuser -vm /mnt/big/
parsley:/mnt# lsof +D big
parsley:/mnt# umount -f /mnt/big/
umount2: Device or resource busy
umount: /mnt/big: device is busy
umount2: Device or resource busy
umount: /mnt/big: device is busy

parsley:/mnt# losetup -a    
/dev/loop0: [fd02]:59 (/mnt/big/dot-dropbox.ext2)
/dev/loop1: [fd02]:59 (/mnt/big/dot-dropbox.ext2)

parsley:/mnt# losetup -d /dev/loop0
parsley:/mnt# losetup -d /dev/loop1
parsley:/mnt# losetup -a
parsley:/mnt# umount big/
parsley:/mnt#

AGentoo 论坛帖子还将交换文件列为潜在的罪魁祸首；尽管现在交换到文件的情况可能相当罕见，但检查cat /proc/swaps.我不确定配额是否可以阻止卸载——我抓住了救命稻草。

答案3

无需使用 lsof 来爬行文件系统，只需使用打开文件的总列表并 grep 即可。我发现这个返回速度必须更快，尽管它不太准确。它应该完成工作。

lsof | grep '/path'

答案4

对我来说，有问题的进程是在 chroot 中运行的守护进程。因为它在 chroot 中，lsof找不到fuser它。

如果您怀疑 chroot 中还有某些东西正在运行，sudo ls -l /proc/*/root | grep chroot则会找到罪魁祸首（将“chroot”替换为 chroot 的路径）。

相关内容