PID 1 init 역할과 signal/reap 처리 방식 정하기

[SuperSon7]

Context

현재 mini-container/main.go는 container child가 namespace/rootfs/mount 설정을 마친 뒤 syscall.Exec(...)으로 사용자 명령을 실행한다. 이 구조에서는 bootstrap process가 사라지고, 사용자가 요청한 명령이 container PID namespace 안의 PID 1이 된다.

이 방식은 단순하고 runc-like한 흐름이지만, PID 1에는 일반 애플리케이션 프로세스와 다른 책임이 생긴다.

• container 내부 orphan process를 wait()로 회수하지 않으면 zombie가 남을 수 있다.
• SIGTERM, SIGINT 같은 signal을 애플리케이션이 직접 잘 처리하지 않으면 종료 동작이 기대와 다를 수 있다.
• 사용자 명령이 PID 1이 되는 방식과 tiny init wrapper가 PID 1로 남는 방식 중 어느 쪽을 기본/옵션으로 둘지 결정이 필요하다.

기존 #5는 cmd.Run() wrapper를 제거하고 syscall.Exec으로 사용자 명령을 PID 1로 만드는 작업을 다룬다. 이 이슈는 #5에서 의도적으로 제외한 signal forwarding, zombie reaping, tiny init 역할을 후속으로 추적한다.

Goal

mini-container에서 PID 1이 가져야 하는 최소 책임을 정하고, 현재 syscall.Exec 구조를 유지할지 또는 optional init wrapper를 둘지 결정한다.

Scope

• 현재 syscall.Exec 방식에서 발생할 수 있는 PID 1 signal/reap 한계를 재현한다.
• 사용자 명령이 PID 1이 되는 방식과 mini init wrapper가 PID 1로 남는 방식의 tradeoff를 정리한다.
• 필요하다면 optional init wrapper를 설계한다.
• init wrapper를 구현한다면 signal forwarding, child wait/reap, exit status propagation을 최소 범위로 다룬다.
• network namespace wiring, parent-child sync, rootfs pivot_root 전환은 이 이슈 범위에서 제외한다.

Acceptance Criteria

• PID 1이 일반 프로세스와 다르게 signal/reap 책임을 갖는 이유가 코드나 문서에 드러난다.
• 현재 syscall.Exec 방식을 유지할지, optional init wrapper를 추가할지 결정되어 있다.
• init wrapper를 추가한다면 child process의 exit status가 parent runtime까지 보존된다.
• init wrapper를 추가한다면 orphan/zombie process를 회수하는 동작을 관찰할 수 있다.
• init wrapper를 추가한다면 SIGTERM/SIGINT가 실제 사용자 명령으로 전달된다.
• cd mini-container && GOCACHE=/tmp/mini-container-go-build go test ./...가 통과한다.

Notes

지금 network runtime wiring 단계에서는 이 문제를 같이 해결하지 않는다. 우선 CLONE_NEWNET, parent-child sync, network.Manager.Setup(pid) 연결을 통해 container가 새 network namespace에서 뜨는지 확인하고, PID 1 init 역할은 별도 단계에서 다룬다.