Container 프로세스 종료 메커니즘
Docker 컨테이너 종료 시 시그널 처리와 Stop Timeout 동작 정리
Docker 컨테이너를 중지할 때, 내부 프로세스가 어떻게 종료 시그널을 처리하고 타임아웃이 적용되는지에 대한 공식 문서 기반의 정리입니다.
kill과는 다릅니다.
1. 프로세스 종료 시그널 전달 과정
docker stop 명령어가 실행되면 Docker 데몬은 컨테이너 내부의 메인 프로세스(PID 1)에 대해 다음과 같은 단계를 거치면서 종료 절차를 수행합니다.
1단계: SIGTERM(15) 송신
SIGTERM은 프로세스에게 정상적인 종료를 요청하는 시스템 시그널을 보냅니다.
프로세스는 이 시그널을 수신한 후 자원을 해제하거나 수행 중인 작업을 마무리하는 '정상 종료 절차'를 시작할 수 있습니다.
즉, 애플리케이션은 이 시그널을 수신한 뒤 다음과 같은 작업을 수행할 수 있습니다.
신규 요청 차단, 처리 중인 작업 마무리, 리소스 정리(DB 커넥션, 스레드 풀 등)
Graceful Shutdown 로직 수행
2단계: Grace Period(대기 시간) 카운트다운
Docker는 프로세스가
SIGTERM을 받고 스스로 종료될 때까지 일정 시간을 기다립니다.이 시간을 Stop Timeout (grace period) 이라고 합니다.
컨테이너에 별도의 설정이 없다면 이 시간의 기본값은
10초입니다.
3단계: SIGKILL(9) 송신
대기 시간이 경과했음에도 프로세스가 여전히 살아있다면, Docker는 즉시 프로세스를 강제 종료시키는
SIGKILL시그널을 보냅니다.이때 프로세스는 더 이상의 정리 작업을 수행하지 못하고 즉시 소멸합니다.
If no default is configured for the container, the Daemon determines the default, and is 10 seconds for Linux containers, and 30 seconds for Windows containers.
Docker 공식 문서에 따르면, 컨테이너 종료 대기 시간을 명시적으로 설정하지 않을 경우 Linux 컨테이너는 기본값으로 10초의 타임아웃(Stop Timeout)을 가집니다.
이는 사용자가 별도의 옵션을 주지 않았을 때 Dokcer Demon이 결정하는 기본 규칙입니다.
2. 설정의 불일치로 인한 데이터 유실 위험
애플리케이션 코드 내부에서 비동기 작업을 위해 설정한 '종료 대기 시간'이 Docker 엔진의 기본 대기 시간보다 길 경우, 실제로는 애플리케이션의 설정값이 무시됩니다.
애플리케이션 설정:
30초동안 작업을 마무리하도록 로직 구성.스프링의 경우 graceful shutdown period 설정이 가능합니다.
Docker 기본값:
10초후 강제 종료 실행.결과: 10초가 지나는 시점에 Docker가 프로세스를 강제로 날려버리므로, 11초~30초 사이에 처리될 예정이었던 비동기 작업(FCM 발송 등)은 중단되며 데이터 유실이 발생합니다.
3. 검증 방법
[컨테이너에 적용된 Stop Timeout 값 확인]
null→ Docker 데몬 기본값 사용숫자 값 → 명시적으로 설정된 Stop Timeout
[실제 컨테이너 종료 소요 시간 측정 & 컨테이너 종료 이벤트 및 종료 코드 확인]
컨테이너의 실제 종료 소요 시간과 강제 종료 여부는 다음 명령어로 확인할 수 있습니다.
Exit Code 143:
SIGTERM에 의해 프로세스가 정상적으로 종료됨을 의미.Exit Code 137:
SIGKILL에 의해 프로세스가 강제로 종료됨을 의미 (10초 타임아웃 발생 시 주로 나타남).
Last updated