상태가 실패인 서비스는 즉각적인 재시작이 필요하지 않습니다. 서버에서 이러한 습관은 가끔 고장을 설명하는 메시지를 지우거나 여전히 잘못된 구성으로 프로그램을 다시 시작하는 경우가 있습니다.
먼저 영향을 받는 유닛을 식별하고, 그 상태와 로그를 읽은 후 원인을 수정하십시오. 재시작은 그 후에 이루어집니다.
실제 실패한 유닛 나열하기
이 명령어는 systemd가 실패한 것으로 간주하는 서비스와 유닛을 표시합니다 :
systemctl --failed전체 이름을 기록하십시오, 예를 들어 nginx.service 또는 mon-application.service. exited 된 유닛이 반드시 고장난 것은 아닙니다: 일부 서비스는 짧은 작업을 수행한 후 정상적으로 종료됩니다. failed 상태는 시작, 제어 명령 또는 모니터링된 프로세스가 오류로 종료되었음을 나타냅니다.
활성, 정지된 서비스 및 그 상태를 다시 보려면 systemctl로 서비스 목록 확인하기를 참고하십시오.
재시작 전에 서비스 상태 확인하기
유닛에 nginx를 대신하십시오. --no-pager 옵션은 결과를 터미널에 직접 출력하여 SSH 세션에서 less에 머무르지 않도록 합니다.
sudo systemctl status nginx --no-pager특히 Active:, 종료 코드 및 표시된 마지막 줄을 주의 깊게 보십시오. 이미 점유된 포트, 누락된 경로, 읽을 수 없는 인증서 또는 잘못 입력된 지시어가 여기에 종종 나타납니다. 서비스가 자체 검증기를 가진 이진 파일을 시작하는 경우, 먼저 그 검증기를 실행하십시오. 예를 들어 Nginx의 경우 :
sudo nginx -tNginx를 사용하지 않는 머신에서 이 명령어를 실행하지 마십시오. 각 서비스는 검증 구문이 다릅니다.
journalctl로 오류 메시지 확인하기
systemctl status는 오직 일부분만 보여줍니다. 유닛의 로그는 전체 맥락을 제공합니다 :
sudo journalctl -u nginx -b --no-pager
sudo journalctl -u nginx -n 50 --no-pager-b는 현재 부팅에 대한 검색을 제한합니다. -n 50은 고장이 더 오래된 경우 마지막 50줄을 유지합니다. 실시간으로 재시작을 따라가려면 두 번째 SSH 세션에서 sudo journalctl -fu nginx를 사용하십시오. journalctl과 마지막 부팅 메시지 가이드는 오류가 여러 서비스에 영향을 줄 때 진단을 확대하는 데 도움이 됩니다.
수정, 재시작, 그리고 체크하기
유닛 파일이나 systemd의 drop-in을 수정한 후에는 설정을 다시 로드하십시오. 이 단계는 서비스를 재시작하지 않습니다.
sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl is-active nginx
systemctl --failedis-active는 active로 응답해야 합니다. 서비스가 포트에서 수신 대기하고 있다면 포트도 확인하고 올바른 클라이언트에서 테스트하십시오. active 응답은 웹 애플리케이션, 프록시 또는 데이터베이스가 이미 요청을 수락하고 있음을 보장하지 않습니다.
중요한 서비스의 경우 재시작 전에 두 번째 SSH 세션을 열어 두고 오류를 정확하게 복사하여 티켓이나 메모에 기록해 두십시오. 다음 사건에서 동일한 진단을 반복하지 않을 수 있습니다.