This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(12)
查看 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.以防万一...有时会发生您从终端调用 umount 的情况,并且您当前的目录属于已安装的文件系统。
Just in case... sometimes happens that you are calling umount from the terminal, and your current directory belongs to the mounted filesystem.
您应该使用 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 (seeman fuser
).使用“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.
另请检查
/etc/exports
。 如果您通过 NFS 导出挂载点内的路径,则在尝试卸载时会出现此错误,并且fuser
或lsof
中不会显示任何内容。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 infuser
orlsof
.(如列出使用挂载在 /mountpoint 的挂载上的文件的进程。对于查找哪些进程正在使用挂载的 USB 记忆棒或 CD/DVD 特别有用。
(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.
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.
打开文件
打开文件的进程是常见的罪魁祸首。 显示它们:
使用
/dev/
而不是/mountpoint
有一个优点:挂载点将在umount -l
后消失>,或者它可能被覆盖的安装座隐藏。也可以使用
fuser
,但在我看来,lsof
有一个更有用的输出。 然而,fuser
在杀死导致戏剧性事件的进程时非常有用,这样您就可以继续生活。列出
上的文件(请参阅上面的警告):仅以交互方式杀死打开文件以进行写入的进程:
以只读方式重新挂载后 (
mount -o remount,ro< /code>),杀死所有剩余进程是安全的(r):
安装点
罪魁祸首可能是内核本身。 在您尝试
umount
的文件系统上安装的另一个文件系统将导致灾难。 检查:对于环回挂载,还要检查以下输出:
匿名 inode (Linux)
匿名 inodes 可以通过以下方式创建:
O_TMPFILE
打开)这些是最难以捉摸的神奇宝贝类型,并以
a_inode
的形式出现在lsof
的TYPE
列中(在lsof
手册页中没有记录< /a>)。它们不会出现在 lsof +f -- /dev/中,因此您需要:
要终止持有匿名 inode 的进程,请参阅:列出当前的inotify监视(路径名,PID)。
Open files
Processes with open files are the usual culprits. Display them:
There is an advantage to using
/dev/<device>
rather than/mountpoint
: a mountpoint will disappear after anumount -l
, or it may be hidden by an overlaid mount.fuser
can also be used, but to my mindlsof
has a more useful output. Howeverfuser
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):Interactively kill only processes with files open for writing:
After remounting read-only (
mount -o remount,ro <mountpoint>
), it is safe(r) to kill all remaining processes:Mountpoints
The culprit can be the kernel itself. Another filesystem mounted on the filesystem you are trying to
umount
will cause grief. Check with:For loopback mounts, also check the output of:
Anonymous inodes (Linux)
Anonymous inodes can be created by:
open
withO_TMPFILE
)These are the most elusive type of pokemon, and appear in
lsof
'sTYPE
column asa_inode
(which is undocumented in thelsof
man page).They won't appear in
lsof +f -- /dev/<device>
, so you'll need to:For killing processes holding anonymous inodes, see: List current inotify watches (pathname, PID).
这正是“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..
如果在停止所有打开文件的服务和进程后仍然无法卸载或重新安装设备,则可能存在交换文件或交换分区使您的设备处于繁忙状态。 这不会用
fuser
或lsof
显示。 关闭交换:您可以使用以下命令提前检查并显示任何交换分区或交换文件的摘要:
或者:
作为使用命令 sudo swapoff -a 的替代方法,您也可以禁用通过停止服务或 systemd 单元来进行交换。 例如:
或者:
在我的例子中,除了停止任何打开文件进行写入的服务和进程之外,还需要关闭交换,以便我可以将我的根分区重新挂载为只读以便运行
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
orlsof
. Turn off swapping with:You could check beforehand and show a summary of any swap partitions or swap files with:
or:
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:or:
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.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/ 上的新目录时,我能够成功停止服务并卸载目录。
下次我将更仔细地查看以下输出:
上面的命令将递归地列出目录树中的所有符号链接(此处从 /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:
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).
除了正在使用的任何文件之外,您尝试卸载的文件系统上挂载的文件系统也可能会导致
目标正忙
错误。 (例如,当您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 youmount -o bind /dev /mnt/yourmount/dev
in order to usechroot
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'