.so프로세스가 계속 실행되는 동안 심볼릭 링크 .so 파일을 로드하는 프로세스를 업데이트 하면 충돌이 발생하는 문제가 발생했습니다 .
처음 시작할 때 공유 라이브러리(.so)를 로드하는 장기 실행 프로세스가 있고 프로세스가 실행된 후에도 오랫동안 이러한 공유 라이브러리를 사용하게 될 수 있습니다. 프로세스에 의해 로드된 공유 라이브러리는 실제로 .so실제 에 대한 심볼릭 링크입니다(모든 .so를 각 프로세스와 연관된 구조화된 디렉터리에 배치). 때로는 몇 가지 수정 사항을 적용하고 .so 파일을 다시 컴파일해야 하지만 이렇게 하면 업데이트된 .so의 기호에 액세스할 때 일부 장기 실행 프로세스가 충돌하는 것을 발견했습니다.
내 이해에 따르면 프로세스가 심볼릭 링크 대신 실제 .so를 로드하는 경우 .so(새 inode로 .so 파일을 삭제하고 다시 생성)를 다시 컴파일할 때 이전 The inode가 발생하기 때문에 이 동작이 표시되어서는 안 됩니다. .so는 해당 파일을 연 모든 프로세스가 닫힐 때까지 계속 존재해야 합니다. 내가 보고 있는 문제는 대상 .so 대신 심볼릭 링크를 여는 프로세스 때문이라고 생각합니다. 따라서 장기 실행 프로세스는 대상 .so 대신 심볼릭 링크 inode만 유지합니다 .so. 하지만 내 이론이 옳다는 것을 확인할 만큼 충분한 정보가 없습니다.
모든 프로세서가 파일을 닫을 때까지 파일의 inode가 존재합니까? 파일을 매핑하지만 파일 설명자를 열지 않는 프로세스에서 이것이 작동합니까?
심볼릭 링크의 open/mmap은 심볼릭 링크의 인덱스 노드만 추적합니까? 아니면 운영 체제가 대상 파일의 inode를 손상시키는 것을 방지합니까?
답변1
예, Linux(및 기타 모든 POSIX 호환 커널)에서는 모든 프로세서가 파일을 닫을 때까지 파일의 inode가 존재합니다. 여기에는 매핑 파일이 포함됩니다.
이는 다음으로 인해 발생합니다.POSIX:
mmap() 함수는 파일 설명자 fildes와 연관된 파일에 추가 참조를 추가합니다. 이는 해당 파일 설명자에 대한 후속 close()에 의해 제거되지 않습니다. 파일에 대한 매핑이 더 이상 없으면 참조가 삭제됩니다.
심볼릭 링크의 열기/mmap은 해당 inode만 추적합니다.대상 파일(사용의 극단적인 경우를 제외하고
O_PATH). 호출되면 경로의 모든 심볼릭 링크가 확인되고open()파일 설명자는 대상 파일만 참조합니다.이것을 테스트할 수 있습니다:
- 파일을 생성하다
/tmp/original /tmp/symlink다음을 가리키는 심볼릭 링크를 만듭니다./tmp/original/tmp/symlink프로그램에서 열기(예: Python 셸에 입력)f = open('/tmp/symlink', 'r')- 보고 있다
/proc/<pid of the program>/fd - 파일 설명자는 다음을 가리킵니다.
/tmp/original
- 파일을 생성하다
다시 컴파일할 때 .so 파일이 직접 작성되지 않고 실제로 삭제되고 다시 생성되는지, 장기 실행 프로세스가 dlopen.so 파일을 동적으로 다시 여는 등의 방법을 사용하지 않는지 확인하세요.
제가 생각할 수 있는 또 다른 가능성은 지연 바인딩으로 인해 장기 실행 프로세스에서 .so 파일 로드가 지연된다는 것입니다.
환경에서 장기 실행 프로세스를 시작하여 지연 바인딩으로 인해 문제가 발생했는지 확인 LD_BIND_NOW=1하고 재컴파일로 인해 여전히 프로세스가 중단되는지 확인할 수 있습니다.