rmdir 由于“设备或资源忙”而失败 [关闭]答案

【问题标题】：rmdir failed because of "Device or resource busy" [closed]rmdir 由于“设备或资源忙”而失败 [关闭]
【发布时间】：2015-12-02 04:22:59
【问题描述】：

有很多类似的问题，例如“设备或资源繁忙”。但我认为我的问题与他们不同。

我使用 mount --bind 绑定目录

mount --bind /tmp/origin /tmp/mount

然后就可以卸载成功了

umount /tmp/mount

然后如果我立即调用 rm

rm -rf /tmp/mount

我可能会收到错误Device or resource busy。如果我等待2~3秒，然后调用rm，就可以成功了。

所以这种行为在这里很奇怪。我尝试使用

lsof +D /tmp/mount

什么都看不到。

我也用fuser -vm /tmp/mount，看不到任何进程持有这个文件夹。

我比较了umount /tmp/mount 之前和umount /tmp/mount 之后的/proc/mounts。 /tmp/mount 已被删除。

我比较了umount /tmp/mount 之前和umount /tmp/mount 之后的stat /proc/mounts。 inode 也不同，这意味着/tmp/mount 已经删除完成。

即使我打电话给sync && echo 2 > /proc/sys/vm/drop_caches 并尝试删除文件缓存，它仍然不起作用。

我在 Ubuntu 14.04 和 CentOS 6.6 中都尝试过这个。他们有相同的结果。

【问题讨论】：

这是个好问题。我会给它一个赞成票，但它更像是一个通用的计算问题，而不是与编程相关的问题，所以它对于 StackOverflow 来说是题外话。它更适合Unix and Linux 甚至Super User。
谢谢。如何将这个移到那个？ @AnthonyGeoghegan
没问题。如果我是你，我会将此问题的内容复制并粘贴到新问题中，然后删除此版本以避免新问题被标记为交叉帖子。欢迎来到 Stack Exchange！
因为上述命令是在代码中发生的，而不是来自 shell。这个问题的原因与调用克隆进程时的这个参数有关：CLONE_NEWNS。所以我还是把它放在这里。
非常感谢。去吧。

标签： linux filesystems

【解决方案1】：

我遇到了这样的问题，因为我在 VM 中挂载了共享文件夹，我想在卸载后删除目录，我只想分享我的解决方案。

卸载路径
```
sudo umount /your_path
```
删除 /etc/fstab 中的 mout 路径
```
sudo nano /etc/fstab
```
重启
```
sudo reboot
```
删除目录
```
sudo rm -rf /your_path
```

【讨论】：

实际上他可以在 3 秒后删除目录，而无需重新启动，但无论如何感谢您的回答，这可以帮助其他人。
umount /path -l 强制卸载

【解决方案2】：

根据我的经验，以下操作在 Linux 上是异步的：

关闭文件。在close() 返回后，umount() 在执行异步释放时可能会立即返回EBUSY。请参阅此处的讨论：page 1、page 2。
正在卸载文件系统。在所有数据都写入磁盘之前，挂载的设备可能很忙。

即使我打电话给sync && echo 2 > /proc/sys/vm/drop_caches 并尝试删除文件缓存，它仍然不起作用。

见sync(8):

在 Linux 上，sync 只保证调度脏块进行写入；在最终写入所有块之前实际上可能需要很短的时间。 reboot(8) 和 halt(8) 命令通过在调用 sync(2) 后休眠几秒钟来考虑这一点。

至于/proc/sys/vm/drop_caches，见here：

这是非破坏性操作，不会释放任何脏对象。

因此，在您发出命令后，数据可能仍在排队等待写入，而卸载尚未完成。

更新

但是，当异步卸载运行时，内核将返回EBUSY 用于挂载设备上的操作，但不会返回挂载点。

所以上述情况不可能是你的问题的原因：P

附言。

实际上我不明白为什么手册页指出sync(8) 在 Linux 中不是同步的。它调用sync(2) 声明：

根据标准规范（例如，POSIX.1-2001），sync() 安排写入，但可能在实际写入完成之前返回。但是，从 1.3.20 版开始，Linux 确实在等待。（这仍然不能保证数据完整性：现代磁盘具有大缓存。）

【讨论】：

谢谢，让我试着挖掘更多关于这个的细节。
好主意，但没有一个能解决我的问题。看起来像是挂载实现中的一个缺陷

【解决方案3】：

感谢@g-v 的回答。但我发现结果是另一个问题。我们在 fork 进程时使用 CLONE_NEWNS 标志。更多详情请见CLONE_NEWNS flag 和MESOS-3349 Device busy bug

简而言之，我们挂载在父进程中。然后在子进程中umount，因为CLONE_NEWNS，挂载点仍然存在，由父进程处理。所以调用 rmdir 时会得到 EBUSY 错误码。

为了避免上述问题，我们可以使用共享挂载或从属挂载。更多详情请见LWN 159092

【讨论】：

【解决方案4】：

检查
```
df -h
```
然后
```
sudo umount /path
```

【讨论】：

这似乎无法回答问题。

【解决方案5】：

按照以下步骤操作：

打开资源监视器
点击“关联句柄”下拉框
搜索文件夹创建问题
右键单击每个进程并“结束进程”。

现在你可以删除文件夹了

【讨论】：