서비스가 계속 재시작될 때 원인 찾는 법 — 35일간 3,348회 재시작한 서버 기록
리눅스 서비스가 몇 분 간격으로 계속 재시작된다면, 원인이 그 서비스가 아니라 서비스를 지켜보는 쪽 일 수 있어요. 로그에 오류가 안 남는데도 재시작만 반복된다면 특히 그렇습니다. 제 서버가 35일 동안 3,348번 재시작됐는데, 범인은 서비스를 살려두려고 제가 직접 붙인 감시 스크립트였어요. 이 글에서 원인을 3분 만에 확인하는 명령어 와 감시 기준을 어떻게 바꿔야 하는지를 정리했습니다. 숫자는 전부 제 서버에서 뽑은 실제 값이에요. 📌 3줄 결론 - "살아 있음"을 파일 수정 시각으로 판정했더니, 감시 스크립트가 감시 대상을 계속 죽였습니다 - 35일 · 3,348회. 재시작 간격이 정확히 15분이라 로그만 봐도 인위적인 주기가 보였습니다 - 재시작은 직접 만든 스크립트가 아니라 systemd에 맡기고, 판정 기준을 "부산물"이 아니라 "결과"로 바꿔야 합니다 확인일 2026-08-14 · 대상: 제가 직접 운영하는 리눅스 서버 1대 어떤 구조였나 AI 에이전트가 계속 학습하며 결과를 데이터베이스에 쌓는 서버였어요. 이 작업이 멈추면 안 되니까, 살아 있는지 지켜보는 스크립트를 하나 붙였습니다. 판정 기준은 이랬어요. 데이터베이스 파일의 수정 시각이 10분 넘게 그대로면 작업이 멈춘 것으로 본다 멈췄으면 작업 서비스와 API 서비스를 함께 재시작 한다 이 검사를 cron으로 5분마다 돌린다 읽어보면 그럴듯해요. 실제로 저도 그럴듯해서 붙였습니다. 문제는 작업 프로세스가 한 번 도는 데 15분 넘게 걸렸다 는 겁니다. 그 15분 동안 계산만 하고, 결과를 데이터베이스에 쓰는 건 맨 마지막 이었어요. 그러니까 정상 작동 중에도 파일 수정 시각은 10분 넘게 그대로였습니다. 감시 스크립트 입장에서 정상 작동은 고장과 구분되지 않았어요. 15분마다 죽은 이유 — 로그에 그대로 찍힌다 재시작이 일어나면 파일 수정 시각이 갱신됩니다. 그다음 10분간은 임계값에 안 걸려요....
댓글