/dev/md127
얼마 전에 설치된 mdadm RAID 0 어레이가 있습니다 /mnt/storage1
. 어느 시점에서 bash 세션을 열고 CWD를 로 변경했는데 /mnt/storage1
bash 세션이 여전히 활성 상태입니다. 그런 다음 어레이를 언로드하고 파괴하기로 결정하여 다음과 같이 했습니다.
/# 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
.