systemd 서비스가 재시작을 멈췄다면: Restart와 StartLimit을 함께 읽는 법

서비스가 몇 차례 다시 시작되다가 멈췄습니다. unit 파일에는 자동 재시작 설정이 있는데, 왜 더는 시도하지 않을까요? 이때는 재시작 정책이 맞는지와 새로운 시작이 허용되는지를 따로 확인해야 합니다. 마지막 실패 메시지만으로 애플리케이션의 최초 종료 원인까지 단정하기는 어렵죠.

Restart 설정만으로 계속 재시작할 수 있나요?

재시작 정책이 종료 조건에 맞더라도, 시작 횟수 제한이나 재시작 제외 조건에 따라 멈출 수 있습니다.

systemd.service의 Restart 설명은 프로세스의 종료·시그널·시간 초과에 따른 정책을 구분합니다. 예를 들어 on-failure와 always는 같은 조건을 뜻하지 않죠. 어떤 설정인지와 실제 종료 결과를 맞춰 읽어야 해요.

always라는 이름도 모든 상황에서 끝없이 실행된다는 보장은 아닙니다. 관리자가 systemctl stop으로 중지한 경우에는 자동으로 다시 시작하지 않습니다. RestartPreventExitStatus= 같은 별도 조건도 함께 확인해야 하죠.

재시작까지 기다리는 시간과 시작 횟수 제한도 다릅니다. RestartSec=는 자동 재시작 전의 대기 시간을 정합니다. 이 값 하나로 시작 제한의 판단 기간이나 허용 횟수를 설명할 수는 없죠.

StartLimit은 어떤 시작 요청을 제한하나요?

일정 기간의 시작 횟수를 제한하며, 자동 재시작뿐 아니라 관리자가 요청한 수동 시작에도 적용됩니다.

systemd.unit의 시작 제한 설명에서 StartLimitIntervalSec=는 확인 기간, StartLimitBurst=는 그 기간에 허용할 시작 횟수입니다. 실패한 횟수만 센다고 이해하면 범위가 달라지죠.

실무에서는 재시작 요청을 반복하기 전에 자동 시도와 수동 시도의 시간을 함께 확인하는 편이 좋습니다. 같은 unit에 대한 시작 요청을 여러 담당자가 보냈다면 그 맥락도 살펴보세요. 여기서는 특정 서버의 장애 사례나 권장 횟수를 가정하지 않아요.

기본값은 관리자 설정과 unit의 재정의 여부까지 확인해야 합니다. 인터넷 예제의 시간과 횟수를 모든 서버의 기본값으로 옮기지 않는 것이 좋죠. 최신 공식 문서와 함께 설치된 systemd 버전 및 배포판 매뉴얼을 확인하세요.

제한 시간이 지나면 서비스가 자동으로 살아나나요?

제한 시간 만료 자체가 자동 시작을 예약하는 것은 아니며, 이후의 새로운 시작 계기가 필요합니다.

공식 문서는 시작 제한에 도달한 서비스의 자동 재시작 시도가 멈춘다고 설명합니다. 기간이 지난 뒤에는 수동 요청이나 타이머·소켓을 통해 다시 시작될 수 있습니다. 그런 계기가 설정되어 있는지와 실제로 발생했는지는 따로 확인해야 하죠.

따라서 시간이 지났는데도 정지 상태라는 관측만으로 제한 기능이 고장 났다고 볼 수는 없습니다. 시작을 막던 조건과 새로운 시작 요청의 유무를 나누어 읽어야 해요. 반대로 자동으로 살아났다면 외부의 시작 계기도 확인할 필요가 있죠.

운영 기록에는 제한에 도달한 시각, 이후 시작 요청의 주체, 그 요청의 결과를 구분해 남기는 방법을 제안합니다. 이 기록은 원인 분석을 위한 정리 방식입니다. 대기 시간 만료를 복구 완료 시각으로 기록하지 마세요.

실제 적용 설정과 실패 기록은 어떻게 확인하나요?

디스크의 unit 파일, 관리자가 읽은 속성, 현재 상태와 해당 시점의 로그를 구분해 대조합니다.

systemctl 공식 문서는 cat과 show의 역할을 구분합니다. cat은 디스크의 unit 본문과 drop-in 파일을 보여주며, show는 서비스 관리자의 속성과 실행 상태를 조회합니다. 파일을 바꾼 뒤 daemon-reload가 이루어지지 않았다면 둘이 다를 수 있죠.

아래는 시스템 서비스의 조회 명령 예시입니다. example.service는 실제 점검할 unit 이름으로 바꿔 읽으세요. 서비스 이름만으로 실행 결과를 가정하지 않아요.

journalctl 공식 문서에서 -b는 인자 없이 쓰면 현재 부팅을 대상으로 합니다. 이전 부팅의 장애를 찾는다면 조회 범위를 바꿔야 하죠. 로그가 보이지 않는 이유에는 조회 범위·접근 권한·보관 여부도 있으므로, 출력이 없다는 사실만으로 장애가 없었다고 판단하지 마세요.

사용자 서비스는 시스템 서비스와 관리자 범위가 다릅니다. 해당 사용자로 systemctl --user 범위를 확인하고, 로그에는 journalctl --user-unit=example.service 같은 사용자 unit 필터를 검토해야 해요. 서로 다른 범위의 결과를 한 서비스의 설정처럼 합치면 안 됩니다.

show의 속성은 원래 설정과 이름·표현이 다를 수 있습니다. 공식 문서는 시간 속성이 내부 정규화 단위에 따라 USec 접미사로 표시될 수 있다고 설명하죠. 숫자를 비교할 때는 속성 이름과 단위를 함께 읽어야 합니다.

reset-failed 전에 무엇부터 확인해야 하나요?

실패 원인과 설정·로그를 먼저 보존한 뒤, 초기화할 unit과 다시 시작할 조건을 확인해야 합니다.

systemctl의 reset-failed 설명은 실패 상태와 시작 제한 카운터, 서비스의 재시작 카운터를 초기화한다고 안내합니다. 애플리케이션 설정이나 실행 환경을 고치는 동작은 아니죠.

특히 unit 이름 없이 실행하면 모든 unit의 실패 상태를 초기화할 수 있습니다. 조사 중이라면 대상 이름과 관리자 범위를 먼저 확정하고, 지워질 상태 정보도 기록해 두는 편이 좋죠. 이 글은 초기화나 재시작을 일괄 실행하는 절차를 제시하지 않아요.

원인이 남아 있다면 다시 시작해도 같은 종료와 제한이 반복될 수 있습니다. 우선 로그에서 처음의 종료 원인과 뒤이은 시작 거부를 구분해 보세요. 시작 제한 해제를 복구의 기본 처방으로 두지 않는 것이 좋죠.

서버 부팅과 서비스 실행의 큰 흐름은 클라우드 인프라, 개별 서비스는 아는데 전체 구조가 안 보인다면에서 다룹니다. 여기서는 전체 인프라 구성이나 애플리케이션별 메모리 조정보다 systemd의 정책·시작 제한·기록을 읽는 데 집중합니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)