무한 반복이 된 자동 재시작

컨테이너가 계속 재시작되면서 로그가 초당 수백 줄씩 쌓이고 있었다. 확인하니 컨테이너 런타임과 서비스 관리자 양쪽에 항상 재시작 설정이 켜져 있었다.

Open Table of contents

살리는 설정보다 먼저 볼 것

살리는 설정이 겹친 것도 문제이지만 더 앞의 문제는 왜 죽느냐였다. 로그를 보니 클래스를 못 찾아 시작하자마자 죽고 있었고 배포에서 파일 하나가 빠진 것이었다.

살리는 설정 때문에 계속 다시 뜨고 계속 죽는 상태였다. 살리는 쪽을 먼저 손대면 증상만 멈추고 원인은 그대로 남는다.

재시작에 상한을 둬서 몇 번 실패하면 그만두게 했다. 계속 도는 것보다 멈춰 있는 편이 낫기 때문이다.

멈춰 있으면 알림이 가게 했는데 여기서 하나를 놓칠 뻔했다. 계속 재시작하는 동안에는 상태가 종료가 아니라 재시작 중이라 종료 상태 필터에 안 잡히므로 재시작 상태도 함께 봐야 했다.

살리는 계층을 하나로 정했다. 서비스 관리자가 컨테이너를 관리하면 런타임 쪽 재시작을 끄고 런타임이 관리하면 서비스 유닛을 안 만든다.

둘이 겹치면 서로 싸우는데 한쪽이 멈추라고 하는 동안 다른 쪽이 살린다. 런타임에 맡기기로 하고 서비스 유닛을 지웠다.

재시작 간격이 점점 늘어나는 방식이라도 처음 몇 번은 빠르므로 그 사이에 로그가 수천 줄 쌓인다. 그래서 로그 크기와 파일 개수에 상한을 뒀다.

상한을 안 두면 디스크가 차는데 실제로 재시작 반복으로 디스크가 찬 적이 있었다. 시작하다 죽는 것과 돌다가 죽는 것도 갈라서 시작 유예 기간을 두고 그 안에 건강해지지 않으면 문제로 보게 했다.

무엇 때문에 죽었는지는 종료 코드로 갈렸다. 정상 종료와 애플리케이션 오류와 메모리 부족에 의한 강제 종료와 종료 신호가 각각 다른 코드로 나온다.

메모리 부족은 애플리케이션 로그를 봐도 안 나오므로 컨테이너 상태의 해당 플래그로 확인해야 한다. 재시작 횟수도 세어 지표로 보냈는데 계속 살아나는 동안에는 겉으로 정상으로 보이므로 그 숫자를 봐야만 알 수 있다.