systemd 종료 시 재부팅 중에 멈추는 SUSE Linux 서버 문제 해결

SUSE Linux 서버가 systemd 종료 메시지에서 재부팅 중에 멈추는 것처럼 보일 경우, 재부팅 명령 자체에 문제가 있는 것은 아닌지 먼저 확인하는 것이 좋습니다. 대부분의 경우 systemd는 특정 유닛, 마운트, 프로세스 또는 종료 후크가 완료되기를 기다리고 있습니다. 따라서 가장 안전한 해결책은 종료 시간 제한을 전체적으로 단축하는 대신, 여전히 실행 중인 정확한 작업을 파악하고, 해당 작업이 중지되지 않는 이유를 검사한 후, 해당 구성 요소를 수정하는 것입니다.

이 가이드 에서는 가상의 예시를 사용합니다 . 예를 들어, 라는 이름의 서버가 lab-sles01SUSE Linux Enterprise Server를 실행하고 재부팅 중에 와 유사한 메시지와 함께 일시 중단되는 상황을 가정합니다 A stop job is running for backup.service. 이 예시는 진단 방법을 설명하기 위한 예시일 뿐이며, 실제 테스트 결과나 특정 SUSE 릴리스의 이라는 서비스에 결함이 있다는 주장을 나타내는 것은 아닙니다 backup.service.

4단계 해결법 간략히 설명하자면

1단계: 종료가 정확히 어디에서 멈추는지 기록합니다.

계획된 재부팅 중에 로컬 콘솔, 가상 머신 콘솔, BMC/IPMI 콘솔 또는 하이퍼바이저 콘솔을 모니터링하십시오. "systemd가 멈췄습니다"와 같은 일반적인 설명보다는 장치 이름이 표시된 줄이 훨씬 더 유용합니다. 예를 들어 , 다른 장치는 이미 종료되었지만 lab-sles01콘솔에 systemd가 여전히 중지 중이라고 표시되는 경우를 생각해 보십시오 .backup.service

예시: 종료 콘솔은 backup.servicesystemd가 여전히 기다리고 있는 장치를 식별합니다.

콘솔에 .mount단위, 네트워크 파일 시스템, 장치 또는 다른 서비스의 이름이 표시되면 일반적인 서비스 시간 초과를 적용하기보다는 해당 이름을 따라가십시오. 콘솔 하단에 표시되는 단위는 단서일 뿐 근본 원인이 아닙니다. 해당 단위 자체가 자식 프로세스, 스토리지, 네트워크 I/O 또는 다른 종속성을 기다리고 있을 수도 있습니다.

SUSE의 최신 systemd 안내에 따르면 재부팅이나 전원 끄기가 오래 걸리는 원인은 서비스가 종료되지 않았기 때문일 수 있으며 systemd 작업을 확인하는 것이 좋습니다. 자세한 내용은 SUSE Linux Enterprise Server 16.0: systemd 기본 사항 소개를 참조하십시오 .

2단계: 서버가 반환된 후 이전 부팅 저널을 사용합니다.

시스템이 다시 부팅되면 방금 발생한 종료 과정을 확인하십시오. SUSE는 저널에 부팅 오프셋을 기록합니다. `boot` 0는 현재 부팅, `-v` -1는 이전 부팅 등을 나타냅니다. 다음 항목부터 시작하십시오.

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

규모가 큰 일기장의 경우, 역순으로 정렬하면 최근 메시지를 더 빨리 찾을 수 있습니다.

sudo journalctl -b -1 -r

예시: 이전 부팅 로그에는 가상의 백업 서비스가 SIGTERM 신호를 수신한 후 시간 초과되는 내용이 표시됩니다.

Stopping, stop job, timed out, Failed with result, Unmounting, , 또는 의심스러운 서비스 자체에서 보낸 메시지 와 같은 문구를 찾아보세요 Dependency failed. 장치 이름을 알게 되면 검색 범위를 좁힐 수 있습니다.

sudo journalctl -b -1 -u backup.service

SUSE는 SLES 15 SP7 저널 문서journalctl -b -1 에서 이전 부팅 분석을 위한 문서를 제공합니다 . 이전 부팅 기록이 없는 경우, 누락된 기록에서 섣부른 결론을 내리지 마십시오. journald 저장소 구성 방식을 확인하고 콘솔 또는 원격 로깅을 사용하여 다음 재현을 진행하십시오.journalctl --list-boots

3단계: 차단 요소가 서비스, 마운트, 억제기 또는 지연 종료 후크인지 확인합니다.

유지 관리 기간 동안 문제를 재현할 수 있다면 두 번째 관리 콘솔을 준비해 두십시오. 연결이 끊어지기 전에 다음 명령을 실행하십시오.

sudo systemctl list-jobs
sudo systemctl status backup.service

예시: backup.service재부팅 대상이 뒤에서 대기하는 동안 중지 작업이 실행 중입니다.

상위 systemd 디버깅 지침에 따르면, 로 표시된 작업이 running완료되어야 종속 작업이 waiting진행될 수 있습니다. SUSE는 또한 systemctl list-jobs종료 또는 재부팅에 시간이 너무 오래 걸리는 경우에도 이 명령을 사용할 것을 권장합니다. 따라서 이 명령은 서버가 완전히 멈추지 않고 PID 1이 여전히 응답 중인 경우에 특히 유용합니다.

서비스가 너무 느리게 종료되는 경우

장치 정의 및 종료 동작을 검사하십시오.

sudo systemctl cat backup.service
sudo systemctl status backup.service
sudo journalctl -u backup.service -b

서비스에 ExecStop=작업이 있는지, 해당 프로세스가 SIGTERM 신호를 처리하는지, 스토리지 또는 네트워크 리소스를 기다리고 있는지 확인하십시오. 데이터베이스, 백업 에이전트 또는 미들웨어 서비스는 데이터를 플러시하는 데 시간이 필요할 수 있으므로 서비스를 더 빨리 종료한다고 해서 자동으로 문제가 해결되는 것은 아닙니다.

마운트 또는 네트워크 파일 시스템이 관련된 경우

마운트 해제 작업 실패 원인을 찾고 마운트 소스를 확인하십시오.

findmnt
systemctl list-units --type=mount
sudo journalctl -b -1 | grep -Ei 'unmount|umount|mount|nfs|cifs'

NFS 또는 CIFS의 경우 서버 연결 가능성, 만료된 세션, 마운트 옵션이 서버 종료 요구 사항을 충족하는지 여부를 확인하십시오. 차단된 유닛이 에서 발생한 경우 /etc/fstab, 관련 없는 유닛에 서비스별 시간 초과를 적용하는 대신 마운트 구성을 수정하십시오.

재부팅 요청이 차단된 경우

시스템 종료가 시작되기 전에 활성화된 systemd 억제기 목록을 확인할 수 있습니다.

systemd-inhibit --list

억제기 잠금은 애플리케이션이 중단되어서는 안 되는 작업을 수행하는 동안 종료 요청을 차단하거나 지연시킬 수 있습니다. 이는 시스템이 최종 종료 시퀀스에 진입하기 전에 재부팅 요청 자체가 지연될 때 가장 중요합니다. 자세한 내용은 상위 systemd-inhibit 매뉴얼을 참조하십시오 .

서비스가 이미 중단된 후에 멈춤 현상이 발생하는 경우

시스템 종료 후반 단계에서 발생하는 멈춤 현상은 별도의 조사가 필요합니다. systemd는 /usr/lib/systemd/system-shutdown/최종 재부팅 또는 전원 끄기 직전에 실행 파일을 실행하고 해당 실행 파일이 완료될 때까지 기다립니다. 저널과 콘솔에 일반 서비스는 이미 중지되었고 멈춤 현상이 최종 종료 단계에서 발생하는 것으로 나타난다면, 해당 디렉터리와 벤더에서 설치한 훅을 검토하십시오. systemd 종료 서비스 관련 문서에서 이러한 동작을 설명하고 있습니다.

4단계: 구성 요소를 수정한 후 정상적으로 재부팅하여 테스트합니다.

가상 상황으로 돌아가 보겠습니다 lab-sles01. 로그를 보면 backup.service백업 프로세스가 이미 완료된 후에도 정상적인 종료를 무시하는 것으로 나타납니다. 첫 번째 선택지는 서비스 또는 서비스 종료 명령을 수정하는 것입니다. 서비스가 일정 시간 후 안전하게 종료될 수 있는 것으로 알려져 있다면, 시스템d의 대기 시간을 단위별로 제한하는 시스템d 오버라이드를 사용할 수 있습니다.

벤더 유닛을 편집하는 대신 재정의를 생성하세요 /usr/lib/systemd/system.

sudo systemctl edit backup.service

예를 들어:

[Service]
TimeoutStopSec=30s

그런 다음 systemd의 유닛 구성을 다시 로드합니다.

sudo systemctl daemon-reload

예시: 서비스별 타임아웃은 가상의 서비스가 차단 요인으로 식별된 후에만 적용됩니다.

30초라는 값을 맹목적으로 복사하지 마십시오. 적절한 타임아웃 시간은 실제 서비스가 안전하게 완료되어야 하는 시점에 따라 달라집니다. 데이터베이스, 스토리지 데몬, 클러스터 서비스 또는 백업 프로세스의 경우 타임아웃 시간을 줄이면 정상적인 정리 작업이 중단될 수 있습니다. 타임아웃은 안전장치일 뿐이며, 잘못된 ExecStop=동작이나 제대로 종료되지 않는 애플리케이션을 수정하는 것을 대체할 수 없습니다.

변경 사항에 만족하시면 정상적인 재부팅을 테스트해 보세요.

sudo systemctl reboot

기기가 다시 부팅되면 이전 부팅 과정을 다시 검토하여 기기가 콘솔에서 단순히 사라진 것이 아니라 정상적으로 종료되었는지 확인하십시오.

강제 재부팅은 언제 사용해야 할까요?

강제 재부팅은 복구 옵션이지 문제 해결 전략이 아닙니다. systemd 공식 문서에 따르면 강제 재부팅은 일반적인 서비스 종료 --force는 systemctl reboot건너뛰지만 프로세스를 종료하고 파일 시스템을 읽기 전용으로 마운트 해제하거나 다시 마운트하려고 시도합니다. 강제 재부팅 옵션을 --force두 번 제공하면 프로세스를 종료하거나 파일 시스템을 마운트 해제하지 않고 재부팅될 수 있으므로 데이터 손실 위험이 있습니다.

서버가 이미 멈춰버렸고 서비스를 복구할 더 안전한 방법이 없는 경우, 운영 절차에 따라 강제 재부팅이 정당화될 수 있습니다.

sudo systemctl reboot --force

systemctl reboot --force --force가상 전원 재부팅이나 물리적 재설정을 일반적인 해결 방법으로 취급하지 마십시오 . 이러한 조치는 필요한 증거를 제거할 수 있으며 진행 중인 쓰기 작업을 위험에 빠뜨릴 수 있습니다. 상위 systemctl 문서에서는 단일 강제 실행과 이중 강제 실행 동작을 명확하게 구분하고 있습니다.

재부팅할 때마다 시스템이 멈추고 일반 모드에서 문제 해결이 불가능하다면 어떻게 해야 할까요?

유지보수 콘솔을 사용하고 복구 모드로 부팅하십시오. SUSE는 systemd.unit=rescue.targetGRUB 편집기에서 커널 명령줄을 추가하는 방법에 대한 문서를 제공합니다. 복구 모드는 네트워크를 비활성화한 상태로 로컬 파일 시스템과 핵심 서비스에 대한 루트 세션을 제공하므로 문제가 있는 서비스 또는 마운트 구성을 비활성화하거나 복구하는 데 도움이 될 수 있습니다.

공식 복구 모드 절차는 SLES 15 SP7 관리 가이드를 참조하십시오 . 특정 패키지, 커널, 드라이버 또는 스토리지 변경 후에만 문제가 발생하는 시스템의 경우, 영구적인 시간 초과 변경을 하기 전에 관련 SUSE 유지 관리 기록을 검토하십시오.

빠른 의사 결정표

결론적으로

SUSE Linux 서버가 systemd 종료 시 멈추는 경우, 가장 확실한 해결책은 systemd가 대기 중인 작업을 식별하고 해당 작업 또는 그 종속성을 수정하는 것입니다. 종료 메시지를 기록하고, 검사하고 journalctl -b -1, 도구를 사용하여 systemctl list-jobs차단 systemctl status요인을 격리한 다음, 서비스별 타임아웃 또는 마운트 구성을 변경하십시오. 강제 재부팅은 복구 상황에만 사용하고, 일상적인 운영에는 사용하지 마십시오.