Cấu hình kdump trên Fedora Server: Bắt lỗi Kernel Panic và phân tích crash dump thực tế

Quick start: Thiết lập kdump trong 5 phút

Nếu bạn cần bảo vệ máy chủ production ngay lập tức trước nguy cơ sập nguồn không rõ nguyên nhân, hãy làm lần lượt 3 bước sau.

Bước 1: Cài đặt gói kexec-tools

Mở terminal và cài gói điều khiển nạp kernel:

sudo dnf install -y kexec-tools

Bước 2: Dành riêng RAM cho Crash Kernel

Hạt nhân cứu hộ cần một vùng nhớ độc lập để hoạt động khi hệ thống chính sụp đổ. Hãy dùng grubby để gán tham số khởi động:

sudo grubby --update-kernel=ALL --args="crashkernel=512M"

Khởi động lại máy để GRUB áp dụng phân vùng RAM này:

sudo reboot

Bước 3: Kích hoạt service và kiểm tra

Sau khi máy lên lại, bạn bật kdump daemon:

sudo systemctl enable --now kdump.service
sudo kdumpctl status

Kết quả trả về kdump: Kdump is operational nghĩa là hệ thống đã sẵn sàng ghi nhận crash bất cứ lúc nào.

kdump hoạt động thế nào khi Kernel Panic?

Khi Kernel Panic nổ ra, toàn bộ CPU dừng xử lý tác vụ bình thường. Bộ nhớ RAM bị đóng băng. Các tiến trình ghi log kinh điển như rsyslog hay systemd-journald đều tê liệt. Bạn sẽ không tìm thấy bất kỳ manh mối nào trong /var/log/messages sau khi khởi động lại.

Đó là lý do kdump ra đời. Nó hoạt động như chiếc hộp đen độc lập. Dựa vào cơ chế kexec, kdump nạp ngay một kernel cứu hộ gọn nhẹ (capture kernel) vào vùng nhớ 512MB ta đã cách ly từ trước. Toàn bộ tiến trình này bỏ qua bước kiểm tra phần cứng BIOS/UEFI tốn thời gian.

Nhiệm vụ của capture kernel rất đơn giản: trích xuất toàn bộ dữ liệu RAM của kernel cũ, nén lại thành file vmcore rồi ghi xuống đĩa cứng. Xong việc, máy sẽ tự reboot.

Thực tế vận hành cho thấy, một cụm server Fedora chạy dịch vụ tính toán nặng với driver mạng ngoài rất dễ dính lỗi memory corruption hoặc deadlock ngầm. Không có vmcore, bạn chỉ còn cách đoán mò giữa hàng trăm commit mã nguồn hoặc đổi phần cứng trong vô vọng.

Tinh chỉnh cấu hình kdump.conf

File cấu hình chính nằm tại /etc/kdump.conf. Mặc định hệ thống lưu dump tại ổ cứng local, nhưng bạn hoàn toàn có thể điều chỉnh theo hạ tầng riêng.

1. Chuyển vị trí lưu trữ

Ghi dump lên cùng phân vùng root (/) tiềm ẩn rủi ro làm tràn ổ cứng. Bạn có thể trỏ đường dẫn sang phân vùng dữ liệu riêng hoặc máy chủ NFS qua mạng:

# Ghi vào phân vùng riêng gắn tại /mnt/crash
path /mnt/crash

# Hoặc đẩy qua NFS server trong mạng nội bộ
# nfs 192.168.1.50:/data/kdumps

2. Giảm dung lượng file dump với makedumpfile

Máy chủ sở hữu 64GB hay 128GB RAM nếu ghi thô (raw dump) sẽ vừa ngốn đĩa vừa mất cả chục phút. Cấu hình sau lọc sạch dữ liệu dư thừa trước khi nén:

core_collector makedumpfile -l --message-level 7 -d 31

Chỉ số -d 31 tương đương việc bật toàn bộ cờ lọc: bỏ trang bộ nhớ trống (zero page), bộ nhớ đệm (cache), dữ liệu của ứng dụng người dùng (user-space) và trang free. File kết xuất chỉ giữ lại cấu trúc dữ liệu của kernel. Dung lượng nhờ đó giảm từ 64GB xuống chỉ còn khoảng 600MB đến 1.2GB.

Thực hành: Kích hoạt Panic có kiểm soát và mổ xẻ lỗi

Đừng chờ sự cố thật xảy ra mới biết cấu hình kdump bị thiếu bộ nhớ. Hãy chủ động tạo panic trên môi trường staging.

Tạo Kernel Panic giả lập bằng SysRq

Kernel Linux hỗ trợ giao tiếp trực tiếp qua Magic SysRq. Chạy hai lệnh sau (lưu ý: hệ thống sẽ crash và reboot ngay):

echo 1 | sudo tee /proc/sys/kernel/sysrq
echo c | sudo tee /proc/sysrq-trigger

Sau khi máy hoàn tất khởi động lại, kiểm tra thư mục chứa file crash:

ls -lh /var/crash/

Bạn sẽ thấy thư mục dạng 127.0.0.1-YYYY-MM-DD-HH:MM:SS/ chứa file vmcore và file text tóm tắt nhật ký dmesg lúc crash.

Phân tích vmcore bằng crash utility

Để đọc được file nhị phân này, máy cần cài công cụ crash và biểu tượng debug (debuginfo) khớp đúng bản kernel gặp sự cố:

sudo dnf install -y crash dnf-plugins-core
sudo dnf debuginfo-install -y kernel-$(uname -r)

Khởi chạy công cụ phân tích:

crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/127.0.0.1-*/vmcore

Khi dấu nhắc lệnh crash> xuất hiện, gõ lệnh bt (backtrace) để truy vết ngăn xếp cuộc gọi hàm:

crash> bt
PID: 1420   TASK: ffff88012a45c000  CPU: 1   COMMAND: "tee"
 #0 [ffffc90001423d60] machine_kexec at ffffffff8106a3f3
 #1 [ffffc90001423dc0] __crash_kexec at ffffffff8116248d
 #2 [ffffc90001423e80] panic at ffffffff810be512
 #3 [ffffc90001423f00] sysrq_handle_crash at ffffffff81580125
 #4 [ffffc90001423f10] __handle_sysrq at ffffffff81580872

Dấu vết hiện rõ: tiến trình tee (PID 1420) gọi hàm kích nổ sysrq_handle_crash. Khi gặp lỗi thật, ngăn xếp này sẽ chỉ thẳng vào tên driver bên thứ ba hoặc hàm kernel đang bị lỗi dereference pointer.

Lưu ý vận hành thực tế

• Định mức RAM cho crashkernel: Mức 512M đáp ứng tốt cho máy chủ từ 8GB đến 32GB RAM. Với máy chủ trên 128GB RAM trang bị nhiều card RAID hoặc card mạng quang 10GbE/25GbE cần nạp nhiều driver lớn khi boot, hãy tăng lên 768M hoặc 1024M để tránh tình trạng kernel cứu hộ bị dính OOM (Out of Memory).
• Dọn dẹp tự động: Mỗi file vmcore có thể chiếm 1GB-2GB đĩa cứng. Nhiều sự cố liên tiếp dễ làm cạn kiệt dung lượng ổ /var. Bạn nên đặt systemd-tmpfiles hoặc cron job xóa các thư mục crash cũ hơn 14 ngày.
• Cập nhật kernel: Khi chạy dnf upgrade lên phiên bản kernel mới, hãy kiểm tra lại bằng lệnh sudo kdumpctl status để chắc chắn ramdisk cứu hộ đã được dracut biên dịch lại tương thích.