Kernel Oops khi VPN khởi động: bằng chứng đáng lưu giữ

Khởi động ứng dụng VPN là một mốc thời gian thuận tiện, không phải nguyên nhân, và sự phân biệt đó quyết định điều gì xảy ra tiếp theo. Khi một Oops của nhân xảy ra gần thời điểm đó, lựa chọn là giữa thu thập một báo cáo lỗi dùng được và cố tình gây lại cùng sự cố thêm năm lần trên máy chạy thật. Lưu bốn thứ trước khi khởi động lại: bản dựng nhân chính xác, dấu vết lỗi đầu tiên, trạng thái taint và mô tả ngắn về mọi thứ khác đã thay đổi trong cùng phút. Phần còn lại là diễn giải, và diễn giải có thể đợi đến khi bằng chứng nằm ở nơi an toàn.

Bắt lỗi đầu tiên, không phải dòng cuối

Oops đầu tiên trong nhật ký mới là thứ quan trọng, vì mọi lỗi về sau có thể là thiệt hại phụ từ một nhân đã không còn khỏe. Sao chép phần đầu cùng với dấu vết gọi hàm, vì phần đầu mang chỉ thị đã lỗi và trạng thái thanh ghi xác định đường đi của mã. Một báo cáo bắt đầu từ dòng cuối có rất ít giá trị với người đọc nó một tuần sau.

Nếu máy đã khởi động lại, bộ đệm nhân của lần khởi động trước thường vẫn còn trong nhật ký, miễn là lúc đó đã bật lưu trữ bền vững. Đọc nó từ tệp đã lưu thay vì tạo lại khối lượng công việc, vì lần tái hiện thứ hai có thể ghi đè thứ bạn cần. Ở nơi máy không thể giữ nhật ký qua các lần khởi động, console nối tiếp hoặc netconsole là cách duy nhất để lỗi từng hiển thị.

Chốt bản dựng trước khi đọc bất kỳ ký hiệu nào

Tên hàm và offset chỉ có nghĩa so với tệp nhị phân đã tạo ra chúng, nên ghi chuỗi phiên bản nhân và mã nhận diện bản dựng của bản phân phối cùng nhau. Tệp ký hiệu từ bản dựng khác trỏ tới dòng sai với đầy đủ tự tin, điều này tệ hơn là không có ký hiệu nào. Giữ phiên bản gói nhân, không chỉ số upstream, vì các bản phân phối chuyển ngược rất nhiều thứ.

Các mô-đun ngoài cây xứng đáng có dòng riêng trong bản ghi, vì nhân bị taint giới hạn điều người bảo trì được phép kết luận. Đọc giá trị taint thay vì suy ra từ danh sách mô-đun.

Taint khác không không phải là lời buộc tội và không làm báo cáo trở nên vô giá trị. Nó cho người đọc biết thành phần nào đã được nạp khi lỗi xảy ra, và một số cờ khiến báo cáo bị hạ ưu tiên theo chính sách chứ không theo đánh giá. Ghi lại giá trị, tên mô-đun và liệu cùng phần cứng và khối lượng công việc đó đã từng chạy nhân mà không có chúng chưa. Chính phép so sánh cuối cùng đó tách một hồi quy mới khỏi một lỗi lâu năm.

Tách yếu tố kích hoạt khỏi khiếm khuyết

Khởi động đường hầm thường dùng một đường đi đã tồn tại: trình điều khiển mạng, kỷ luật hàng đợi, tính năng offload hoặc trạng thái nguồn. Yếu tố kích hoạt giải thích lỗi xuất hiện khi nào, không phải mã nào sai, và coi yếu tố kích hoạt là nguyên nhân dẫn đến một loạt thay đổi cấu hình không sửa được gì.

Một ảnh trước đó chạy được là bằng chứng, không phải chứng minh. Khi so sánh, đổi một thành phần mỗi lần khởi động, và giữ kết quả ở nơi tồn tại lâu hơn máy.

Kiểm tra xem người bảo trì thực sự dùng được gì

Đọc báo cáo như một người lạ sẽ đọc trước khi gửi. Nếu cấu hình, trình tự chính xác và danh tính bản dựng đều có, và thông tin đăng nhập đã bị xóa, báo cáo là dùng được. Nếu đó là ảnh chụp dấu vết ngăn xếp, nó sẽ quay lại với yêu cầu đúng thông tin đó. Hướng dẫn truy tìm lỗi nhân mô tả dấu vết hữu ích và ký hiệu khớp trông như thế nào.

uname -r
cat /proc/sys/kernel/tainted
journalctl -k -b -1 --no-pager | sed -n '/BUG:/,/Call Trace/p'
dmesg -T | grep -A 40 'RIP:'

Mọi lệnh ở trên chỉ đọc trạng thái, và hai lệnh đầu nên chạy trước lần khởi động lại tiếp theo nếu máy vẫn còn trả lời được. Ở nơi nhật ký không bền, chỉ hai lệnh đó là sẽ hoạt động lại.

Xóa khóa, mật khẩu và lưu lượng không liên quan, nhưng giữ tên hàm và offset mà ai đó cần để đọc dấu vết. Gửi tài liệu qua kênh báo cáo phù hợp với bản phân phối hoặc nhân, không dùng dán công khai kèm tên máy. Sau đó chờ một câu hỏi thay vì thu thêm sự cố, vì một lỗi đã định vị so với bản dựng khớp là kết quả duy nhất đưa báo cáo tiến lên. Nếu không có gì trả về, phương án dự phòng là tái hiện có kiểm soát trên phần cứng dự phòng, không bao giờ trên máy mà người khác phụ thuộc.