파일 시스템에서 여전히 지연된 파일 마운트 해제를 사용하고 있는 프로세스 식별

파일 시스템에서 여전히 지연된 파일 마운트 해제를 사용하고 있는 프로세스 식별

/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.

관련 정보