Kdump và vmcore: Điều tra Linux kernel panic trong production

Khi Linux kernel panic, log thông thường có thể dừng đúng lúc bằng chứng quan trọng nhất xuất hiện. Kdump giải quyết khoảng trống đó bằng cách dành trước một vùng RAM, dùng kexec khởi động capture kernel tối giản sau sự cố, giữ nguyên ảnh bộ nhớ của kernel lỗi và ghi nó thành vmcore để phân tích hậu kiểm.

Bài viết dựa trên tài liệu Kdump của Linux kernel, hướng dẫn kdump của Red Hat Enterprise Linux và tài liệu makedumpfile. Tên package, service, initramfs và công cụ quản lý bootloader khác nhau theo distribution; hãy ưu tiên tài liệu của bản Linux đang vận hành.

1. Kdump hoạt động như thế nào?

1. Kernel chính boot với tham số crashkernel= và dành một vùng RAM riêng.
2. Một capture kernel cùng initramfs tối giản được nạp vào vùng đã dành bằng kexec.
3. Khi kernel chính panic, hệ thống chuyển sang capture kernel thay vì boot đầy đủ theo đường thông thường.
4. Ảnh RAM của kernel lỗi được expose qua /proc/vmcore.
5. Công cụ capture ghi, lọc hoặc nén vmcore tới local disk hay đích mạng.
6. Đội vận hành phân tích vmcore bằng đúng debug kernel tương ứng.

Capture kernel phải nhỏ và độc lập vì nó khởi động trong môi trường vừa gặp lỗi nghiêm trọng. Kdump không bảo đảm thu được mọi sự cố: mất điện, firmware reset tức thời, hỏng phần cứng nặng hoặc capture kernel không đủ driver/RAM vẫn có thể làm mất dump.

2. Vì sao journal không đủ?

Điều tra tốt kết hợp cả bốn. Vmcore mạnh cho lỗi kernel nhưng không thay log ứng dụng, distributed trace hay dữ liệu phần cứng.

3. Kiểm tra khả năng hỗ trợ và trạng thái hiện tại

uname -r
cat /proc/cmdline
grep -i 'Crash kernel' /proc/iomem
systemctl status kdump --no-pager

# Trên hệ dùng kdumpctl
kdumpctl status

# Trên Debian/Ubuntu có thể dùng công cụ khác
kdump-config show

Không phải mọi lệnh đều có trên mọi distribution. Cần xác nhận kernel hỗ trợ kexec/crash dump, package kdump đã cài, vùng RAM thật sự được reserve và capture kernel đã load. Trạng thái service “active” một mình chưa chứng minh đường ghi dump, DNS, network hay storage sẽ hoạt động sau panic.

4. Sizing crashkernel không phải một con số chung

crashkernel= làm giảm RAM mà workload chính có thể dùng, nhưng reserve quá ít khiến capture kernel hết bộ nhớ hoặc thiếu khả năng ghi dump. Nhu cầu phụ thuộc kiến trúc CPU, tổng RAM, số CPU, driver, thiết bị, encryption, dump target và initramfs.

• Dùng giá trị mặc định/ước lượng do distribution hiện tại cung cấp khi có thể.
• Đừng copy bảng sizing của release cũ sang release mới; cú pháp và khuyến nghị có thể đổi.
• Máy có nhiều NIC, HBA, multipath, encrypted storage hoặc RAM lớn cần test thực tế.
• Sau khi thay boot parameter, reboot có kiểm soát và xác nhận vùng reserve trong /proc/iomem.

Một lần load thành công chưa đủ: capture kernel có thể boot nhưng thất bại khi driver storage/network được dùng hoặc khi makedumpfile cần thêm memory bitmap.

5. Capture kernel và initramfs phải chứa đúng dependency

Đích local cần filesystem, block, LVM, RAID, multipath hoặc encryption dependency tương ứng. Đích mạng cần NIC driver, network configuration, route, DNS nếu dùng hostname, cùng credential/protocol cần thiết. Capture initramfs nên tối giản nhưng không được thiếu mắt xích.

• Ưu tiên identifier ổn định thay cho tên device phụ thuộc thứ tự probe.
• Nếu target mã hóa, xác minh capture kernel có thể unlock theo cơ chế được hỗ trợ.
• Nếu dùng network, tránh phụ thuộc một control plane có thể không sẵn sàng khi node lỗi.
• Rebuild kdump initramfs sau thay đổi kernel, driver, target hay credential theo hướng dẫn distro.
• Giữ capture path đủ đơn giản để có thể audit và diễn tập.

6. Chọn dump target theo fault domain

Không ghi vmcore vào filesystem đang gây panic hoặc volume có thể không mount trong capture kernel. Dự trù worst case thay vì chỉ nhìn kích thước dump gần nhất. Cấu hình hành vi khi dump thất bại—reboot, halt hay shell—phải phù hợp availability và an toàn; shell khẩn cấp không nên vô tình mở console đặc quyền.

7. makedumpfile: nhỏ hơn nhưng vẫn đủ bằng chứng

Raw vmcore có thể gần bằng dung lượng RAM. makedumpfile lọc các loại page và nén output. Dump level là bitmask: tùy tổ hợp, nó có thể bỏ zero page, cache page, user-process data và free page.

# Ví dụ theo tài liệu kernel; kiểm tra hỗ trợ compression trên bản cài
makedumpfile -l --message-level 1 -d 31 \
  /proc/vmcore /var/crash/vmcore.filtered

-d 31 thường giảm mạnh kích thước nhưng có thể loại user-space memory cần cho một số điều tra. Không chọn dump level chỉ vì file nhỏ nhất: xác định câu hỏi forensic, giới hạn dữ liệu nhạy cảm và yêu cầu vendor support. Theo dõi exit code; một file tồn tại không có nghĩa dump hoàn chỉnh.

8. Vmcore là dữ liệu cực kỳ nhạy cảm

RAM có thể chứa token, key, session, nội dung request, dữ liệu khách hàng và plaintext từ volume mã hóa. Vì vậy vmcore phải được phân loại ít nhất ngang mức dữ liệu nhạy cảm nhất có thể nằm trong bộ nhớ.

• Mã hóa đường truyền và storage đích; tách credential capture.
• Giới hạn quyền đọc, tải xuống và phân tích; ghi audit log.
• Không đính kèm vmcore nguyên bản vào ticket công khai.
• Định nghĩa retention, legal hold và secure deletion.
• Hash file sau capture để kiểm tra integrity trong quá trình vận chuyển.
• Chỉ upload cho vendor qua kênh được duyệt và theo data-processing policy.

9. Giữ đúng kernel artifacts để phân tích

crash cần file vmlinux có debug symbols khớp chính xác với kernel tạo vmcore. Tên version giống nhau chưa chắc đủ nếu build ID, config, compiler hoặc module khác.

Mỗi lần deploy kernel nên archive theo release/build ID:

• unstripped vmlinux hoặc package debuginfo/dbgsym chính xác;
• kernel config, System.map khi quy trình cần;
• module binaries và symbols tương ứng;
• initramfs/capture config và package manifest;
• provenance, checksum và thời hạn giữ ít nhất bằng retention vmcore.

Đừng đợi kernel cũ biến mất khỏi repository mới tìm debug package. Artifact retention là một phần của thiết kế kdump.

10. Phân tích bước đầu bằng crash

crash /path/to/vmlinux /path/to/vmcore

# Trong crash shell
sys
log
bt
ps
kmem -i
mod
files

sys xác nhận kernel và trạng thái; log đọc kernel ring buffer; bt xem stack; ps liệt kê task; kmem -i cho tổng quan memory. Bắt đầu từ panic string, crashing CPU/task và backtrace, rồi kiểm tra module taint, recent log, lock/wait state và dấu hiệu hardware error.

Stack có tên một module không tự động chứng minh module đó là nguyên nhân. Corruption có thể xảy ra sớm hơn; cần đối chiếu source, symbols, các incident tương tự và telemetry phần cứng.

11. Test end-to-end là bắt buộc và gây gián đoạn

Cảnh báo nghiêm trọng: ghi c vào /proc/sysrq-trigger cố ý làm kernel panic, dừng workload ngay lập tức và có thể gây mất dữ liệu chưa flush. Chỉ test trên lab hoặc trong maintenance window đã được phê duyệt, sau khi drain traffic, xác minh backup và có console/out-of-band access.

# LỆNH GÂY CRASH — không chạy trên production đang phục vụ
echo c | sudo tee /proc/sysrq-trigger

Một drill đạt yêu cầu phải chứng minh toàn chuỗi: panic → capture kernel boot → target sẵn sàng → vmcore hoàn chỉnh → reboot/halt đúng policy → file được hash/bảo vệ → mở được bằng crash và symbols khớp. Chỉ chạy kdumpctl status không kiểm tra được chuỗi này.

12. Monitoring và vòng đời vận hành

Revalidate sau kernel update, thay driver/NIC/HBA, thay storage/network, đổi encryption, thay crashkernel sizing hoặc đổi image base. Fleet nên báo cáo tỷ lệ node “armed and recently tested”, không chỉ trạng thái package installed.

Runbook khi nhận vmcore

1. Cô lập incident, ghi nhận thời điểm, node, kernel build và tác động.
2. Xác minh vmcore hoàn chỉnh, checksum và quyền truy cập.
3. Thu journal, pstore, BMC/hardware event và deployment timeline liên quan.
4. Lấy đúng vmlinux/debuginfo/module theo build ID.
5. Phân tích panic string, CPU/task, backtrace, taint và memory/I/O state.
6. So sánh với kernel bug, driver release note và thay đổi gần nhất.
7. Đưa ra giả thuyết có bằng chứng, mitigation có rollback và cách tái hiện an toàn.
8. Lưu artifact theo retention rồi xóa bản tạm đúng policy.

Checklist production

• crashkernel được sizing theo distro, phần cứng và dependency thực tế.
• Vùng reserve và capture kernel được kiểm tra sau mỗi boot/kernel update.
• Initramfs có đủ driver, storage, network và encryption dependency.
• Dump target tách fault domain, đủ capacity và có failure policy rõ ràng.
• Dump level cân bằng forensic value, kích thước và privacy.
• Vmcore được mã hóa, phân quyền, audit, hash và retention như dữ liệu nhạy cảm.
• vmlinux/debuginfo/module khớp build được archive trước incident.
• Alert bao phủ reservation, loaded state, target health và artifact coverage.
• Drill end-to-end chỉ chạy trong cửa sổ gây gián đoạn được phê duyệt.
• Đã chứng minh một vmcore thật mở và phân tích được bằng crash.

Kết luận

Kdump biến kernel panic từ một lần reboot khó hiểu thành bằng chứng có thể phân tích. Giá trị không nằm ở việc service kdump đang chạy, mà ở cả hệ thống: RAM reserve đủ, capture kernel tự lực, target sống qua fault domain, vmcore được lọc và bảo vệ, symbols khớp được giữ lại, cùng một drill chứng minh đường đi hoàn chỉnh. Khi đó sự cố kernel không còn phụ thuộc vào phỏng đoán từ vài dòng log cuối.