프로그래밍/리눅스 커널

리눅스 pidfd 기준

포도알77 2026. 9. 19. 14:10

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

리눅스에서 프로세스를 다룰 때 PID 숫자만 저장해 두면 애매한 순간이 생깁니다. 대상 프로세스가 종료된 뒤 같은 PID가 다른 프로세스에 재사용될 수 있기 때문입니다. pidfd는 이 문제를 줄이기 위해 프로세스를 파일 디스크립터처럼 참조하는 방식입니다.

기준은 단순합니다. 이미 존재하는 프로세스에 안정적인 참조가 필요하면 pidfd_open()을 검토하고, 새 자식 프로세스를 만들면서 처음부터 참조를 확보해야 하면 clone() 또는 clone3()CLONE_PIDFD 계열 흐름을 검토합니다. PID 문자열을 오래 보관해 두고 나중에 신호를 보내거나 종료를 감시하는 구조라면 pidfd가 더 직접적인 선택지입니다.

pidfd는 무엇을 바꾸나

공식 man-pages 기준 pidfd_open()은 특정 task를 가리키는 파일 디스크립터를 만듭니다. 이 디스크립터에는 close-on-exec 플래그가 설정되며, 성공하면 일반 파일 디스크립터처럼 0 이상의 정수로 반환됩니다.

중요한 차이는 참조의 성격입니다. PID 숫자는 이름에 가깝고, pidfd는 특정 프로세스에 대한 커널 객체 참조에 가깝습니다. 그래서 pidfd_send_signal()은 기존 kill()처럼 숫자 PID만 보고 신호를 보내는 방식에서 생길 수 있는 PID 재사용 race를 피하는 데 쓰입니다. 대상이 이미 종료되어 회수된 경우에는 다른 프로세스에 잘못 신호를 보내는 대신 오류로 실패할 수 있습니다.

구분 특징 주의할 점
PID 숫자 프로세스 식별자로 쓰기 쉽고 전통적인 인터페이스와 맞음 프로세스 종료 뒤 같은 숫자가 재사용될 수 있음
pidfd 특정 task를 가리키는 파일 디스크립터 참조 리눅스 전용 인터페이스이고 권한, namespace, 커널 지원을 확인해야 함

어떤 작업에 쓸 수 있나

pidfd_open() 문서는 pidfd의 대표 용도를 몇 가지로 설명합니다. pidfd_send_signal()로 신호를 보낼 수 있고, poll(), select(), epoll()로 종료 상태를 감시할 수 있으며, 호출한 프로세스의 자식이면 waitid()로 기다릴 수 있습니다. 또 pidfd_getfd()로 다른 프로세스의 파일 디스크립터를 복제하거나, setns()와 함께 namespace 이동에 사용할 수 있습니다.

운영 코드에서 가장 먼저 떠올릴 사용처는 종료 감시와 신호 전달입니다. supervisor, test runner, worker manager처럼 자식 프로세스를 많이 만들고 회수하는 프로그램은 PID 재사용과 좀비 회수를 항상 신경 써야 합니다. pidfd를 쓰면 이벤트 루프에서 다른 파일 디스크립터와 같은 방식으로 프로세스 종료를 감시할 수 있습니다.

pidfd는 읽을 수 있는 데이터 스트림이 아닙니다. man-pages는 현재 구현에서 pidfd에 대한 read()EINVAL로 실패한다고 설명합니다. 종료 감시는 내용을 읽는 방식이 아니라 poll()이나 epoll() 이벤트를 보는 방식으로 이해해야 합니다.

 

 

pidfd_open과 CLONE_PIDFD는 어떻게 고르나

이미 실행 중인 프로세스를 대상으로 한다면 pidfd_open(pid, 0)이 기본 흐름입니다. 리눅스 5.3부터 제공되며, man-pages는 이미 존재하는 프로세스에 대한 PID file descriptor를 얻는 선호 방법으로 설명합니다. 예전 방식처럼 /proc/pid 디렉터리를 열 수도 있지만, 이 방식은 proc 파일시스템에 의존하고 poll() 가능성이나 waitid() 사용 면에서 pidfd_open으로 얻은 디스크립터와 같지 않습니다.

자식 프로세스를 만들면서 race 없이 참조를 확보해야 한다면 CLONE_PIDFD를 검토합니다. fork() 뒤에 pidfd_open()을 호출하는 방식도 가능한 조건이 있지만, 자식이 이미 회수되었거나 SIGCHLD 처리 방식이 다른 경우에는 보장이 깨질 수 있습니다. 이런 구조에서는 생성 시점에 pidfd를 함께 받는 방식이 더 명확합니다.

상황 우선 검토할 방법 이유
이미 존재하는 프로세스를 참조 pidfd_open() 기존 PID로 안정적인 파일 디스크립터 참조를 얻음
새 자식 프로세스를 직접 생성 CLONE_PIDFD 생성 시점부터 참조를 확보해 회수 race를 줄임
단순 일회성 명령 실행 기존 wait() 계열도 충분할 수 있음 복잡한 이벤트 루프나 장기 참조가 없다면 이점이 작음

신호 전달에서는 무엇이 안전해지나

pidfd_send_signal()은 리눅스 5.1부터 제공된 시스템 호출입니다. 대상은 PID 숫자가 아니라 pidfd가 가리키는 프로세스입니다. 호출자는 대상 프로세스와 같은 PID namespace에 있거나 그 namespace의 조상 namespace에 있어야 하며, 일반적인 신호 권한도 만족해야 합니다.

리눅스 6.9부터는 thread를 가리키는 pidfd와 신호 범위를 더 세밀하게 다루는 플래그가 문서화되어 있습니다. 일반적인 프로세스 단위 제어라면 먼저 기본 pidfd와 flags = 0 흐름을 이해하고, thread 단위 신호가 필요한 경우에만 PIDFD_THREAD나 관련 signal scope 플래그를 검토하는 편이 안전합니다.

pidfd_getfd는 언제 조심해야 하나

pidfd_getfd()는 리눅스 5.6부터 제공되며, pidfd가 가리키는 다른 프로세스의 파일 디스크립터를 호출한 프로세스 쪽으로 복제합니다. 반환된 디스크립터는 원래 디스크립터와 같은 open file description을 가리키므로 파일 오프셋과 상태 플래그 같은 성격을 공유합니다.

이 기능은 디버깅, supervisor, sandbox, container runtime 같은 저수준 도구에는 유용할 수 있지만 일반 애플리케이션 코드의 기본 선택지는 아닙니다. 문서상 다른 프로세스의 디스크립터를 복제하려면 ptrace 접근 권한 검사를 통과해야 하며, flags는 현재 0이어야 합니다. 권한 경계를 우회하는 편의 기능으로 보면 안 됩니다.

실무에서의 선택 기준

첫째, 프로세스를 장시간 추적해야 하는지 봅니다. 잠깐 실행하고 바로 wait()하는 구조라면 기존 방식이 충분할 수 있습니다. 반대로 비동기 이벤트 루프에서 여러 자식 프로세스의 종료와 타임아웃을 함께 봐야 한다면 pidfd가 더 자연스럽습니다.

둘째, PID 재사용이 실제 위험인지 봅니다. 종료 후 나중에 신호를 보내거나 상태를 확인하는 코드가 있다면 숫자 PID만 저장하는 방식은 취약합니다. pidfd는 이 지점에서 명확한 기준을 줍니다.

셋째, 배포 대상 커널과 libc 사용 방식을 확인합니다. man-pages 6.18 기준 pidfd_open(), pidfd_send_signal(), pidfd_getfd()는 glibc wrapper 없이 syscall() 형태로 설명됩니다. 실제 프로젝트에서는 대상 배포판의 커널 버전, 헤더, 런타임 권한, namespace 구조를 함께 확인해야 합니다.

자주 묻는 질문

pidfd를 쓰면 좀비 프로세스가 자동으로 정리되나?

그렇지 않습니다. pidfd는 참조와 감시 수단이지 자식 회수를 자동으로 대신하는 기능이 아닙니다. 자식 프로세스라면 여전히 적절한 wait() 또는 waitid() 흐름으로 회수해야 합니다.

pidfd는 리눅스 밖에서도 쓸 수 있나?

아닙니다. man-pages의 standards 항목은 관련 시스템 호출을 Linux로 분류합니다. 이식성이 중요한 코드라면 pidfd 경로와 다른 운영체제용 대체 경로를 분리해야 합니다.

PID namespace에서는 항상 같은 방식으로 신호를 보낼 수 있나?

아닙니다. pidfd_send_signal() 문서는 호출자가 대상과 같은 PID namespace 또는 그 조상 namespace에 있어야 한다고 설명합니다. container나 namespace를 다루는 도구에서는 이 조건을 설계에 포함해야 합니다.

정리하면 pidfd는 모든 프로세스 제어 코드를 바꾸는 도구가 아니라, PID 숫자만으로는 안정성이 부족한 지점을 보완하는 리눅스 인터페이스입니다. 프로세스 종료 감시, 안전한 신호 전달, 생성 시점의 참조 확보가 핵심 요구라면 pidfd를 기준 선택지로 검토할 만합니다.

반응형

'프로그래밍 > 리눅스 커널' 카테고리의 다른 글

리눅스 Landlock 기준  (0) 2026.09.22
리눅스 Device Tree clocks 기준  (0) 2026.09.20
리눅스 io_uring 기준  (0) 2026.09.18
리눅스 PSI 기준  (0) 2026.09.16
리눅스 모듈 파라미터 기준  (0) 2026.09.14
페이스북으로 공유카카오톡으로 공유카카오스토리로 공유트위터로 공유URL 복사