Posted inLinux

Làm Chủ Core Dump Trên Linux: Tuyệt Chiêu ‘Bắt Bài’ Lỗi Segmentation Fault

Linux tutorial - IT technology blog
Linux tutorial - IT technology blog

Ứng dụng sập mà không để lại dấu vết?

Anh em làm System Admin hay Backend chắc chẳng lạ gì dòng thông báo đầy ám ảnh: Segmentation fault (core dumped). Đau nhất là khi ứng dụng chết bất đắc kỳ tử, log file trống trơn vì tiến trình bị kill quá nhanh. Lúc này, Core Dump chính là cứu cánh duy nhất.

Cứ tưởng tượng Core Dump giống như chiếc “hộp đen” máy bay. Khi app bị sập, Linux sẽ chụp lại toàn bộ trạng thái bộ nhớ (RAM), các thanh ghi và ngăn xếp (stack) rồi ghi vào một file. Nhìn vào đó, mình sẽ biết chính xác dòng code nào gây lỗi và biến nào đang mang giá trị sai. Kinh nghiệm thực chiến của mình là hãy cấu hình Core Dump ngay từ khi setup server, đừng đợi đến lúc app sập trên Production mới cuống cuồng đi bật.

Quick start: Kích hoạt Core Dump trong 30 giây

Thông thường, các bản phân phối Linux như Ubuntu hay CentOS sẽ giới hạn kích thước file core bằng 0. Điều này có nghĩa là hệ thống sẽ không tạo ra file gì cả khi crash. Để kiểm tra và bật nhanh cho phiên làm việc hiện tại, anh em dùng lệnh:

# Kiểm tra giới hạn hiện tại
ulimit -c

# Cho phép tạo file core không giới hạn dung lượng
ulimit -c unlimited

Thử nghiệm ngay bằng một đoạn Python gây lỗi truy cập vùng nhớ cấm:

python3 -c "import ctypes; ctypes.string_at(0)"

Nếu thấy chữ (core dumped) xuất hiện cạnh thông báo lỗi, chúc mừng anh em, bằng chứng “phạm tội” đã được ghi lại.

Cấu hình Core Dump chuyên sâu và vĩnh viễn

Dùng lệnh ulimit chỉ có tác dụng tạm thời trong terminal đó. Để hệ thống tự động ghi lại mọi vụ crash sau khi reboot, mình cần can thiệp vào cấu hình hệ thống.

1. Cấu hình vĩnh viễn với limits.conf

Anh em mở file /etc/security/limits.conf và thêm hai dòng sau vào cuối:

*          soft    core    unlimited
*          hard    core    unlimited

Dấu * áp dụng cho mọi user. Sau khi lưu, hãy logout và login lại để cấu hình mới có hiệu lực.

2. Quy hoạch nơi lưu trữ và cách đặt tên file

Mặc định file core hay nằm rải rác ở thư mục thực thi với cái tên core rất khó quản lý. Mình thường gom tất cả về một thư mục riêng để dễ theo dõi và dọn dẹp.

# Tạo thư mục tập trung
sudo mkdir -p /var/crash
sudo chmod 777 /var/crash

# Cấu hình định dạng tên file qua sysctl
sudo sysctl -w kernel.core_pattern=/var/crash/core-%e-%p-%t

Ý nghĩa các tham số:

  • %e: Tên file thực thi (ví dụ: nginx, python).
  • %p: PID của tiến trình bị sập.
  • %t: Thời điểm crash tính theo UNIX timestamp.

Để duy trì thiết lập này sau khi khởi động lại, hãy thêm dòng kernel.core_pattern=/var/crash/core-%e-%p-%t vào file /etc/sysctl.conf.

Sử dụng coredumpctl trên các bản Linux hiện đại

Nếu đang dùng Ubuntu 20.04+, Debian 11+ hoặc RHEL 8+, hệ thống thường tích hợp sẵn systemd-coredump. Công cụ này cực kỳ bá đạo vì nó quản lý file core tập trung và hỗ trợ query rất nhanh.

# Liệt kê danh sách các vụ crash gần đây
coredumpctl list

# Xem thông tin chi tiết của một vụ crash (dựa trên PID)
coredumpctl info 1234

# Trích xuất file core để phân tích riêng
coredumpctl dump 1234 -o my_app.core

Phân tích lỗi bằng GDB

Có file core rồi, giờ là lúc “khám nghiệm tử thi”. Công cụ mạnh mẽ nhất là gdb (GNU Debugger). Giả sử ứng dụng my_app bị sập, anh em chạy lệnh:

gdb ./my_app /var/crash/core-my_app-1234

Gõ lệnh bt (backtrace) trong giao diện gdb. Hệ thống sẽ hiện ra danh sách các hàm được gọi ngay trước thời điểm sập. Thủ phạm thường nằm ở dòng code cuối cùng được liệt kê.

(gdb) bt
#0  0x0000555555555151 in crash_function () at main.c:10
#1  0x000055555555516a in main () at main.c:15

Nhìn vào kết quả, ta biết ngay lỗi nằm ở dòng số 10 trong file main.c. Không còn phải đoán mò nữa!

Những lưu ý “xương máu” để tránh sập server

Core Dump là con dao hai lưỡi. Trước khi triển khai rộng rãi, anh em cần nhớ 3 quy tắc này:

  1. Quản lý dung lượng: File core có kích thước tương đương lượng RAM app đang chiếm dụng (RSS). Nếu app Java ngốn 16GB RAM mà bị crash liên tục, ổ cứng server sẽ đầy chỉ trong vài phút. Hãy thiết lập quota hoặc script dọn dẹp định kỳ.
  2. Rủi ro bảo mật: File core chứa dữ liệu thô từ RAM. Nếu app đang xử lý token, mật khẩu hoặc khóa bí mật, chúng sẽ nằm dưới dạng plain text trong file này. Hãy giới hạn quyền truy cập thư mục crash chặt chẽ.
  3. Debug Symbols: Để thấy được tên hàm và số dòng code, app phải được build với cờ -g (debug symbols). Nếu không, anh em sẽ chỉ thấy những địa chỉ bộ nhớ khô khan như 0x00007f... rất khó đọc.

Tóm lại, cấu hình Core Dump giúp anh em chuyển từ thế bị động sang chủ động khi xử lý sự cố. Hãy thử thiết lập trên môi trường Staging ngay hôm nay để làm quen với quy trình truy vết lỗi nhé!

Share:
Tags: