ディレクトリをアンマウントするときに問題がよく発生します。
umount /mnt/dir umount:/ mnt/dir:デバイスがビジーです
デバイスがビジーである理由はたくさんあります。開いているロックがあるプロセスが実行されていることもあれば、/mnt/dir
の上に他のディレクトリがマウントされていることもあります。
私の質問:
ディレクトリをアンマウントできなかった理由を確認する手順は何ですか。
理由はたくさんありますが、具体的な解決策を説明してもかまいません。
[編集]
[X]マウントされたボリュームで実行中のプロセス。
[X]アンマウントするボリュームの上に別のボリュームがマウントされています
[_] NFSはアンマウントするボリュームをロックします
確認する方法はfuser -vm /mnt/dir
であり、rootとして実行する必要があります。マウントポイントにアクセスしているプロセスがわかります。
別の方法はlsof /mnt/dir
で、マウント上で開いている各ファイルを表示します。再びルートとして実行するのが最善です。
これらのいずれかを非rootとして実行できますが、出力はプロセスに限定されます。他のユーザーからの1つは、ファイルシステムのアンマウントを妨げますが、黙って表示されません。
例:
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
には、マウントを使用して各プロセスにシグナル(デフォルト:SIGKILL
)を送信する-k
オプションがあります。これは、マウントがビジー状態になるのを防ぐためのかなり強力な方法です。 (そしてもちろん、あなたがSIGKILL
に注意してください!)
umount
には、遅延アンマウントを実行する-l
オプションがあります。マウントはファイルシステムのネームスペースから削除されます(例では/mnt/Zia/src
の下には表示されなくなります)がマウントされたままなので、マウントにアクセスするプログラムは引き続きマウントできます。これにアクセスする最後のプログラムが終了すると、実際にマウント解除が行われます。
アンマウント失敗の最後の修正可能な原因が1つあり、それはNFSサーバーがダウンしていることです。ここではumount -f
を使用できますが、使用するとデータが失われるおそれがあります。 (クライアントは、サーバーによってまだ確認されていない書き込みをキャッシュした可能性があり、それらの書き込みは破棄されます。ただし、アプリは書き込みが成功したことをすでに通知されています。)
あなたは使うべきです:
Sudo umount -l <path>
manページ から:
-l, --lazy
怠惰なアンマウント。ここでファイル階層からファイルシステムを切り離し、ビジー状態でなくなったらすぐにこのファイルシステムへのすべての参照をクリーンアップします。
ネットワークファイルシステムまたはサブマウントを持つローカルファイルシステムにこのオプションを使用する場合、近い将来にシステムの再起動が予想されます。
umount -l
の推奨ユースケースは、サーバーまたはネットワークパーティションのダウンにより通常のumountがハングする、到達できないネットワーク共有が原因でシャットダウン時にハングするのを防ぐことです。共有の再マウントはできません。
アンマウントしたいボリュームの上に別のボリュームがマウントされています:
mount
コマンドを使用すると、引数やオプションなしで呼び出された場合、マウントされたすべてのボリュームを知ることができます(-v
を除く)。 Perlを少し追加すると、アクティブなマウントポイントのリストを取得できます。
mount | Perl -pe 's/.*on (\S+) type.*/\1/'
次に、アンマウントしたいmointpointをgrepするだけで、マウントされたファイルシステムがマウントされているかどうかがわかります。
mount | Perl -pe 's/.*on (\S+) type.*/\1/' | grep '/mnt/dir/'
次に、2つのsolutionsがあります。ファイルシステムをアンマウントするか、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ノード は次の方法で作成できます。
open
with O_TMPFILE
)これらは最もわかりにくいタイプのポケモンであり、lsof
のTYPE
列にはa_inode
として表示されます( lsof
manページ )。
これらはlsof +f -- /dev/<device>
には表示されないため、以下を行う必要があります。
lsof | grep a_inode
匿名のiノードを保持しているプロセスの強制終了については、 現在のinotify監視(パス名、PID) の一覧を参照してください。
私にとっての問題は、(sshを介して)2回以上ログインし、ログインの1つでコマンドプロンプトを使用していて、pwdがマウントポイントに従属するフォルダー内にあることでした。
アンマウントしようとしているディレクトリにNFSがアクセスしているかどうかを確認する方法についての質問には、まだ回答がありません。
私が持っているのはこれだけです:
Nfsdが実行されているかどうかを確認します。
pidof nfsd
クライアントによってマウントされたディレクトリを表示します。
showmount -a
およびshowmount
w/o引数は、オフラインでもクライアントホストのみを表示します。これはNFSの特別な動作だと思います。