Linux:哪个进程导致“设备繁忙” 当进行umount时?

发布于 2024-07-14 21:27:22 字数 1552 浏览 6 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(12

蓝海 2024-07-21 21:27:22

查看 lsof 命令(列出打开的文件)——它可以告诉您哪些进程是保持打开的状态。 有时这很棘手,但通常就像 sudo lsof | 一样简单。 grep(此处为您的设备名称) 可以为您做到这一点。

Look at the lsof command (list open files) -- it can tell you which processes are holding what open. Sometimes it's tricky but often something as simple as sudo lsof | grep (your device name here) could do it for you.

不美如何 2024-07-21 21:27:22

以防万一...有时会发生您从终端调用 umount 的情况,并且您当前的目录属于已安装的文件系统。

Just in case... sometimes happens that you are calling umount from the terminal, and your current directory belongs to the mounted filesystem.

忱杏 2024-07-21 21:27:22

您应该使用 fuser 命令。

例如。 fuser /dev/cdrom 将使用 /dev/cdrom 返回进程的 pid。

如果您尝试卸载,可以使用 -k 开关终止这些进程(请参阅 man fusionr)。

You should use the fuser command.

Eg. fuser /dev/cdrom will return the pid(s) of the process using /dev/cdrom.

If you are trying to unmount, you can kill theses process using the -k switch (see man fuser).

寄人书 2024-07-21 21:27:22

使用“losetup -a”检查映射到文件系统上的文件的开环设备。 他们不会与 lsof 或 fusion 一起出现。

Check for open loop devices mapped to a file on the filesystem with "losetup -a". They wont show up with either lsof or fuser.

情仇皆在手 2024-07-21 21:27:22

另请检查 /etc/exports。 如果您通过 NFS 导出挂载点内的路径,则在尝试卸载时会出现此错误,并且 fuserlsof 中不会显示任何内容。

Also check /etc/exports. If you are exporting paths within the mountpoint via NFS, it will give this error when trying to unmount and nothing will show up in fuser or lsof.

水溶 2024-07-21 21:27:22
lsof +f -- /mountpoint

(如列出使用挂载在 /mountpoint 的挂载上的文件的进程。对于查找哪些进程正在使用挂载的 USB 记忆棒或 CD/DVD 特别有用。

lsof +f -- /mountpoint

(as lists the processes using files on the mount mounted at /mountpoint. Particularly useful for finding which process(es) are using a mounted USB stick or CD/DVD.

定格我的天空 2024-07-21 21:27:22

lsof 和 fusionr 确实是查找使某个文件保持打开状态的进程的两种方法。
如果您只想成功卸载,则应该研究其 -f 和 -l 选项。

lsof and fuser are indeed two ways to find the process that keeps a certain file open.
If you just want umount to succeed, you should investigate its -f and -l options.

汹涌人海 2024-07-21 21:27:22

打开文件

打开文件的进程是常见的罪魁祸首。 显示它们:

lsof +f -- <mountpoint or device>

使用 /dev/ 而不是 /mountpoint 有一个优点:挂载点将在 umount -l 后消失>,或者它可能被覆盖的安装座隐藏。

也可以使用 fuser,但在我看来,lsof 有一个更有用的输出。 然而,fuser 在杀死导致戏剧性事件的进程时非常有用,这样您就可以继续生活。

列出 上的文件(请参阅上面的警告):

fuser -vmM <mountpoint>

仅以交互方式杀死打开文件以进行写入的进程:

fuser -vmMkiw <mountpoint>

以只读方式重新挂载后 (mount -o remount,ro< /code>),杀死所有剩余进程是安全的(r):

fuser -vmMk <mountpoint>

安装点

罪魁祸首可能是内核本身。 在您尝试umount的文件系统上安装的另一个文件系统将导致灾难。 检查:

mount | grep <mountpoint>/

对于环回挂载,还要检查以下输出:

losetup -la

匿名 inode (Linux)

匿名 inodes 可以通过以下方式创建:

  • 临时文件(使用 O_TMPFILE 打开)
  • inotify watch
  • [eventfd]
  • [eventpoll]
  • [timerfd]

这些是最难以捉摸的神奇宝贝类型,并以 a_inode 的形式出现在 lsofTYPE 列中(在 lsof 手册页中没有记录< /a>)。

它们不会出现在 lsof +f -- /dev/中,因此您需要:

lsof | grep a_inode

要终止持有匿名 inode 的进程,请参阅:列出当前的inotify监视(路径名,PID)

Open files

Processes with open files are the usual culprits. Display them:

lsof +f -- <mountpoint or device>

There is an advantage to using /dev/<device> rather than /mountpoint: a mountpoint will disappear after an umount -l, or it may be hidden by an overlaid mount.

fuser can also be used, but to my mind lsof has a more useful output. However fuser is useful when it comes to killing the processes causing your dramas so you can get on with your life.

List files on <mountpoint> (see caveat above):

fuser -vmM <mountpoint>

Interactively kill only processes with files open for writing:

fuser -vmMkiw <mountpoint>

After remounting read-only (mount -o remount,ro <mountpoint>), it is safe(r) to kill all remaining processes:

fuser -vmMk <mountpoint>

Mountpoints

The culprit can be the kernel itself. Another filesystem mounted on the filesystem you are trying to umount will cause grief. Check with:

mount | grep <mountpoint>/

For loopback mounts, also check the output of:

losetup -la

Anonymous inodes (Linux)

Anonymous inodes can be created by:

  • Temporary files (open with O_TMPFILE)
  • inotify watches
  • [eventfd]
  • [eventpoll]
  • [timerfd]

These are the most elusive type of pokemon, and appear in lsof's TYPE column as a_inode (which is undocumented in the lsof man page).

They won't appear in lsof +f -- /dev/<device>, so you'll need to:

lsof | grep a_inode

For killing processes holding anonymous inodes, see: List current inotify watches (pathname, PID).

半世蒼涼 2024-07-21 21:27:22

这正是“fuser -m /mount/point”存在的原因。

顺便说一句,我不认为“fuser”或“lsof”会指示内核模块何时持有资源,尽管我通常不会遇到这个问题。

That's exactly why the "fuser -m /mount/point" exists.

BTW, I don't think "fuser" or "lsof" will indicate when a resource is held by kernel module, although I don't usually have that issue..

空‖城人不在 2024-07-21 21:27:22

如果在停止所有打开文件的服务和进程后仍然无法卸载或重新安装设备,则可能存在交换文件或交换分区使您的设备处于繁忙状态。 这不会用 fuserlsof 显示。 关闭交换:

sudo swapoff -a

您可以使用以下命令提前检查并显示任何交换分区或交换文件的摘要:

swapon -s

或者:

cat /proc/swaps

作为使用命令 sudo swapoff -a 的替代方法,您也可以禁用通过停止服务或 systemd 单元来进行交换。 例如:

sudo systemctl stop dphys-swapfile

或者:

sudo systemctl stop var-swap.swap

在我的例子中,除了停止任何打开文件进行写入的服务和进程之外,还需要关闭交换,以便我可以将我的根分区重新挂载为只读以便运行fsck 在我的根分区上,无需重新启动。 这对于运行 Raspbian Jessie 的 Raspberry Pi 是必要的。

If you still can not unmount or remount your device after stopping all services and processes with open files, then there may be a swap file or swap partition keeping your device busy. This will not show up with fuser or lsof. Turn off swapping with:

sudo swapoff -a

You could check beforehand and show a summary of any swap partitions or swap files with:

swapon -s

or:

cat /proc/swaps

As an alternative to using the command sudo swapoff -a, you might also be able to disable the swap by stopping a service or systemd unit. For example:

sudo systemctl stop dphys-swapfile

or:

sudo systemctl stop var-swap.swap

In my case, turning off swap was necessary, in addition to stopping any services and processes with files open for writing, so that I could remount my root partition as read only in order to run fsck on my root partition without rebooting. This was necessary on a Raspberry Pi running Raspbian Jessie.

情深缘浅 2024-07-21 21:27:22

lsof 和 fusioner 也没有给我任何东西。

在将所有可能的目录重命名为 .old 并每次进行更改后重新启动系统之后,我发现了一个负责的特定目录(与 postfix 相关)。

事实证明,我曾经创建了一个从 /var/spool/postfix 到 /disk2/pers/mail/postfix/varspool 的符号链接,以便最大限度地减少基于 SDCARD 的根文件系统(Sheeva Plug)上的磁盘写入。

有了这个符号链接,即使停止 postfix 和 dovecot 服务(ps aux 和 netstat -tuanp 都没有显示任何相关内容),我也无法卸载 /disk2/pers。

当我删除符号链接并更新 postfix 和 dovecot 配置文件以直接指向 /disk2/pers/ 上的新目录时,我能够成功停止服务并卸载目录。

下次我将更仔细地查看以下输出:

ls -lR /var | grep ^l | grep disk2

上面的命令将递归地列出目录树中的所有符号链接(此处从 /var 开始),并过滤掉那些指向特定目标安装点(此处为 disk2)的名称。

lsof and fuser didn't give me anything either.

After a process of renaming all possible directories to .old and rebooting the system every time after I made changes I found one particular directory (relating to postfix) that was responsible.

It turned out that I had once made a symlink from /var/spool/postfix to /disk2/pers/mail/postfix/varspool in order to minimise disk writes on an SDCARD-based root filesystem (Sheeva Plug).

With this symlink, even after stopping the postfix and dovecot services (both ps aux as well as netstat -tuanp didn't show anything related) I was not able to unmount /disk2/pers.

When I removed the symlink and updated the postfix and dovecot config files to point directly to the new dirs on /disk2/pers/ I was able to successfully stop the services and unmount the directory.

Next time I will look more closely at the output of:

ls -lR /var | grep ^l | grep disk2

The above command will recursively list all symbolic links in a directory tree (here starting at /var) and filter out those names that point to a specific target mount point (here disk2).

剩余の解释 2024-07-21 21:27:22

除了正在使用的任何文件之外,您尝试卸载的文件系统上挂载的文件系统也可能会导致目标正忙错误。 (例如,当您 mount -o bind /dev /mnt/yourmount/dev 以便在那里使用 chroot 时。)

要查找文件系统上安装了哪些文件系统,请运行以下内容:

<代码>安装| grep '/mnt/yourmount'

要查找哪些文件正在使用,请参考其他人在此建议的建议:

lsof | grep '/mnt/yourmount'

Filesystems mounted on the filesystem you're trying to unmount can cause the target is busy error in addition to any files that are in use. (For example when you mount -o bind /dev /mnt/yourmount/dev in order to use chroot there.)

To find which file systems are mounted on the filesystem run the following:

mount | grep '/mnt/yourmount'

To find which files are in use the advice already suggested by others here:

lsof | grep '/mnt/yourmount'

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文