Umountのデバイスがビジーです

ディレクトリをアンマウントするときに問題が発生することがよくあります。

umount / mnt / dir
umount：/ mnt / dir：デバイスはビジーです

デバイスがビジーである理由は多数あります。開いているロックがあるプロセスが実行されていることもあれば、の上に他のディレクトリがマウントされていることもあります/mnt/dir。

私の質問：

ディレクトリをアンマウントできなかった理由を確認する手順は何ですか？

多くの理由があることは知っていますが、特定の解決策を説明しても大丈夫です。

[編集]

[X]マウントされたボリューム上で実行中のプロセス。
[X]アンマウントするボリュームの上に別のボリュームがマウントされ
ます[_] アンマウントするボリュームをNFSロックします

チェックする方法はでfuser -vm /mnt/dir、これはルートとして実行する必要があります。どのプロセスがマウントポイントにアクセスしているかがわかります。

別の方法lsof /mnt/dirとして、マウント上で開いている各ファイルを表示します。再びルートとして実行するのが最適です。

これらのいずれかを非ルートとして実行できますが、出力はプロセスに限定されます。他のユーザーからのファイルは、ファイルシステムのアンマウントができなくても静かに表示されません。

例：

Watt:~# fuser -vm /mnt/Zia/src
                     USER        PID ACCESS COMMAND
/mnt/Zia/src:        root     kernel mount /mnt/Zia/src
                     anthony   24909 ..c.. bash
                     anthony   25041 F.c.. gvim

「アクセス」フィールドは、そのアクセス方法を示します。この場合、カーネルはそれをマウントとして使用しています（しかし、これだけでアンマウントは可能です）。bashこれを現在の作業ディレクトリとして（cdアンマウントする前に別のディレクトリに移動する必要があります）、gvimは現在のディレクトリとファイルを開いています（そのgvimを閉じる必要があります）。

Watt:~# lsof /mnt/Zia/src
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
bash    24909 anthony  cwd    DIR   0,26    12288 3527682 /mnt/Zia/src/perl (zia.vpn.home:/home/anthony/src)
gvim    25041 anthony  cwd    DIR   0,26    12288 3527682 /mnt/Zia/src/perl (zia.vpn.home:/home/anthony/src)
gvim    25041 anthony    6u   REG   0,26    16384 3526219 /mnt/Zia/src/perl/.utf8.c.swp (zia.vpn.home:/home/anthony/src)

この出力では、bashとgvim（タイプとしてDIR）の両方の現在のディレクトリを確認できます。gvimが書き込み用に開いているファイルも確認できます。

問題を強制する方法：

fuserマウントを使用して各プロセスに-kシグナル（デフォルト：）を送信するオプションがありますSIGKILL。これは、マウントがビジー状態にならないようにするかなり強力な方法です。（そしてもちろん、あなたは何に注意してくださいSIGKILL！）

umount-l遅延アンマウントを実行するオプションがあります。マウントはファイルシステムの名前空間から削除されます（したがって/mnt/Zia/src、この例では表示されなくなります）が、マウントされたままなので、それにアクセスするプログラムは引き続き実行できます。最後にアクセスするプログラムが終了すると、実際にアンマウントが行われます。

アンマウントに失敗する最後の修正可能な原因が1つあり、それはNFSサーバーのダウンです。ここではを使用できますが、使用するumount -fとデータ損失のリスクがあります。（クライアントは、サーバーによってまだ確認されていない書き込みをキャッシュしている可能性があり、それらの書き込みは破棄されます。ただし、アプリは書き込みが成功したことを既に通知されています。）

以下を使用する必要があります。

sudo umount -l <path>

別のボリュームが、マウント解除するボリュームの上にマウントされます。

このmountコマンドを使用すると、引数やオプションなしで呼び出された場合に、マウントされているすべてのボリュームがわかります（を除く-v）。perlを少し追加することで、アクティブなマウントポイントのリストを作成できます。

mount | perl -pe 's/.*on (\S+) type.*/\1/'

次に、アンマウントしたいポイントからgrepを実行するだけで、この上にファイルシステムがマウントされているかどうかがわかります。

mount | perl -pe 's/.*on (\S+) type.*/\1/' | grep '/mnt/dir/'

次に、2つのソリューションがあります。ファイルシステムをアンマウントするか、mount --move olddir newdir（カーネル> 2.5.1）で移動します

ファイルを開く

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

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（lsofmanページには記載されていません）と表示され ます。

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

lsof | grep a_inode

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

NFSがマウント解除しようとしているディレクトリにアクセスするかどうかを確認する方法についての質問にはまだ答えがありません。

私が持っているのはこれだけです：

nfsdが実行されているかどうかを確認します。

pidof nfsd

クライアントごとにマウントされたディレクトリを表示します。

showmount -a

そしてshowmount、彼らがオフラインであっても、引数ショーのみクライアントホストOワット/。これはNFSの特別な動作だと思います。

私にとっての問題は、（sshを介して）複数回ログインし、ログインの1つで、マウントポイントに従属するフォルダー内にpwdがあるコマンドプロンプトにいたことです。