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私の状況には十分ではありません。

カーネルがこのファイルシステムがビジーであると考える理由を理解するにはどうすればよいですか？

私の問題の原因はnfs-kernel-server、ディレクトリのエクスポートであったようです。はnfs-kernel-serverおそらく通常の開いているファイルの背後にあるため、lsofとでリストされませんfuser。

私が停止したとき、nfs-kernel-server私umountはディレクトリをできました。

これまでにすべてのソリューションの例を含むページをここに作成しました：http : //oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

上記のBruceCranのコメントに付け加えると、この問題の私の顕在化の原因は、今は古いループバックマウントでした。私はすでにの出力にチェックしたいfuser -vm <mountpoint>/をlsof +D <mountpoint>、mountそしてcat /proc/mounts、いくつかの古いNFSカーネル・サーバーが実行されたかどうかをチェックし、クォータをオフにし、試みた（しかし、失敗した）A umount -f <mountpoint>とすべてが、最終的に出力をチェックする前に924日の稼働時間を放棄する自分自身を辞任しましたのlosetupと2古い、マウントされていない構成された-しかし、ループバックを見つけます：

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#

Gentooのフォーラムのポストは、潜在的な原因としてスワップファイルを一覧表示します。最近のファイルへのスワップはおそらく非常にまれですが、の出力を確認しても害はありませんcat /proc/swaps。クォータがアンマウントを防ぐことができるかどうかはわかりません—ストローで握りしめていました。

lsofを使用してファイルシステムをクロールする代わりに、開いているファイルの全リストを使用してgrepするだけです。精度は劣りますが、この返品はより高速でなければなりません。それは仕事を終わらせる必要があります。

lsof | grep '/path'

私にとって、問題のプロセスはchrootで実行されているデーモンでした。それはchrootにlsofあり、fuser見つけられなかったからです。

chrootで何かが実行されていると思われる場合はsudo ls -l /proc/*/root | grep chroot、犯人を見つけます（「chroot」をchrootへのパスに置き換えます）。

ファイルを開く

ファイルを開いているプロセスは、通常の原因です。それらを表示する：

lsof +f -- <mountpoint or device>

使用する/dev/<device>よりも利点があります /mountpoint。マウントポイントはの後に消えumount -lます。または、マウントが重なることで隠される場合があります。

fuser使用することもできますが、私の考えでlsofはより有用な出力があります。しかしfuser、ドラマを引き起こしているプロセスを殺すことになると、あなたの人生を続けることができます。

ファイルをリストします<mountpoint>（上記の注意事項を参照）：

fuser -vmM <mountpoint>

ファイルを書き込み用に開いているプロセスのみを対話的に強制終了します。

fuser -vmMkiw <mountpoint>

読み取り専用（mount -o remount,ro <mountpoint>）を再マウントした後、残りのすべてのプロセスを強制終了しても安全です（r）。

fuser -vmMk <mountpoint>

マウントポイント

犯人はカーネルそのものである可能性があります。あなたがしようとしているファイルシステムにマウントされた別のファイルシステムはumount悲嘆を引き起こします。確認する：

mount | grep <mountpoint>/

ループバックマウントの場合は、次の出力も確認してください。

losetup -la

匿名iノード（Linux）

匿名iノードは次の方法で作成できます。

• 一時ファイル（openwith O_TMPFILE）
• inotifyウォッチ
• [eventfd]
• [イベントポール]
• [timerfd]

これらは最もとらえどころのないタイプのポケモンであり、lsofのTYPE列にとして表示されますa_inode（lsofマニュアルページには記載されてい ません）。

には表示されないlsof +f -- /dev/<device>ため、次のことを行う必要があります。

lsof | grep a_inode

匿名iノードを保持しているプロセスの強制終了については、「現在のinotifyウォッチのリスト（パス名、PID）」を参照してください。

フューザーがマウントを開いたままにしているPIDについて報告するには、-mを使用する必要があります

fuser -m /path

ルートファイルシステムが通常読み取り専用である独自のシステムがあります。時折、ファイルをコピーする必要がある場合、読み書き可能に再マウントされます。

mount -oremount,rw /

そして、再びマウントし直しました：

mount -oremount,ro /

しかし、今回はエラーmountを出し続けmount: / is busyました。これは、ファイルシステムが読み書き可能であるときに実行されたコマンドによって置き換えられたファイルへのオープン記述子を保持しているプロセスが原因でした。lsof -- /出力の重要な行はたまたま（名前が変更されています）：

replicate  1719 admin DEL REG 8,5  204394 /opt/gns/lib/replicate/modules/md_es.so

DEL出力に注目してください。削除されたファイルを保持しているプロセスを再起動するだけで問題は解決しました。

lsofそしてfuser私にも何もくれなかった。

すべての可能なディレクトリの名前を.oldに変更し、変更を加えるたびにシステムをリブートするプロセスの後、責任のある特定のディレクトリ（postfixに関連する）を見つけました。

それは私がからシンボリックリンクを作っかつていたことが判明/var/spool/postfixする/disk2/pers/mail/postfix/varspoolディスクはSDCARDベースのルートファイルシステム（Sheevaプラグ）に書き込みを最小限にするために。

このシンボリックリンクであっても停止した後postfixとdovecot（両方のサービスをps auxだけでなく、netstat -tuanp関連する何かを示さなかった）私がすることができませんでしたunmount /disk2/pers。

シンボリックリンクを削除し、新しいdirを直接指すようにconfigファイルを更新するpostfixと、サービスとディレクトリを正常に停止できました。dovecot/disk2/pers/unmount

次回は、次の出力をさらに詳しく見ていきます。

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

上記のコマンドは、ディレクトリツリー（ここではから始まる/var）内のすべてのシンボリックリンクを再帰的にリストし、特定のターゲットマウントポイント（ここではdisk2）を指す名前を除外します。

私はこの問題を抱えていて、知らないバックグラウンドでアクティブなスクリーンセッションがあったことが判明しました。私は他のアクティブなスクリーンセッションに接続しましたが、そのシェルは現在マウントされたディレクトリにさえありませんでした。これらの他のシェルセッションを削除すると、問題が修正されました。

私は自分の解像度を共有すると思った。

今日、問題はオープンソケット（特にtmux）です。

mount /mnt/disk
export TMPDIR=/mnt/disk
tmux
<<detatch>>
umount /mnt/disk
umount: /mnt/disk: device is busy.
lsof | grep /mnt/disk
tmux      20885             root    6u     unix 0xffff880022346300        0t0    3215201 /mnt/disk/tmux-0/default

私はいくつ持っているbindとoverlay私をブロックした私のマウントの下にマウントを、あなたはアンマウントしたいマウントポイント用のタブ補完を確認してください。私はそれが特にオーバーレイマウントだったと思うが、バインドもできた

これは答えよりも回避策ですが、誰かに役立つかもしれない場合に備えて投稿しています。

私の場合、/ varパーティションを大きくしたいので、LVMを変更しようとしていたので、アンマウントする必要がありました。この投稿でコメントと回答をすべて試してみました（全員に感謝し、特に@ ole-tangeがそれらを収集してくれたことに感謝します）。

私の場合、順序が関連している場合のために、0ランレベルで指定された順序でほとんどのプロセスを強制終了しましたが、それも助けにはなりませんでした。そのため、私はカスタムランレベル（chkconfigの出力を新しいchkconfig --levelコマンドに結合）を作成し、1（シングルユーザーモード）に非常に似ていますが、ネットワーク機能（sshネットワークとxinetを使用）を作成しました。

私はredhatを使用していたので、ランレベル4は「未使用/ユーザー定義」としてマークされているので、それを使用して実行します init 4 。私の場合は、いずれにせよサーバーを再起動する必要があるので大丈夫でしたが、おそらくそうなるでしょうディスクを微調整する人の。