커널 패닉 로그는 어디에 있습니까?

핸드 브레이크 / ffmpeg에 문제가 있습니다. ~ 5 분 코드 변환 후 컴퓨터가 잠 깁니다. Caps-Lock이 깜박이기 때문에 커널 패닉이라고 확신합니다.

이 할 특정 버그에 대한 몇 가지 할 작업에 대한 몇 가지 논리적 인 질문이 있습니다하지만 난 정말 한 가지 후 해요 : 모든 죽기 전에 무엇을 잘 있었나요?!

확인한 /var/log/kern.log결과 시간이 지남에 따라 DVD에 꽂힌 다음 몇 분 후에 시스템이 부팅됩니다. 오류, 공황 통지 없음.

공황을 강제로 기록 할 수있는 방법이 있습니까? 나는 이것을 재현 할 수 있다고 확신합니다 (최근에 시도한 시간의 100 %가 발생했습니다). 공황의 원인을 찾으십시오.

우분투의 모든 시스템 로그가 처리 rsyslog에 구성을 유지하는 /etc/rsyslog.conf과 /etc/rsyslog.d/.

구성 방법 rsyslog및 가능한 옵션 에 대한 자세한 내용을 보려면를 방문하십시오 rsyslog.conf man page.

열면 /etc/rsyslog.d/50-default.conf선 중 하나에

*.*;auth,authpriv.none -/var/log/syslog*

이 경우 찾고있는 파일 /var/log/syslog이 아마도 거대한 로그 중 하나라는 것을 의미합니다 .

파일 이름도로 시작 -한다는 것을 알 수 있습니다. 이것은 파일이 쓰기 전에 캐시된다는 것을 의미하지만, 로그가 잘못 될 수 있습니다. 원하는 것은 문제가 발생하자마자 로그가 작성되는 것입니다. 대시를 제거하고 재부팅 또는 다시로드 rsyslog한 다음 컴퓨터가 다시 충돌하게하려면을 확인하십시오 /var/log/syslog.

그것이 실제로 커널 패닉이라면 정상적인 방법으로 로그에 기록되지 않습니다. 이 시점에서 커널이 다운되었으므로 파일 시스템에 쓰는 것은 위험한 작업입니다. 더 이상 커널을 신뢰할 수 없으므로 로그에 쓰면 실제로 부트 로더에 임의의 크랩이 발생할 수 있습니다!

대신 메모리 내용을 스왑에 덤프 한 다음 나중에 디버깅 할 수 있습니다. 이것을 커널 충돌 / 코어 덤프라고합니다.

Ubuntu Wiki에는 CrashdumpRecipe 가 유용 할 수 있습니다. 약간 오래된 것으로 보이지만 너무 많이 바뀌지 않았다고 생각합니다.

시리얼 포트

직렬 포트는 컴퓨터 간의 간단한 저수준 통신 메커니즘입니다.

장점 :

• 한 번의 간단한 설정 (하드웨어가있는 경우)
• 데이터 전송은 단순한 와이어 및 커널 API에만 의존하기 때문에 TCP / IP 하위 시스템보다 패닉의 영향을 덜받습니다.

단점 :

• 대부분의 최신 랩탑에는 공간을 절약하기 위해 더 이상 직렬 포트가 없습니다 (노출 되었습니까?). 그러나 데스크톱과 가상 머신은 여전히 ​​그렇습니다.
• 또한 데이터를 수신하려면 직렬 포트가있는 두 번째 컴퓨터가 필요하지만 기본적으로 Raspberry Pi와 같은 모든 내장 개발 보드의 경우입니다.
• 무제한 TCP / IP 네트워크와 달리 물리 계층 직렬 케이블의 길이에 의해 제한됩니다. 그러나 이것은 직렬과 TCP / IP 사이에서 인터페이스하는 장치로 해결할 수 있습니다. 그러나 둘 사이를 변환하는 장치가 있습니다.

직렬 포트는 다음과 같습니다.

RPI에서 GPIO를 통해 사용할 수 있습니다.

그런 다음 필요한 하드웨어가 있으면 다음을 사용하여 두 번째 컴퓨터에서 기본 컴퓨터로 연결하십시오.

screen /dev/ttyS0 115200

이것은 실제로 쉘을 제공합니다.

그런 다음 주 시스템에서 패닉 작업을 시작하십시오.

패닉이 발생하면 패닉 덤프가 두 번째 머신으로 스트리밍되고 터미널에서 위로 스크롤하여 모두 볼 수 있습니다.

다른 방법

더 복잡하고 신뢰성이 떨어지면서 위에서 언급 한 하드웨어 제한을 극복하는 다른 방법들도 있습니다. 주목할만한 방법 :

• netdump : TCP / IP를 통해 패닉을 스트리밍합니다. 손상되지 않은 TCP / IP 서브 시스템에 의존합니다.
• kdump : https://askubuntu.com/a/104793/52975 다음에 언급 된 linux-crashdump의 기본 메커니즘 인 것으로 보입니다 . 충돌 한 커널을 검사하기 위해 두 번째 Linux 커널을 부팅합니다. 무엇이 잘못 될 수 있습니까?! :-)

이 위대한 답변을 참조하십시오 : https://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic

단계 디버깅

궁극적으로 패닉 출력을 얻으려면 일부 커널 기능이 작동해야하며 모든 커널 기능이 패닉에 의해 손상 될 수 있습니다.

그러나 커널에서 GDB를 사용할 수 있다면 누가 패닉을 필요로합니까? 그 하드 코어라면 다음을 살펴보십시오.

• QEMU 또는 기타 VM : https://stackoverflow.com/a/42316607/895245
• JTAG

가시성이 충분하고 시간이 충분하면 모든 문제가 해결됩니다.