☰

ファイルシステムでまだ遅延ファイルのマウント解除を使用しているプロセスの識別

tag-icon • tag-icon linux mount mdadm open-files unmounting
ファイルシステムでまだ遅延ファイルのマウント解除を使用しているプロセスの識別

/dev/md127しばらく前にインストールされたmdadm RAID 0アレイがあります/mnt/storage1。ある時点でbashセッションを開き、CWDをに変更しましたが、/mnt/storage1bashセッションはまだアクティブです。その後、アレイをアンロードして破壊することにしました。

/# umount /mnt/storage1
Device or resource busy msg
/# umount -l /mnt/storage1
(Succeeded)
/# rmdir /mnt/storage1
(Succeeded)

/mnt/storage1削除されたことを確認してください。インストール済みとしてマークされてmountいません。/dev/md127それでも私が言及したbashセッションにはまだ/mnt/storage1作業ディレクトリがあります。

/mnt/storage1# _

/dev/md127 配列を停止して破壊しようとすると、次のような結果が返されます。

/# mdadm --stop /dev/md127
mdadm: Cannot get exclusive access to /dev/md127:Perhaps a running process, mounted filesystem or active volume group?

lsof/dev/md127 または /mnt/storage1 にまだ開いているファイルはリストされません。

/# lsof |grep storage1
/# (No results)
/# lsof |grep md127
/# (No results)

私はbashプロセスによって開かれたファイルを一覧表示しようとしましたが、まだディレクトリにありますが、/mnt/storage1成功しませんでした（例えば、3172はbashプロセスの正しいPIDです）。

/# lsof -p 3172
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
bash    3172 root  cwd    DIR   0,40       40      256 /
bash    3172 root  rtd    DIR    9,0     4096        2 /
bash    3172 root  txt    REG    9,0  1037528 10485776 /bin/bash
bash    3172 root  mem    REG    9,0    47600  1310937 /lib/x86_64-linux-gnu/libnss_files-2.23.so
bash    3172 root  mem    REG    9,0    47648  1310851 /lib/x86_64-linux-gnu/libnss_nis-2.23.so
bash    3172 root  mem    REG    9,0    93128  1310763 /lib/x86_64-linux-gnu/libnsl-2.23.so
bash    3172 root  mem    REG    9,0    35688  1310755 /lib/x86_64-linux-gnu/libnss_compat-2.23.so
bash    3172 root  mem    REG    9,0  2981280 16522333 /usr/lib/locale/locale-archive
bash    3172 root  mem    REG    9,0  1864888  1311188 /lib/x86_64-linux-gnu/libc-2.23.so
bash    3172 root  mem    REG    9,0    14608  1311189 /lib/x86_64-linux-gnu/libdl-2.23.so
bash    3172 root  mem    REG    9,0   167240  1311191 /lib/x86_64-linux-gnu/libtinfo.so.5.9
bash    3172 root  mem    REG    9,0   162632  1311181 /lib/x86_64-linux-gnu/ld-2.23.so
bash    3172 root  mem    REG    9,0    26258 16523837 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
bash    3172 root    0u   CHR  136,0      0t0        3 /dev/pts/0
bash    3172 root    1u   CHR  136,0      0t0        3 /dev/pts/0
bash    3172 root    2u   CHR  136,0      0t0        3 /dev/pts/0
bash    3172 root  255u   CHR  136,0      0t0        3 /dev/pts/0

私はbashプロセスのCWDを取得しようとしましたが、これは間違った（？）結果をもたらしました。

/# pwdx 3172
3172: /

また、どのプロセスがアレイを停止できないのかわからないとします。どうやって識別できますか？

この質問は以下に関連しています。https://superuser.com/questions/471327/how-to-force-mdadm-to-stop-raid5-array- この問題は何年も私を悩ませてきましたが、今度はこの問題が発生した場合は正しく解決したいと思います。 Bashセッションはまだ開いており、答えをテストする準備ができています :-)

この質問は、アレイを停止するのではなく、アレイ内のファイルを引き続き使用しているプロセスを識別し、そのファイルが破壊されるのを防ぐ方法についてです。

ベストアンサー1

~によると遅延マウント解除ファイルシステムへの参照の検索このページでは、lsofツールは絶対パスではなくパスをリストしないように見えます（lsofの出力は不規則です）。

/proc/*/maps回避策は、各プロセスに属するメモリマップを表示して、マップの種類とファイルなのかパスなのかを示す場所を調べる必要があります。ただし、同様に、lsofファイルをホストするファイルシステムがゆっくりマウント解除されている場合、絶対パスは使用できません。

提案されたスクリプトは次のとおりです。

!/bin/bash
cat /proc/*/maps 
  | awk '{print $6}'
  | grep -v '^/'         # remove absolute paths
  | grep -v '^$' 
  | grep -v '(deleted)' 
  | grep -v '^.vdso.$' 
  | grep -v '^.heap.$' 
  | grep -v '^.stack.$' 
  | grep -v '^.vsyscall.$' 
  | grep -v '^socket:$'

これは、既知の誤検出を取り除くのに役立ちます。

また、チェックインも/proc/X/fd/*可能です/proc/X/cwd。

おすすめ記事