[Docer] 도커 컨테이너의 종료 코드 (exit code)

layl__a·2023년 4월 20일

Docker

목록 보기

2/5

프로젝트를 하다가 도커가 갑자기 꺼지더니.. 재시작도 안돼서 무슨 일인가 싶어 찾아봤더니.. 도커 종료 코드가 있다는 걸 알게 되었다.

리눅스 프로세스가 종료 시그널을 받으면, 종료되는 이유를 관리자가 알 수 있도록 종료 원인에 해당하는 코드를 반환하는 것이 일반적이고, 도커 컨테이너 또한 예외는 아니라고 한다. 컨테이너 내부의 init 프로세스가 종료될 시 컨테이너는 종료 코드를 도커 데몬에게 알려 저장하도록 되어 있다. (init 프로세스는 Dockerfile 및 컨테이너 생성 명령어에 정의된 CMD 또는 Entrypoint 등을 의미한다) 때문에 docker ps -a와 같은 일반적인 명령어로도 어떠한 이유로 컨테이너가 종료되었는지를 쉽게 확인할 수 있다고 한다.

종료 코드 확인 방법

docker ps -a --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

1) exit code 0: 성공적으로 종료됨

가장 일반적인 경우로, 컨테이너 내부의 init 프로세스가 자신의 역할을 다하고 정상적으로 종료되었을 때, 또는 docker stop에 의해 종료되었을 때에 해당된다. SIGTERM에 의해 종료되어도 0으로 출력되는걸로 보아, 두 코드 간에 큰 차이는 없는걸로 보인다.

(2) exit code 125: 도커 명령어 자체가 실패한 경우

잘못된 도커 명렁어 또는 플래그로 인해 수행 자체가 성공되지 않은 경우에 해당한다. 사실상 docker ps -a 출력에서는 볼 수 없는 에러 코드이다.

(3) exit code 126: 컨테이너의 커맨드가 실패한 경우

컨테이너 실행 시, 커맨드의 수행이 실패된 경우이다. 명령어 자체는 유의미하지만 실행 불가능한 경우 등에 해당된다. 컨테이너가 생성되어 Created 상태이지만, 실행 자체가 불가능하므로 docker ps -a에서는 출력되지 않는 코드이다.

(4) exit code 127: 컨테이너의 커맨드가 존재하지 않는 경우

컨테이너에 설정된 커맨드가 컨테이너 내부에 존재하지 않아 수행할 수 없는 경우이다. 126과 마찬가지로 컨테이너가 생성은 되지만 실행은 되지 않는다.

(5) exit code 128 + n: 리눅스 시그널 n에 해당하는 오류가 발생한 경우

255를 제외한 아래의 경우에 해당된다.

(6) exit code 130: (128+2) Control + C로 종료된 경우

컨테이너가 실행되었을 때, 인터럽트 루틴(Control + C) 에 의해 init 프로세스가 전달된 경우이다. 인터럽트 신호인 SIGINT의 코드가 2이므로 종료 코드는 130이 된다. 사실상 개발자가 의도적으로 컨테이너를 종료시키는 경우가 아니면 거의 볼 수 없다.

mysql과 같은 컨테이너를 interactive하게 (-it) 생성하고 Control + C를 연속적으로 입력하면 이 코드를 인위적으로 만들어 낼 수 있다.

(7) exit code 137 & 143: (128+9, 15) 컨테이너가 SIGKILL 및 SIGTERM 을 받은 경우

docker stop 명령어를 사용하면 도커 데몬은 컨테이너의 init 프로세스에 SIGTERM을 전송하며, 일반적으로 Gracefully exit라고 부른다. 일정 시간이 지나도 종료되지 않을 시 SIGKILL을 전송하게 되고, 이 때의 종료 코드는 137이 된다. docker stop이 SIGKILL로 전환되도록 하는 시간 제한은 docker stop의 -t 플래그를 통해 초 단위로 설정할 수 있으며 기본 값은 10초이다.

docker kill 및 docker rm -f 명령어 또한 SIGKILL 시그널을 사용하기 때문에, 마찬가지로 종료 코드는 137로 출력된다. 참고로, 컨테이너의 메모리 자원 부족으로 인한 OOM 시 컨테이너의 강제 종료에도 SIGKILL이 사용되어 137로 출력된다.