Server treo không rõ lý do — cơn ác mộng của sysadmin
Mình còn nhớ cái lần đầu đối mặt với kernel panic trên production — server CentOS 7 chạy database chính của team, đã bỏ ra cả tháng tối ưu để đạt latency dưới 10ms. Nó khởi động lại lúc 3 giờ sáng, không có cảnh báo nào trước. Check /var/log/messages thì log bị cắt ngang giữa chừng — không một dòng nào ghi lại nguyên nhân. Mất gần cả tuần mới tái hiện được lỗi và tìm ra thủ phạm là một kernel module của phần mềm backup, thứ mà mình không bao giờ nghĩ tới.
Nếu lúc đó biết đến kdump, mình đã tiết kiệm được rất nhiều thời gian. Kdump ghi lại toàn bộ trạng thái RAM ngay khi kernel bị crash — trước khi hệ thống kịp reboot. File dump này phân tích bằng công cụ crash để xác định chính xác call stack, dòng code lỗi, và nguyên nhân gốc rễ của sự cố.
Kdump hoạt động như thế nào?
Thay vì dựa vào kernel đang crash (vốn đã không còn tin cậy), kdump dùng một capture kernel nhỏ được load sẵn vào một vùng RAM riêng từ lúc boot. Khi kernel chính bị panic, hệ thống chuyển qua chạy capture kernel này, ghi toàn bộ RAM ra file vmcore, rồi mới reboot bình thường.
- vmcore: File dump được ghi ra, thường nằm tại
/var/crash/ - makedumpfile: Nén và lọc vmcore, bỏ các trang RAM không cần thiết để tiết kiệm dung lượng
- crash: Công cụ phân tích vmcore, giao diện tương tự GDB
- kernel-debuginfo: Package chứa debug symbols — cần để
crashđọc được symbol names
Memory reservation
Capture kernel cần vùng RAM riêng, không bị kernel chính đụng vào. Vùng này khai báo qua tham số boot crashkernel=. Thông thường 128–256MB là đủ cho hầu hết hệ thống.
Cài đặt và cấu hình kdump từng bước
Bước 1: Cài đặt các package cần thiết
Trên RHEL/CentOS/AlmaLinux:
sudo dnf install kexec-tools crash kernel-debuginfo kernel-debuginfo-common
# CentOS 7 dùng yum
sudo yum install kexec-tools crash kernel-debuginfo kernel-debuginfo-commonTrên Ubuntu/Debian:
sudo apt-get install kdump-tools crash linux-image-$(uname -r)-dbgsymBước 2: Thêm crashkernel vào GRUB
Bước này quyết định kdump có hoạt động hay không — capture kernel cần vùng RAM riêng, và crashkernel= là cách khai báo nó với bootloader. Mở /etc/default/grub:
sudo vi /etc/default/grub
# Tìm dòng GRUB_CMDLINE_LINUX, thêm crashkernel=auto vào cuối
GRUB_CMDLINE_LINUX="... crashkernel=auto"
# Cập nhật grub config (BIOS)
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
# Nếu dùng UEFI
sudo grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfgReboot, rồi kiểm tra crashkernel đã được reserve chưa:
cat /proc/iomem | grep -i crash
# Output mong đợi:
# 2d000000-4cffffff : Crash kernelBước 3: Cấu hình /etc/kdump.conf
sudo vi /etc/kdump.confCấu hình cơ bản để lưu dump ra local disk:
# Đường dẫn lưu vmcore
path /var/crash
# Hành động sau khi dump xong
default reboot
# Dùng makedumpfile để nén và lọc bớt trang không cần thiết
core_collector makedumpfile -l --message-level 1 -d 31Tham số -d 31 loại bỏ zero pages, cache pages, và một số loại trang không liên quan đến lỗi. File dump sau đó thường chỉ còn 10–20% kích thước RAM thực tế — server 16GB xuống còn khoảng 2–3GB là chuyện bình thường.
Nếu muốn ghi dump ra NFS share để tránh chiếm disk local:
nfs 192.168.1.100:/exports/crash_dumps
path /Bước 4: Enable và start kdump service
sudo systemctl enable kdump
sudo systemctl start kdump
sudo systemctl status kdumpKhi start thành công, trông như này:
● kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled)
Active: active (exited) since Wed 2026-06-25 10:30:00 JSTBước 5: Test kdump (chỉ làm trên môi trường test!)
Để xác nhận kdump hoạt động đúng, cần trigger một kernel panic giả. Lệnh dưới đây sẽ crash server ngay lập tức — chỉ chạy trên VM hoặc server test:
# CẢNH BÁO: Server sẽ crash và reboot ngay
echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-triggerSau khi server khởi động lại, kiểm tra thư mục dump:
ls -lh /var/crash/
# drwxr-xr-x 2 root root 4096 Jun 25 10:35 2026-06-25-10:35
ls -lh /var/crash/2026-06-25-10:35/
# vmcore -- file dump chính
# vmcore-dmesg.txt -- kernel messages trước khi crashPhân tích kernel crash dump với crash tool
Mở vmcore với crash
# Cú pháp: crash <vmlinux> <vmcore>
sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux \
/var/crash/2026-06-25-10:35/vmcoreVào được crash shell rồi, mấy lệnh này là đủ cho 90% trường hợp:
# Call stack tại thời điểm crash
crash> bt
# Kernel log trước khi crash
crash> log
# Danh sách process đang chạy
crash> ps
# Thông tin tổng quan về crash
crash> sys
# Tình trạng memory
crash> kmem -i
# Thoát
crash> quitĐọc kết quả backtrace
Kết quả của bt trông như thế này:
crash> bt
PID: 0 TASK: ffffffff81c14480 CPU: 0 COMMAND: "swapper/0"
#0 [ffffffff81c03d28] machine_kexec at ffffffff8105b6ab
#1 [ffffffff81c03d78] __crash_kexec at ffffffff810f2d5a
#2 [ffffffff81c03e48] crash_kexec at ffffffff810f2e50
#3 [ffffffff81c03e60] oops_end at ffffffff8162efb8
#4 [ffffffff81c03e88] die at ffffffff8101e97b
#5 [ffffffff81c03eb8] do_general_protection at ffffffff8162e834Đọc từ dưới lên — function ở cuối stack là nơi vấn đề bắt đầu. Trường hợp của mình, backtrace chỉ thẳng vào module của phần mềm backup, thứ mà mình không nghi ngờ chút nào trước đó.
Extract nhanh dmesg từ vmcore
Không muốn phân tích sâu? Lấy nhanh kernel messages trước crash:
makedumpfile --dump-dmesg /var/crash/2026-06-25-10:35/vmcore dmesg.txt
cat dmesg.txt | tail -50Thường thì dòng lỗi ngay trước Kernel panic đã đủ để bắt đầu điều tra — không cần đào sâu vào crash shell.
Lưu ý thực tế khi deploy
- Dung lượng disk: Để đủ chỗ cho ít nhất 1–2 file dump. RAM 16GB sau khi nén vẫn cần khoảng 3–5GB trống tại
/var/crash - Kernel debuginfo không cần cài trên production: Package này nặng vài GB. Chỉ cần cài trên máy phân tích, copy vmcore về đó là được
- Kernel version phải khớp chính xác: vmlinux (debuginfo) phải đúng version với kernel tạo ra vmcore. Sai version thì crash tool báo lỗi ngay
- crashkernel=auto không đủ trên server RAM lớn: Server 64GB+ đôi khi cần chỉ định thủ công
crashkernel=512Mnếu kdump service fail khi start - Cleanup định kỳ: Thêm cron để xóa dump cũ, tránh đầy disk khi server crash nhiều lần liên tiếp
Kết luận
Kdump không phải thứ dùng hàng ngày. Nhưng khi server gặp kernel panic mà không để lại dấu vết, nó là thứ duy nhất có thể cho bạn câu trả lời thực sự. Setup mất khoảng 30 phút — đổi lại là không phải mò mẫm hàng ngày trời khi sự cố xảy ra.
Server chạy kernel module tùy chỉnh, driver phần cứng lạ, hoặc workload database nặng đặc biệt cần có kdump. Bật từ đầu, trước khi sự cố xảy ra — vì khi cần đến nó, đã không còn cơ hội để bật nữa.
