☰

프로세스가 파일 시스템에 없는 inode를 열었습니까?

tag-icon • tag-icon solaris process inode
프로세스가 파일 시스템에 없는 inode를 열었습니까?

그래서 프로세스가 다소 특이한 위치로 리디렉션되었는지 확인하려고 합니다 stderr(Java 프로세스이고 스레드 덤프를 원하지만 시작 스크립트 중첩을 통해 시작되었습니다).

나는 를 사용하여 내 프로세스를 찾고 거기에 무엇이 있는지 확인하는 데 pgrep사용합니다 .pfiles

4366: /foo/bar/플랫폼/solaris2/jre_1.5.0/bin/java -Xmx2048m -Xms10
현재 rlimit: 65536개의 파일 설명자
 0: S_IFCHR 모드:0666 dev:302,0 ino:6815752 uid:0 gid:3 rdev:13,2
    O_RDONLY|O_LARGEFILE
    /devices/pseudo/mm@0:null
 1: S_IFREG 모드:0640 dev:85,56 ino:26471 uid:0 gid:0 크기:10485812
    O_WRONLY|O_LARGEFILE
 2: S_IFREG 모드:0640 dev:85,56 ino:26471 uid:0 gid:0 크기:10485812
    O_WRONLY|O_LARGEFILE
 3: S_IFCHR 모드:0666 dev:302,0 ino:6815772 uid:0 gid:3 rdev:13,12

stdout그래서 나는 and stderr(파일 설명자 1과 2)가 같은 장소를 가리키고 있음 을 알 수 있습니다 . 나는 그들이 시작 스크립트에서 동일한 파일로 리디렉션되어 이것이 집계되었다고 생각합니다.

그러나 inode 번호가 26471인 파일을 찾으면 다음과 같은 내용이 표시됩니다.

# 찾기 / -inum 26471
/usr/share/man/man3mlib/mlib_MatrixScale_S16_U8_Sat.3mlib
/proc/4366/fd/1
/proc/4366/fd/2
/proc/4366/fd/83

첫 번째 히트는 (확실히) 다른 파일 시스템에 있는 파일입니다. 의 세 항목은 /proc내 프로세스가 열린 fds입니다.

을 살펴보면 /proc/4366에서 얻은 것보다 더 많은 정보를 볼 수 없습니다 pfiles.

# ls -li 0 1 2 3
   6815752 c--------- 1 루트 sys 13, 2 1월 20일 14:10 0
     26471 --w------- 0 루트 루트 10485812 1월 20일 13:42 1
     26471 --w------- 0 루트 루트 10485812 1월 20일 13:42 2
   6815772 c--------- 1 루트 sys 13, 12 2009년 6월 7일 3
# 파일 0 1 2 3
0: 캐릭터 스페셜(13/2)
1: ASCII 텍스트
2: ASCII 텍스트
3: 캐릭터 스페셜(13/12)

(이 fd 중 하나를 추적하여 그 파일이 어떤 파일인지 알아낼 수 있습니다. fd와 inode 간의 관계를 충분히 깊이 이해하지 못하기 때문에 묻습니다.)

그래서 내 프로세스는 다음과 같습니다.무엇(일부 장치에서는 inode 26471이 있음) 그러면 데이터가 다른 inode 번호를 가진 파일로 들어갑니다. 누구든지 이것이 무엇인지에 대한 아이디어를 줄 수 있습니까(또는 지금까지의 추론이 완전히 깨졌는지 알려주십시오)?

답변1

AFAIK는 find파일 시스템의 디렉토리를 검색합니다. 해당 파일이 삭제되었지만 열려 있기 때문에 여전히 존재하는 경우(유닉스의 일반적인 트릭) find.

솔라리스에서는 시도하지 않았지만여기lsof'삭제되었지만 열려 있는' 파일을 식별하는 데 사용하고 다음을 통해 복구하는 방법에 대한 참고 사항입니다.cat /proc/<procid>/fd/<fdid> > /tmp/xxxx

편집하다:

이미 이것이 사실임을 확인한 것 같지만 여전히 어떻게 가능한지 궁금합니다. 간단한 설명은 다음과 같습니다.

POSIX 파일 시스템에서 파일은 에 의해 처리되며 inode디렉터리는 "path => inode" 매핑에 지나지 않습니다. 동일한 inode(하드링크라고 함)를 '가리키는' 경로가 두 개 이상 있을 수 있으며, inode는 링크 수를 유지합니다. 명령 rm은 단순히 unlink()이 경로를 호출하여 링크 수를 줄이고 파일 자체를 '삭제'할 수 있습니다.

그러나 디렉토리 트리의 경로는 inode에 대한 유일한 참조가 아니며 fd실행 중인 프로세스에서 열린 것도 포함되며 '삭제된' 파일은 0이 될 때까지 실제로 제거되지 않습니다.

위에서 언급했듯이 이는 일반적인 트릭입니다. 프로세스 실행이 완료된 후 보관하고 싶지 않은 임시 파일이 있는 경우 해당 파일을 열고 즉시 '삭제'하세요. 열린 핸들은 안정적으로 작동하며 프로세스가 완료되면(정상적으로 종료되거나 충돌하는 경우) 시스템이 핸들을 제거하고 임시 파일을 완전히 삭제합니다.

로그 파일은 '숨겨진 자동 삭제' 파일의 후보가 아닙니다. 하지만 우연히 하는 것은 어렵지 않습니다.

삭제된 로그 파일은 아직 살아있고 데이터를 수집하고 있기 때문에 단순히 내용을 복사하는 것만으로는 큰 도움이 되지 않을 것 같습니다. 따라서 /proc//fd/ 파일에 대한 새로운 하드링크를 만들어 보십시오 ln /proc/4366/fd/1 /tmp/xxxx. -s플래그가 없으므로 ln기호 링크(원하는 것이 아닌 기존 경로에 대한 포인터에 불과함)가 아닌 원본과 동일한 inode를 사용하여 새 하드링크를 만들어야 합니다.

편집하다:

ln /proc/... /tmp/.../proc과 /tmp가 서로 다른 파일 시스템에 있기 때문에 명령이 작동할 수 없습니다 . 불행하게도 기존 inode에 대한 경로 이름을 만드는 방법을 모르겠습니다. link()syscall이 inode 번호와 경로를 사용하기 를 원 하지만 소스 및 대상 경로도 사용합니다.

관련 정보