부팅 과정과 커널 패닉

각 단계가 다음 단계를 찾아 넘기는 사슬입니다.

4번이 왜 필요한지가 자주 빠집니다. 실제 루트가 담긴 디스크를 읽으려면 그 디스크의 드라이버가 필요한데, 그 드라이버는 디스크 안에 있습니다. 순환을 끊으려고 필요한 최소 드라이버만 담은 임시 파일시스템을 메모리에 먼저 올립니다.

6번의 PID 1 은 특별합니다. 고아가 된 프로세스를 입양해 종료 상태를 거두고, 이것이 죽으면 시스템이 멈춥니다.

흔한 실수: 부트로더가 운영체제를 실행한다고 답하는 것. 부트로더는 커널을 메모리에 올려놓고 제어를 넘기는 것까지 합니다. 그 뒤는 커널이 스스로 진행합니다.

차이의 근원은 권한입니다. 사용자 모드 프로그램의 잘못된 메모리 접근은 커널이 잡아 그 프로세스만 종료시킵니다. 커널 자신이 그런 상태에 빠지면 잡아줄 상위 계층이 없습니다.

패닉은 고장이 아니라 판단이라는 점도 중요합니다. 커널이 "더 진행하면 데이터를 망가뜨린다"고 보고 스스로 멈추는 것입니다. 계속 돌게 두면 디스크에 잘못된 내용을 쓸 수 있습니다.

흔한 실수: 패닉 원인을 애플리케이션에서 찾는 것. 응용 프로그램은 커널 모드 코드를 실행할 수 없으므로 직접 패닉을 만들 수 없습니다. 드라이버나 커널 버그를 자극한 경우가 아니라면 원인은 그 아래에 있습니다.

추측하지 않고 단계별 소요 시간을 먼저 측정합니다. 대개 특정 서비스의 대기가 대부분입니다.

네 번째가 종종 가장 큰 몫입니다. 네트워크가 준비되기를 기다리는 서비스가 90초 타임아웃을 다 쓰는 경우가 있습니다. 그 서비스가 정말 네트워크를 기다려야 하는지부터 봅니다.

마지막이 근본적인 답입니다. 서버 부팅이 자주 필요한 요구라면(자동 확장 등) 컨테이너나 미리 만들어 둔 이미지로 옮기는 편이 낫습니다.

흔한 실수: 커널 옵션 조정부터 시작하는 것. 커널 초기화는 대개 몇 초이고, 수십 초는 사용자 공간의 서비스 시작에서 나옵니다.

두 번째가 컨테이너에서 실제 문제를 만듭니다. 컨테이너 안에서 애플리케이션이 PID 1 이 되는데, 대부분의 애플리케이션은 고아 프로세스를 거두는 일을 하지 않습니다. 그러면 좀비 프로세스가 쌓입니다.

세 번째가 실무의 답입니다. 컨테이너 실행 옵션으로 최소한의 init 을 넣으면 고아 수거와 신호 전달을 대신 해줍니다.

네 번째도 놓치기 쉽습니다. 일반 프로세스는 종료 신호를 받으면 기본 동작으로 종료되지만, PID 1 은 처리기가 없으면 무시합니다. 그래서 컨테이너가 종료 신호에 반응하지 않고 강제 종료까지 기다리는 일이 생깁니다.

흔한 실수: 셸 스크립트로 애플리케이션을 감싸 실행하는 것. 셸이 PID 1 이 되고 신호를 자식에게 전달하지 않아, 종료 신호가 애플리케이션에 닿지 않습니다.