다음을 통해 공유

Azure Linux VM의 커널 패닉

  • 아티클

이 문서에서는 커널 패닉으로 이어질 수 있는 여러 조건에 대해 설명하고 문제 해결 지침을 제공합니다.

일반적으로 커널 패닉은 커널이 제대로 로드되지 않아 시스템이 부팅되지 않는 상황입니다. 커널 패닉의 또 다른 형태는 커널이 중지하여 자신을 처리하고 보호하는 방법을 모르는 상황이 발생할 때 발생합니다.

필수 구성 요소

직렬 콘솔이 Linux VM에서 사용하도록 설정되고 작동하는지 확인합니다.

커널 패닉을 식별하는 방법

Azure Portal 사용하여 부팅 진단 블레이드, 직렬 콘솔 블레이드 또는 AZ CLI에서 VM의 직렬 콘솔 로그 출력을 확인하여 특정 커널 패닉 문자열을 식별합니다.

커널 패닉은 아래 출력과 유사하며 직렬 콘솔 로그의 끝에 표시됩니다.

Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[  300.206297] Kernel panic - xxxxxxxx
[  300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.xxx.x86_64 #1

가장 일반적인 커널 패닉 이벤트 중 일부:

패닉 메시지 이유
Oops: 0000 [#1] SMP " (자세한 내용은 로그 검사) 잘못된 주소를 역참조하여 시스템이 당황했습니다.
SysRq: 크래시덤프 트리거 코어 덤프는 sysrq-c를 사용하거나 c를 /proc/sysrq-trigger에 에코하여 사용자가 시작했습니다.
<pathname/filename>:<line number>! 이 형식은 실패한 BUG 검사 대한 표준입니다(ASSERT와 비슷하지만 논리는 반전됨). 파일 이름 및 줄 번호는 실패한 BUG 검사 나타냅니다.
커널 패닉 - 동기화되지 않음: softlockup: 중단된 작업 소프트 잠금 탐지기에서 일시 잠금 임계값 내에서 Watchdog 작업을 예약하지 않은 CPU를 발견했습니다.
커널 패닉 - 동기화되지 않음: Watchdog이 cpu 0에서 하드 LOCKUP을 감지했습니다. 하드 잠금 탐지기에서 하드 잠금 임계값 내에서 hrtimer 인터럽트 수신되지 않은 CPU를 발견했습니다.
커널 패닉 - 동기화되지 않음: hung_task: 차단된 작업 중단된 작업 감시가 차단된 작업 시간 제한 값 이상에 대해 무정전 상태인 하나 이상의 작업을 검색했습니다.
커널 패닉 - 동기화되지 않음: 메모리 부족. panic_on_oom 선택됨 시스템에서 메모리와 스왑이 부족하여 메모리를 해제하기 위해 프로세스를 종료해야 했습니다(기본 동작이 아님).
커널 패닉 - 동기화되지 않음: 메모리 부족 및 종료 가능한 프로세스 없음... 시스템이 메모리와 스왑이 부족하고 메모리를 확보하기 위해 프로세스를 죽이고 있지만 종료할 프로세스가 부족합니다.
커널 패닉 - 동기화되지 않음: NMI가 발생했습니다. 자세한 내용은 통합 관리 로그를 참조하세요. Watchdog가 NMI(마스크할 수 없는 인터럽트)를 차단했습니다.
커널 패닉 - 동기화되지 않음: NMI IOCK 오류: 계속되지 않음 시스템에서 하드웨어에서 IO 검사 NMI를 수신했으며(메모리 패리티 오류가 아님) kernel.panic_on_io_nmi 설정되었습니다(기본값이 아님).
커널 패닉 - 동기화 안 됨: NMI: 계속되지 않음 시스템에서 NMI(하드웨어 또는 메모리 패리티 오류)를 받았고 kernel.panic_on_unrecovered_nmi 설정되었습니다(기본값이 아님).
커널 패닉 - 동기화되지 않음: nmi watchdog 시스템에서 NMI를 받았고 kernel.panic_on_timeout 또는 kernel.panic_on_oops 설정되었습니다(기본값이 아님).
커널 패닉 - 동기화되지 않음: 심각한 컴퓨터 검사 심각한 상태에 대한 컴퓨터 검사 예외 이벤트가 발생했습니다.
커널 패닉 - 동기화되지 않음: init를 죽이려고 했습니다! init 프로세스는 시작할 첫 번째 프로세스이며 종료해서는 안 됩니다.

시나리오 1: 부팅 시 커널 패닉 발생

부팅 시 커널 패닉으로 인해 VM이 운영 체제 시작 프로세스를 완료하지 못하게 됩니다. 가상 머신이 시작될 때마다 발생하며 로그인을 허용하지 않습니다.

이러한 종류의 이벤트는 일반적으로 관련이 있지만 다음으로 제한되지는 않습니다.

시나리오 1에 대한 해결 방법

이러한 종류의 커널 패닉을 처리하기 위해 다음 방법을 사용할 수 있습니다.

방법 1: Azure 직렬 콘솔 사용

Azure 직렬 콘솔을 사용하여 부팅 프로세스를 중단하고 사용 가능한 경우 이전 커널 버전을 선택합니다. 이렇게 하면 VM이 다시 부팅될 수 있으며, 다음 방법 중 하나를 사용하여 부팅되지 않는 커널과 관련된 특정 문제를 해결할 수 있습니다.

방법 2: 구조 VM을 사용하여 오프라인 복구

Azure 직렬 콘솔을 사용할 수 없거나 이전 커널을 사용할 수 없는 경우 오프라인 복구를 수행하려면 복구/복구 VM이 필요합니다.

VM 복구 명령을 사용하여 대상 VM의 OS 디스크 복사본이 연결된 복구 VM을 만듭니다. 그런 다음 복구 VM에서 OS 파일 시스템의 복사본을 chroot 탑재를 사용합니다. 그런 다음 다음 메서드를 사용하여 커널 문제를 해결합니다.

시나리오 2: 런타임 시 커널 패닉

이러한 종류의 커널 패닉은 일반적으로 운영 체제 시작 프로세스가 완료된 후 예측할 수 없는 시간에 트리거되고 VM이 응답을 중지하여 로그인하지 못하게 합니다. 일반적으로 관련이 있지만 다음으로 제한되지는 않습니다.

시나리오 2에 대한 해결 방법

이러한 종류의 커널 패닉을 처리하기 위해 다음 방법을 사용할 수 있습니다.

  • 리소스 사용량 및 전반적인 시스템 성능을 검토합니다. 커널 패닉은 VM 크기 조정으로 이어질 수 있는 리소스 부족과 관련이 있을 수 있습니다.
  • 가능하면 해당 Linux 배포 리포지토리에서 사용할 수 있는 최신 업데이트를 설치합니다. 커널 패닉은 커널 또는 다른 소프트웨어의 알려진 버그와 관련이 있을 수 있습니다.
  • 커널 패닉이 최근 커널 변경과 관련이 있을 가능성이 있습니다. 이 경우 시나리오 1의 해결에 설명된 대로 이전 커널 버전을 통해 부팅하는 것이 좋습니다.
  • 위의 옵션을 적용할 수 없는 경우 추가 분석을 지원하기 위해 kdump를 구성하고 코어 덤프를 생성해야 할 수 있습니다.

보다 구체적인 커널 패닉 시나리오

특정 문제 해결/복구 지침이 포함된 일반적인 커널 패닉 시나리오:

문서 시나리오
호스트 노드 업그레이드 후 3.10 기반 커널의 Azure Linux VM이 패닉 이 문서에서는 Azure에서 호스트 노드 업그레이드 후 3.10 기반 커널을 실행하는 Azure Linux VM이 충돌할 때 발생하는 문제에 대해 설명합니다.
커널 관련 부팅 문제에서 Azure Linux 가상 머신을 복구하는 방법 이 문서에서는 커널 변경 내용을 적용한 후 Linux VM(가상 머신)을 다시 시작할 수 없는 문제에 대한 솔루션을 제공합니다.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.