systemd 종료 화면에서 멈추는 SUSE 서버 진단하기

SUSE Linux Enterprise Server가 systemd 종료 중에 멈추는 경우, 실행 중인 종료 작업이 있는 유닛을 확인하거나 이전 부팅 시 마지막 메시지를 검사하여 해당 유닛 또는 그 종속성을 수정하십시오. 유닛은 서비스나 마운트와 같은 systemd에서 관리하는 리소스이며, 종료 작업은 systemd가 해당 유닛을 종료하도록 요청하는 것입니다. 전역 시간 초과 값을 줄이거나 강제로 전원을 끄는 것은 첫 번째 해결 방법으로 사용하지 마십시오. 서비스나 파일 시스템이 여전히 파일을 닫거나 데이터를 기록하고 있을 수 있습니다.

이 안내서는 2026년 10월에 확인된 SLES 15 SP7 문서를 기준으로 작성되었습니다. 정확한 중지 정책은 서비스 및 스토리지 공급업체에 따라 다르므로, 장치별 변경 사항이 있는 경우 해당 공급업체의 지침을 따르십시오.

1. 안전하게 전원을 차단하십시오.

1단계: 정확한 메시지를 기록하고 유용한 증거를 기다립니다.

콘솔에 "…에 대한 중지 작업이 실행 중입니다"라는 메시지와 함께 카운트다운이 표시되면, 해당 서비스 또는 마운트의 이름과 타이머 변경 여부를 기록해 두십시오. 이는 systemd가 해당 장치의 중지 작업을 기다리고 있다는 의미이며, 반드시 운영체제가 충돌했다는 것을 의미하는 것은 아닙니다. 데이터베이스나 원격 저장소는 정상적으로 종료되는 데 시간이 걸릴 수 있습니다.

원격 또는 시리얼 콘솔, 혹은 다른 사용 가능한 터미널을 통해 관찰하십시오. 쓰기 작업이 진행 중일 때는 재설정 또는 전원 명령을 실행하지 마십시오. 시스템이 응답하지 않으면 마지막으로 표시된 줄을 기록하고 시스템 부팅 후 작업을 계속하십시오.

2. 대기 중인 유닛을 찾으세요

2단계: 시스템이 여전히 명령을 수락하는지 확인하기 위해 systemd 작업을 검사합니다.

SSH 또는 두 번째 터미널이 여전히 작동하는 경우 systemd에 실행 중이거나 대기 중인 작업이 무엇인지 확인한 다음 화면에 표시된 장치를 확인하십시오.

sudo systemctl list-jobs
sudo systemctl status SERVICE.service

SERVICE실제 장치 이름으로 바꾸십시오 . 실행 중인 중지 작업은 검색 범위를 좁히지만 프로세스가 종료되지 않은 이유는 설명하지 않습니다. 구성을 변경하기 전에 해당 프로세스의 상태와 로그를 확인하십시오. systemd가 더 이상 응답하지 않으면 작업을 섣불리 취소하지 말고 호스트가 응답한 후 이전 저널을 검사하십시오.

3. 이전 부팅 기록을 사용하여 원인을 파악합니다.

3단계: 이전 부츠 일지의 마지막 부분을 읽으세요.

저널 은 systemd가 커널, 서비스 및 시스템 메시지에 대해 색인화한 로그입니다. 다음 부팅이 성공적으로 완료되면 기록된 부팅 목록을 확인하고 이전 부팅의 마지막 부분을 검사하십시오.

sudo journalctl --list-boots
sudo journalctl -b -1 -e

마지막 "정지 중" 메시지, 시간 초과, 재시도 또는 명명된 장치나 마운트를 찾으십시오. 마지막 줄은 단서일 뿐입니다. 종료 순서에 따라 다른 장치가 대기 상태로 남아 있을 수 있습니다. 타임스탬프와 주변 메시지를 비교해 보십시오.

4단계: 의심스러운 서비스에 대한 로그를 필터링합니다.

화면이나 저널에 서비스 이름이 표시되면 해당 장치의 이전 부팅 항목만 조회합니다. 로드된 구성도 검토하십시오.

sudo journalctl -b -1 -u SERVICE.service --no-pager
sudo systemctl cat SERVICE.service

사용자 정의 ExecStop스크립트, 무기한 대기하는 스크립트, 남아 있는 자식 프로세스 또는 애플리케이션 종료 후크의 오류가 있는지 확인하십시오. 공급업체 단위의 경우 편집하기 전에 패키지 및 구성을 지원되는 지침과 비교하십시오.

5단계: 증거가 뒷받침될 때만 마운트와 저장 장치를 점검하십시오.

저널에 마운트, 장치 또는 원격 파일 시스템이 언급된 경우 마운트 테이블과 다음 항목의 해당 항목을 검사하십시오 /etc/fstab.

sudo findmnt --verify --verbose

종료 시 NFS, CIFS, iSCSI 또는 기타 원격 종속성에 대한 연결 가능 여부와 예상되는 연결 상태를 확인하십시오. 더 이상 사용되지 않는 마운트 항목은 사용되지 않는 것을 확인한 후에만 제거하십시오. 느린 재부팅만을 근거로 실행 중인 파일 시스템을 강제로 마운트 해제하지 마십시오.

4. 원인을 숨기지 않고 해결하십시오.

6단계: 서비스를 수리하거나 문서화된 서비스 중단 정책만 조정합니다.

존재하지 않는 서비스의 경우, 먼저 종료 스크립트, 애플리케이션 구성 또는 패키지 문제를 해결하십시오. 벤더 파일을 편집하지 않고도 단위별 드롭인 옵션이 sudo systemctl edit SERVICE.service저장됩니다 . 서비스 시작 또는 중지에 대한 SUSE 문서를 참조하십시오. 이 워크로드에 대해 벤더가 승인한 값을 사용하십시오./etc/systemd/system/TimeoutSec

수정 사항을 문서화한 후, `reload systemd` 명령어를 사용하여 systemd의 유닛 정의를 다시 로드하고 `reload systemd` 명령어 sudo systemctl daemon-reload로 결과를 확인하십시오 sudo systemctl cat SERVICE.service. 타임아웃 시간을 길게 설정하면 정상적인 종료가 완료될 수 있지만, 실패한 재부팅 시간도 길어질 수 있습니다. 반대로 타임아웃 시간을 짧게 설정하면 서비스가 상태를 플러시하기 전에 종료될 수 있습니다. 특정 유닛의 결함을 숨기기 위해 전역 기본값을 변경하지 마십시오.

7단계: 다음 사고 발생 시를 대비하여 로그를 보존합니다.

SLES는 기본적으로 저널 데이터를 해당 디렉터리에 저장하며 /run/log/journal/, 해당 휘발성 디렉터리는 재부팅 시 지워집니다. journalctl -b -1이전 부팅 기록이 없는 경우, 향후 진단을 위해 영구 저널 저장 기능을 활성화하십시오.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix=/var/log/journal
sudo journalctl --flush

영구 로그는 해당 파일 시스템의 공간을 사용합니다 /var. SUSE에 따르면 저널은 기본적으로 해당 파일 시스템의 최대 10%를 사용할 수 있습니다. 특히 /var용량이 작은 경우 여유 공간과 보존 기간을 확인하십시오.

5. 예정된 다음 재부팅 시간을 확인하십시오.

8단계: 중지 작업이 완료되고 서버가 서비스 상태로 복귀했는지 확인합니다.

의심되는 원인을 해결한 후 콘솔에 접속하여 제어된 재부팅을 한 번 예약하십시오. 시스템이 다시 시작되면 이전 부팅의 최종 메시지를 확인하고 서비스의 현재 상태를 점검하십시오.

sudo journalctl -b -1 -e
sudo systemctl status SERVICE.service

서버가 동일한 장치를 기다리지 않고 종료된 후 정상적으로 부팅되고 서비스 또는 마운트가 작동하면 문제가 해결됩니다. 로그가 갑자기 중단되거나 커널, 컨트롤러 또는 하드웨어 오류가 표시되는 경우, 타임아웃 설정을 조정하는 대신 해당 로그를 보존하고 SUSE 또는 하드웨어 공급업체에 문의하여 문제를 조사하십시오.

자세한 명령 내용은 SLES 15 SP7 systemd 가이드 와 SUSE의 영구 저널 및 journalctl 필터 가이드를 참조하십시오 . 이러한 단계는 문제의 원인이 될 수 있는 요소를 식별하는 데 도움이 됩니다. 올바른 서비스, 파일 시스템 또는 하드웨어 해결 방법은 시스템 로그에 표시된 항목에 따라 달라집니다.