Nhật ký hoảng loạn hạt nhân ở đâu?

Tôi đã gặp vấn đề với Handbrake / ffmpeg. Sau ~ 5 phút chuyển mã, máy tính khóa lại. Tôi khá chắc chắn rằng đó là một cơn hoảng loạn hạt nhân vì mũ khóa bắt đầu nhấp nháy.

Có một vài câu hỏi logic về những việc cần làm và một số về các lỗi cụ thể nhưng tôi thực sự sau một điều: điều gì đã xảy ra ngay trước khi mọi thứ chết?!

Tôi đã kiểm tra /var/log/kern.logvà tất cả những gì tôi thấy trong khoảng thời gian đó là tôi đang dán một đĩa DVD và sau đó vài phút, hệ thống khởi động. Không có lỗi, không có thông báo hoảng loạn.

Có cách nào để buộc hoảng loạn được đăng nhập? Tôi khá chắc chắn rằng tôi có thể tái tạo điều này (nó đã xảy ra 100% số lần tôi đã thử gần đây) vì vậy trong khi tôi thay vì "chỉ hoạt động", tôi đủ hạnh phúc để khởi động lại một vài lần nếu điều đó có nghĩa là tôi có thể tìm ra nguyên nhân của sự hoảng loạn.

Tất cả nhật ký hệ thống của bạn trong Ubuntu được xử lý theo rsyslogđó giữ cấu hình của nó trong /etc/rsyslog.confvà /etc/rsyslog.d/.

Để biết thêm thông tin về cách cấu hình rsyslogvà các tùy chọn có thể truy cập rsyslog.conf man page.

Mở ra /etc/rsyslog.d/50-default.confbạn có thể thấy một trong những dòng chứa

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

Có nghĩa là tệp bạn đang tìm kiếm trong trường hợp này là bất kỳ /var/log/syslognhật ký khổng lồ nào bạn có thể sẽ có.

Bạn có thể thấy rằng tên tệp cũng bắt đầu bằng a -, điều này có nghĩa là tệp được lưu trong bộ nhớ cache trước khi viết, nó rất tuyệt nhưng có thể để lại cho bạn một nhật ký xấu, điều bạn muốn là nhật ký được viết ngay khi có vấn đề. Xóa dấu gạch ngang và khởi động lại hoặc tải lại rsyslogvà sau đó làm cho máy tính của bạn gặp sự cố một lần nữa, kiểm tra /var/log/syslog.

Nếu nó thực sự là một kernel hoảng loạn thì nó sẽ không được ghi vào nhật ký thông qua các phương thức thông thường. Vì hạt nhân tại thời điểm này đã bị sập, việc ghi vào hệ thống tập tin là một hoạt động rủi ro - không còn nhiều hạt nhân có thể tin cậy được nữa, vì vậy việc ghi vào nhật ký thực sự có thể được đưa vào crap ngẫu nhiên trên bộ tải khởi động của bạn!

Thay vào đó, bạn có thể đổ nội dung của bộ nhớ vào trao đổi của mình và sau đó gỡ lỗi nó sau. Điều này được gọi là một sự cố kernel / kết xuất lõi.

Ubuntu Wiki có một CrashdumpRecipe có thể hữu ích - mặc dù có vẻ hơi lỗi thời, tôi không nghĩ quá nhiều nên đã thay đổi.

Cổng nối tiếp

Cổng nối tiếp là một cơ chế giao tiếp cấp thấp đơn giản giữa các máy tính.

Ưu điểm:

• thiết lập đơn giản một lần (nếu bạn có phần cứng)
• đáng tin cậy, vì việc truyền dữ liệu chỉ phụ thuộc vào API dây và hạt nhân đơn giản, ít có khả năng bị ảnh hưởng bởi sự hoảng loạn hơn là hệ thống con TCP / IP.

Nhược điểm:

• hầu hết các máy tính xách tay hiện đại không còn cổng nối tiếp nữa (tiếp xúc?) để tiết kiệm dung lượng. Nhưng máy tính để bàn và máy ảo vẫn làm.
• bạn cũng cần một máy tính thứ hai có cổng nối tiếp để nhận dữ liệu, nhưng đây là trường hợp cơ bản cho tất cả các bảng phát triển nhúng như Raspberry Pi.
• bị giới hạn bởi độ dài của cáp nối tiếp lớp vật lý, không giống như các mạng TCP / IP không giới hạn. Tuy nhiên, điều này có thể được xử lý xung quanh với một thiết bị có giao diện giữa nối tiếp và TCP / IP. Nhưng có những thiết bị chuyển đổi giữa hai.

Cổng nối tiếp trông như thế này:

và trên RPI có sẵn thông qua GPIO.

Sau đó, nếu bạn có phần cứng cần thiết, hãy kết nối từ máy tính thứ hai với máy tính chính bằng:

screen /dev/ttyS0 115200

Điều này thực sự cung cấp cho bạn một vỏ.

Sau đó vào máy chính, bắt đầu thao tác mà hoảng loạn.

Khi sự hoảng loạn xảy ra, bãi chứa hoảng loạn được truyền trực tiếp đến máy thứ hai và bạn có thể thấy tất cả bằng cách cuộn lên trên thiết bị đầu cuối.

Các phương pháp khác

Ngoài ra còn có các phương pháp khác khắc phục các hạn chế phần cứng được đề cập ở trên, với chi phí phức tạp hơn và kém tin cậy hơn. Phương pháp đáng chú ý:

• netdump: truyền sự hoảng loạn qua TCP / IP. Dựa vào hệ thống con TCP / IP không bị hỏng.
• kdump: dường như là cơ chế cơ bản của linux-crashdump được đề cập tại: https://askubfox.com/a/104793/52975 Khởi động kernel Linux thứ hai để kiểm tra kernel bị lỗi. Cái gì có thể đi sai?! :-)

Xem thêm câu trả lời tuyệt vời này: https://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic

Bước gỡ lỗi

Cuối cùng, nhận được đầu ra hoảng loạn đòi hỏi một số chức năng hạt nhân hoạt động và bất kỳ chức năng hạt nhân nào cũng có thể bị hỏng bởi sự hoảng loạn.

Nhưng ai cần hoảng loạn nếu bạn có thể sử dụng GDB trên kernel? Nếu bạn là người khó tính, hãy xem:

• QEMU hoặc các máy ảo khác: https://stackoverflow.com/a/42316607/895245
• JTAG

Mọi vấn đề đều rơi khi bạn có tầm nhìn đầy đủ (và đủ thời gian!).