AWS/EC2에서 Ubuntu 12.04를 실행 중인데 호스트 충돌이 많이 발생했습니다. 코어 덤프를 활성화하려고 하는데 커널 패닉을 시뮬레이션할 때 .crash 파일이 파일 시스템 어디에도 기록되지 않습니다.
나는 여기의 지침을 따랐습니다.https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
상황이 올바르게 설정된 것 같습니다.
# cat /proc/cmdline
root=LABEL=cloudimg-rootfs ro console=hvc0 crashkernel=384M-2G:64M,2G-:128M
# dmesg |grep crash
[ 0.000000] Command line: root=LABEL=cloudimg-rootfs ro console=hvc0 crashkernel=384M-2G:64M,2G-:128M
[ 0.000000] Reserving 64MB of memory at 832MB for crashkernel (System RAM: 1708MB)
[ 0.000000] Kernel command line: root=LABEL=cloudimg-rootfs ro console=hvc0 crashkernel=384M-2G:64M,2G-:128M
# cat /sys/kernel/kexec_crash_loaded
1
하지만 실행하면:
# echo c | sudo tee /proc/sysrq-trigger
시스템이 예상대로 다시 시작되지만 어떤 종류의 "충돌" 파일도 생성되지 않습니다. 내가 무엇을 잘못할 수 있었나요?
답변1
kdump init 스크립트가 활성화되어 있는지 확인하십시오. kexec_crash 패키지는 initscript를 사용하여 일반적인 시작 루틴을 우회합니다. 현재 호출이 init
충돌로 인해 호출된 호출인지 확인하고 이를 사용하여 실제 다시 시작을 수행하기 전에 이전 실행 상태 덤프가 필요한지 여부를 결정합니다.
즉, 테스트 시스템이 64Mb를 수용할 만큼 작지 않고 충돌이 발생할 때마다 전체 메모리가 줄어드는 것을 알지 못한다면 그렇지 않을 수도 있습니다.
확인해야 할 가장 중요한 것은 두 번째가 init
발사되는지 여부입니다. 시스템 충돌 직후 콘솔에 initscript 시작 시퀀스가 표시되어야 합니다.이전 재부팅 없음.
- 이런 일이 발생하지 않으면 크래시 커널이 전혀 실행되지 않습니다.
- 이런 일이 발생하고 프롬프트가 표시되면 init 스크립트가 해당 작업을 수행하지 않은 것입니다. (충돌 후 상태가 활성화되거나 감지되지 않음)
- 이런 일이 발생하면 두 번째가
init
실행되고 시스템이 재부팅되어init
시작됩니다 .다시하지만 여전히 파일이 없습니다... kdump initscript가 다시 시작되기 전에 무슨 일이 일어나고 있는지 문제를 해결해야 합니다. 아이러니하게도 더 좋은 방법 중 하나는 initscript를 비활성화하고 명령을 수동으로 실행하는 것입니다. (참고: 이 작업을 시도하기 전에 서비스가 충돌한 커널의 메모리에 적합한지 확인하세요!)