Signal — SIGTERM, SIGKILL và Ctrl+C thật sự làm gì

TL;DR: Signal là cách OS (hoặc tiến trình khác) gõ cửa một tiến trình đang chạy để báo một sự kiện: "hãy dừng", "có lỗi", "con của mày vừa chết". Khi signal tới, kernel tạm ngắt tiến trình và chạy handler — hàm phản ứng — nếu tiến trình đã đăng ký; nếu không, dùng default action (thường là kết thúc tiến trình). Điểm mấu chốt: hầu hết signal có thể bắt (catch) để xử lý gọn gàng, nhưng hai signal — SIGKILL (số 9) và SIGSTOP (số 19 trên x86/ARM) — không thể bắt, chặn, hay bỏ qua. Vì vậy SIGTERM (số 15, "xin dừng") cho phép cleanup, còn SIGKILL giết thẳng. Ctrl+C gửi SIGINT (số 2). docker stop gửi SIGTERM rồi SIGKILL sau 10 giây.

Bạn gõ Ctrl+C một script Python đang chạy — nó dừng ngay. Nhưng một service khác thì Ctrl+C hoài không chết, phải kill -9 mới xong. Bạn docker stop một container, đợi đúng 10 giây nó mới tắt hẳn. Ba tình huống này đều là signal — và khác biệt về "chết ngay hay chết từ từ" nằm ở signal nào được gửi và tiến trình có được phép phản ứng không.

Xong bài, bạn compare được SIGTERM, SIGKILL, SIGINT, SIGSTOP — dự đoán mỗi tiến trình phản ứng ra sao — và áp dụng được pattern graceful shutdown mà mọi service production nên có.

1. Analogy — các kiểu yêu cầu nhân viên rời văn phòng

Hình dung nhiều cách bảo một nhân viên rời chỗ làm:

• "Anh dọn đồ rồi về nhé" (lịch sự): nhân viên lưu file đang mở, gửi nốt email dở, tắt máy, rồi đi. Đây là SIGTERM — yêu cầu dừng, cho phép chuẩn bị.
• Bảo vệ lôi thẳng ra cửa, không cho lấy đồ: nhân viên bị đưa ra ngay, file chưa lưu mất. Đây là SIGKILL — không thương lượng, không cleanup.
• Nhấn chuông báo động chung (Ctrl+C): mọi người ở khu vực đó đứng dậy đi ra. Đây là SIGINT từ terminal.
• Bấm nút "đóng băng": nhân viên đứng im tại chỗ, không làm gì, chờ lệnh tiếp. Đây là SIGSTOP — tạm dừng, chưa kết thúc.

Điểm khác biệt cốt lõi: với lời nhắc lịch sự, nhân viên được quyền phản ứng (dọn dẹp). Với bảo vệ lôi ra hay nút đóng băng, nhân viên không cãi được — tương ứng SIGKILL và SIGSTOP mà tiến trình không thể bắt hay chặn.

2. Cơ chế signal — kernel gõ cửa thế nào?

Signal là một thông báo bất đồng bộ (asynchronous) — nó có thể tới bất kỳ lúc nào, giữa hai lệnh bất kỳ của tiến trình. Nguồn gửi: kernel (ví dụ lỗi chia cho 0 → SIGFPE), tiến trình khác (qua system call kill), hay chính terminal (Ctrl+C → SIGINT).

Khi một signal được gửi tới tiến trình, kernel tạm ngắt luồng chạy bình thường và chọn một trong ba disposition:

1. Handler tự đăng ký: nếu tiến trình đã gọi signal()/sigaction() để đăng ký một hàm cho signal đó, kernel chạy hàm ấy (rồi thường quay lại chỗ bị ngắt). Đây là "bắt" (catch) signal.
2. Default action: nếu chưa đăng ký, kernel dùng hành vi mặc định của signal đó. Theo signal(7), default có thể là Term (kết thúc), Core (kết thúc + dump), Stop (tạm dừng), Cont (chạy tiếp), hay Ign (bỏ qua).
3. Bỏ qua: tiến trình đặt disposition thành SIG_IGN — signal tới cũng như không.

Ngoại lệ tối quan trọng (mũi tên đứt trong sơ đồ): theo signal(7), "SIGKILL và SIGSTOP không thể bị catch, block, hay ignore". Với hai signal này, kernel bỏ qua mọi handler và thực thi trực tiếp — SIGKILL giết tiến trình ngay, SIGSTOP đóng băng ngay. Đây là "van an toàn" của OS: luôn có cách giết/dừng một tiến trình lì, kể cả khi code nó cố chống.

3. Bốn signal bạn gặp mỗi ngày

Vài hệ quả thực tế:

• kill <pid> mặc định gửi SIGTERM, không phải SIGKILL. Nhiều người tưởng kill là "giết chết" — thực ra nó chỉ gửi signal, và mặc định là lời mời dừng lịch sự.
• Ctrl+C = SIGINT: signal tới cả nhóm tiến trình foreground (process group — tập tiến trình shell gom lại, ví dụ cả pipeline a | b | c, để nhận signal cùng lúc). Chương trình bắt được nên có thể dừng gọn (lưu trạng thái, in "Bye"). Chương trình phớt lờ SIGINT (đăng ký handler rỗng) thì Ctrl+C vô hiệu — đó là lý do đôi khi Ctrl+C không ăn.
• SIGKILL là lựa chọn cuối: dùng khi tiến trình không phản hồi SIGTERM. Vì không cleanup, nó có thể để lại file tạm, lock, dữ liệu ghi dở.

4. Graceful shutdown — bắt SIGTERM để dừng sạch

Đây là pattern quan trọng nhất của bài, dùng trong mọi service production. Ý tưởng: bắt SIGTERM, và thay vì chết ngay, làm thủ tục dừng có trật tự:

1. Ngừng nhận yêu cầu/việc mới.
2. Hoàn tất các việc đang dở (request đang xử lý).
3. Đóng tài nguyên: flush log, đóng kết nối DB, nhả lock, xoá file tạm.
4. Thoát với exit status hợp lý.

Dưới đây là khung graceful shutdown còn hai chỗ trống — dựa vào bốn bước trên, tự điền trước khi xem đáp án.

// graceful.c -- bat SIGTERM va SIGINT de dung sach
#include <stdio.h>
#include <signal.h>
#include <unistd.h>

volatile sig_atomic_t stop = 0;   // co bao "can dung"

void on_signal(int sig) {
    stop = 1;                     // chi dat co -- KHONG lam viec nang trong handler
}

int main(void) {
    signal(SIGTERM, /* TODO 1: dang ky ham nao cho SIGTERM? */);
    signal(SIGINT,  /* TODO 1: cung ham do cho Ctrl+C */);

    while (/* TODO 2: lap chung nao co chua bat? */) {
        // ... xu ly cong viec binh thuong ...
        sleep(1);
    }

    // Toi day nghia la da nhan SIGTERM/SIGINT -> cleanup
    printf("Nhan tin hieu dung, dang cleanup roi thoat...\n");
    // dong DB, flush log, xoa file tam o day
    return 0;
}

Đáp án: TODO 1 = on_signal (hàm handler đặt stop = 1); TODO 2 = !stop (lặp chừng nào cờ chưa bật, thoát vòng khi handler đã bật cờ). Khớp lại: signal(SIGTERM, on_signal); và while (!stop) { ... }.

Lý do handler chỉ đặt cờ: signal handler chạy bất đồng bộ, chen vào giữa bất kỳ lệnh nào của chương trình chính — kể cả giữa lúc chương trình đang ở trong malloc hay printf. Một hàm async-signal-safe là hàm được phép gọi an toàn bên trong handler — nó reentrant (gọi lồng/ngắt giữa chừng vẫn đúng), không đụng tới lock, malloc hay buffer dùng chung với luồng chính (danh sách đầy đủ ở signal-safety(7)). Gọi hàm không async-signal-safe trong handler (như printf) có thể gây deadlock hoặc hỏng dữ liệu. Pattern an toàn: handler chỉ đặt một cờ kiểu volatile sig_atomic_t. Từ khoá volatile buộc compiler đọc lại biến từ bộ nhớ mỗi lần thay vì cache trong register — để vòng lặp chính thật sự thấy thay đổi mà handler vừa ghi; còn sig_atomic_t là kiểu mà đọc/ghi một lần là nguyên tử, không bị signal chen ngang giữa chừng. Vòng lặp chính thấy cờ rồi tự cleanup ở ngữ cảnh bình thường.

5. Pitfall tổng hợp

❌ Nhầm 1 — tưởng kill luôn là "giết chết ngay":

kill 4821        # gui SIGTERM (15) -- yeu cau dung LICH SU, khong phai giet ngay
kill -9 4821     # day moi la SIGKILL -- giet cung

✅ kill <pid> mặc định gửi SIGTERM, cho tiến trình cơ hội cleanup. Chỉ kill -9 (hoặc kill -KILL) mới là SIGKILL không cưỡng lại được. Thói quen tốt: kill (SIGTERM) trước, chờ vài giây, kill -9 chỉ khi nó lì.

❌ Nhầm 2 — làm việc nặng (I/O, malloc) ngay trong signal handler:

void handler(int sig) {
    printf("Shutting down...\n");   // RUI RO: printf khong async-signal-safe
    save_to_database();            // RAT RUI RO: co the deadlock/hong du lieu
}

✅ Handler chen bất đồng bộ vào giữa code chính, kể cả giữa một lời gọi thư viện. Chỉ làm thao tác async-signal-safe — điển hình là đặt một cờ volatile sig_atomic_t. Cleanup thật để vòng lặp chính làm sau khi thấy cờ.

❌ Nhầm 3 — cố bắt SIGKILL để "chống bị giết":

signal(SIGKILL, my_handler);   // VO ICH: SIGKILL khong the bat

✅ SIGKILL và SIGSTOP không thể catch/block/ignore — lời gọi trên bị bỏ qua. Đừng thiết kế logic dựa trên việc "dọn dẹp khi bị SIGKILL": không có cơ hội đó. Mọi cleanup phải gắn vào SIGTERM (bắt được). SIGKILL là điểm cụt.

6. 📚 Deep Dive

7. Liên hệ các bài khác

• Zombie & orphan: SIGCHLD là signal kernel gửi cho cha khi con chết — cơ sở để reap không block (bắt SIGCHLD, gọi waitpid với WNOHANG).
• fork, exec, wait: disposition signal được thừa kế qua fork và (một phần) reset qua exec — vòng đời signal gắn với vòng đời tiến trình.
• System call là gì: kill, sigaction là system call; và việc SIGKILL không bắt được là biểu hiện của ranh giới quyền lực kernel/user.
• Mini-challenge — mổ xẻ cây tiến trình: bạn sẽ tự gửi SIGTERM vs SIGKILL lên một tiến trình thật và quan sát khác biệt.

8. Tóm tắt

• SIGKILL (9) và SIGSTOP (19) không thể catch/block/ignore — kernel thực thi trực tiếp; van an toàn đảm bảo OS luôn kiểm soát được tiến trình.
• Graceful shutdown: handler bắt SIGTERM chỉ đặt cờ (atomic, async-signal-safe — không gọi malloc/printf trong handler); vòng lặp chính đọc cờ và cleanup thật.
• docker stop: SIGTERM → chờ 10 giây (mặc định, đặt bằng -t) → SIGKILL; K8s terminationGracePeriodSeconds cần lớn hơn timeout cleanup.
• Dùng tên hằng (SIGKILL, SIGTERM, SIGSTOP) thay vì số trần (9, 15, 19) — số thay đổi theo kiến trúc (ví dụ SIGSTOP là 19 trên x86 nhưng 23 trên MIPS).

9. Tự kiểm tra

Bài tiếp theo: Mini-challenge — mổ xẻ cây tiến trình thật