의도적으로 중지한 서비스를 워치독이 재시작했습니다

운영2026-10-31

저희 워치독 중 하나는 활성화되었지만 실행 중이 아닌 서비스를 시작합니다. 10월에 두 번, 의도적으로 중지한 서비스를 시작했습니다. 두 번째 때는 저희 사이트 방문자가 약 45분 동안 오류를 겪었습니다.

그 워치독이 존재하는 이유

예를 들어 이름으로 종료 명령을 받아 SIGTERM을 받고 정상 종료된 서비스는 systemd 입장에서 "실패" 상태가 아닙니다. Restart=on-failure은 이를 다시 시작하지 않으며, systemctl --failed에도 표시되지 않습니다. 누군가 우연히 알아채기 전까지 계속 다운 상태로 남아 있습니다. 그래서 워치독은 활성화되었지만 실행 중이 아닌 서비스를 찾아 시작합니다.

문제는 수동으로 중지한 서비스가 정확히 동일해 보인다는 점입니다.

첫 번째 사례

10월 7일, 작업 큐를 편집하기 위해 12:47에 systemctl stop으로 비디오 워커를 중지했습니다. 12:55에 다시 실행 중이었습니다. 워치독이 시작했기 때문입니다.

두 번째 사례

10월 21일, 저희 사이트 두 개도 서비스하는 머신의 메모리를 모델 테스트에 필요했습니다. 스크립트가 사이트의 웹 앱, 동기화 작업, 데이터베이스 컨테이너를 다시 systemctl stop으로 중지했습니다. 약 5분 후 사이트를 감시하는 타이머가, 그리고 19:14에 워치독이 터널과 웹 앱을 다시 시작했습니다.

터널은 트래픽을 다시 받았지만, 웹 앱은 응답할 수 없었습니다. 테스트 중인 모델이 머신 메모리의 114 GiB를 점유하고 있었기 때문입니다. 약 19:14부터 20:00까지 일부 방문자가 502 오류를 받았습니다. 20:00에 터널, 웹 앱, 동기화 작업을 비활성화하고 감시 타이머를 중지했습니다.

현재 사용하는 규칙

• 서비스를 일시 중지하려면 비활성화하십시오: sudo systemctl disable --now <unit>. sudo systemctl enable --now <unit>으로 다시 시작하십시오. 저희 워치독은 활성화된 서비스만 확인하므로, 비활성화된 서비스는 건드리지 않습니다.
• 다시 시작할 수 있는 모든 것을 일시 중지하십시오: 앞에 있는 터널과 이를 감시하는 모든 타이머.
• 짧은 중지는 경쟁 상태입니다. stop만 사용한다면, 다음 점검 전에 완료하십시오. 저희 머신에서는 몇 분 내에 점검이 실행됩니다.

같은 달에 발생한 다른 systemd 함정 두 가지

• /etc/systemd/system에 있는 유닛 파일에는 systemctl mask --runtime이 아무런 효과가 없습니다. /etc의 유닛이 /run의 런타임 마스크보다 우선하므로, 명령은 성공하지만 서비스는 계속 시작됩니다. 서비스를 정지 상태로 유지하려면 ConditionPathExists=!/etc/<name>.hold가 포함된 드롭인을 사용하십시오. 해당 파일이 존재하는 동안에는 부팅 시에도 수동으로 실행할 때도 서비스가 시작되지 않습니다.
• systemctl is-active는 실행 중인 oneshot 서비스를 inactive로 보고합니다. Type=oneshot 서비스가 실행 중일 때 상태는 "activating"이므로, is-active는 이 값을 출력하고 3을 반환합니다. 야간 작업을 기다리려고 작성한 while systemctl is-active --quiet job.service; do sleep 60; done 같은 루프는 즉시 종료됩니다. 대신 상태를 확인하십시오. active, activating, reloading 또는 deactivating은 모두 서비스가 아직 실행 중임을 의미합니다.

Factory Floor는 활성화되었으나 실행 중이 아닌 서비스를 감시합니다. 기본적으로는 이를 보고만 하며, 사용자가 설정을 켜야만 서비스를 시작합니다. 1.0.3 버전부터는 알림에 서비스를 의도적으로 일시 정지하는 방법이 명시되어 있으며, 런북에도 동일한 내용이 기재되어 있습니다.