동일한 "열린 파일 설명"을 공유하는 파일 설명자 찾기

내가 (본과 같은 껍질에서) 할 경우 :

exec 3> file 4>&3 5> file 6>> file

파일 설명자 3과 4는 4가 dup()3에서 시작되었으므로 동일한 열린 파일 설명 (동일한 속성, 파일 내에서 동일한 오프셋 ...)을 공유합니다. 해당 프로세스의 파일 디스크립터 5와 6은 다른 열린 파일 설명 에 있지만 (예를 들어 파일에 고유 한 포인터가 있습니다).

이제 lsof출력 결과는 다음과 같습니다.

zsh     21519 stephane    3w   REG  254,2        0 10505865 /home/stephane/file
zsh     21519 stephane    4w   REG  254,2        0 10505865 /home/stephane/file
zsh     21519 stephane    5w   REG  254,2        0 10505865 /home/stephane/file
zsh     21519 stephane    6w   REG  254,2        0 10505865 /home/stephane/file

다음과 lsof +fg같이 조금 나아졌습니다 .

zsh     21519 stephane    3w   REG          W,LG  254,2        0 10505865 /home/stephane/file
zsh     21519 stephane    4w   REG          W,LG  254,2        0 10505865 /home/stephane/file
zsh     21519 stephane    5w   REG          W,LG  254,2        0 10505865 /home/stephane/file
zsh     21519 stephane    6w   REG       W,AP,LG  254,2        0 10505865 /home/stephane/file

(여기서는 Linux 3.16에서) fd 6에는 다른 플래그가 있으므로 fd 3, 4 또는 5의 파일 과 다른 열린 파일 설명 이어야 하지만 fd 5가 다른 열린 파일 설명 . 를 사용하면 -o오프셋도 볼 수 있지만 동일한 오프셋이 동일한 열린 파일 설명을 보장하지는 않습니다 .

방해하지 않는 ¹ 가지 방법이 있습니까? 외부 또는 프로세스 자체 파일 설명자?

_{¹ . 휴리스틱 접근법 중 하나는 fd의 플래그를 변경하고 fcntl()다른 파일 디스크립터가 플래그를 업데이트 한 결과를 보는 것이 될 수 있지만, 이상적이지 않고 어리석은 증거는 아닙니다.}

Linux 3.5 이상에서는 kcmp (3) 으로 수행 할 수 있습니다 .

KCMP_FILE

• 파일 디스크립터 있는지 확인 IDX1 공정에서 PID1이 같은 열린 파일 정보를 말한다 (참조 열기 (2) 와 같은 파일 설명자) idx2 공정에서 PID2를 . 동일한 열린 파일 설명을 참조하는 두 개의 파일 디스크립터가 존재하면 dup (2) (및 유사한) fork (2) 또는 도메인 소켓을 통해 파일 디스크립터를 전달 하여 발생할 수 있습니다 ( unix (7) 참조 ).

매뉴얼 페이지는 OP가 요청한 유스 케이스에 대한 예제를 제공합니다. 이 syscall을 사용하려면 커널을 CONFIG_CHECKPOINT_RESTOREset 로 컴파일해야합니다 .

비교하고자 struct file하는 것은 파일 설명자가 가리키는 포인터입니다. (내부 커널은 하나 개이며 task_struct그것은라는 또 다른 구조에 대한 포인터를 포함합니다. 각 스레드에 대한 데이터 구조 files_struct. 그리고 그 구조는 포인터의 배열하는 각 하나를 포함 struct file. 그것은의 struct file오프셋 추구, 오픈 플래그 및을 보관 유지하는 다른 필드는 거의 없습니다.)

files_struct침입 도구를 사용하는 것 이외의 다른 방법으로 포인터를 볼 수있는 사용자가 볼 수있는 방법을 모르겠습니다 . 예를 들어, SystemTap에 PID가 주어지면 해당하는 것을 찾고 task_struct포인터를 따라갈 수 있습니다. 그러나 수동적 인 것을 찾고 있다면 그것에 관한 것이라고 생각합니다. Dell은 오래 전에 KME (Kernel Memory Editor)라는 도구를 발표하여 라이브 커널 메모리에 스프레드 시트와 같은 인터페이스를 제공하여 원하는 작업을 수행 할 수 있었지만 64 비트로 이식되지는 않았습니다. (나는 시도했지만 완전히 작동하지 않았으며 왜 그런지 확신하지 못했습니다.)

당신이 lsof도움 이되지 않는 한 가지 이유 는 그 포인터도 보이지 않기 때문입니다 (그러나 +f비 리눅스 시스템 의 옵션을 보십시오 ). 이론적으로의 모든 필드를 비교 struct file하고 두 구조가 동일하다고 생각할 수 있지만 여전히 별도의 open(2)호출 에서 온 것일 수 있습니다 .

아이디어를 얻으려면 pfiles SystemTap 스크립트를 살펴보십시오 . 주소를 인쇄하도록 수정 한 경우 struct file해결책이 있습니다. open_file_by_pid.stp 도 검사 할 수 있는 함수가 있으므로 확인할 수도 있습니다 files_struct. struct file객체를 보고있는 파일 디스크립터 테이블

내가 뭘 하려는지 물어봐도 될까요?

리눅스 전용 솔루션은 다음과 같습니다. / proc / self / fd는 현재 프로세스에서 열린 파일 핸들을위한 심볼릭 링크 디렉토리입니다. 링크 값만 비교하면됩니다. 자식 프로세스를 사용할 때 자식이 다른 / proc / self를 가질 수 있기 때문에 자식 프로세스를 사용할 때 더 복잡해집니다. / proc / $$ / fd를 사용하여이 문제를 해결할 수 있습니다. 여기서 $$는 원하는 pid입니다.