Cùng một chương trình: là PID 1 thì bỏ qua SIGTERM và chết sau 5,15 giây, làm tiến trình con thì dừng trong 0,11

Nhân Linux đối xử với PID 1 khác mọi tiến trình khác: nó không cài trình xử lý mặc định cho tín hiệu. Với tiến trình thường, SIGTERM không có handler nghĩa là chết. Với PID 1, không có handler nghĩa là bỏ qua.

Trong container, ứng dụng của bạn thường chính là PID 1.

Cùng chương trình, hai vị trí

Một script Python không đăng ký handler nào cho SIGTERM:

Với --init, Docker chèn một init tối giản làm PID 1 và ứng dụng thành tiến trình con — nơi ngữ nghĩa tín hiệu bình thường áp dụng trở lại. SIGTERM giết nó ngay.

Hai mã thoát cũng nói lên chuyện đó:

• 137 = 128 + 9 = SIGKILL. Docker hết kiên nhẫn và giết.
• 143 = 128 + 15 = SIGTERM. Tiến trình chết vì tín hiệu dừng, đúng như thiết kế.

Nhanh hơn 47 lần, chỉ bằng một cờ.

Việc thứ hai của init: dọn tiến trình mồ côi

PID 1 còn một nhiệm vụ nữa — nhận nuôi và dọn xác những tiến trình mất cha. Tôi viết một chương trình cố tình sinh ra 20 tiến trình cháu mồ côi rồi không bao giờ gọi wait():

Hai mươi mục zombie chiếm chỗ trong bảng tiến trình của nhân. Chúng không dùng CPU hay bộ nhớ, nhưng chúng chiếm PID — và một container chạy nhiều ngày với kiểu này sẽ chạm giới hạn PID rồi không fork được nữa, với triệu chứng là Resource temporarily unavailable ở một chỗ hoàn toàn không liên quan.

Ứng dụng nào hay dính? Bất cứ thứ gì gọi tiến trình ngoài: shell script chạy curl, ứng dụng gọi ffmpeg, thư viện sinh worker. Nếu ứng dụng của bạn không bao giờ fork thì không sao — nhưng bạn thường không biết chắc thư viện mình dùng có làm hay không.

--init không cứu được dữ liệu

Đây là chỗ dễ hiểu nhầm nhất. Tôi cho một ứng dụng ghi vào tệp có bộ đệm trong 3 giây rồi dừng container, và so số bản ghi ứng dụng đã viết với số thật sự nằm trên đĩa:

--init làm container dừng nhanh gấp 26 lần — và mất nhiều dữ liệu hơn, vì nó chết sớm hơn nên còn ít thời gian để bộ đệm tự đầy rồi tràn xuống đĩa.

Chỉ hàng cuối cho số 0. Ứng dụng phải tự xử lý SIGTERM và tự flush:

def dong(a=None, b=None):
    tep.flush()
    os.fsync(tep.fileno())
    tep.close()
    sys.exit(0)

signal.signal(signal.SIGTERM, dong)

Nói cách khác: --init giải quyết vấn đề cơ chế (tín hiệu tới được nơi cần tới), còn việc dừng tử tế là vấn đề của ứng dụng. Cần cả hai.

STOPSIGNAL khi ứng dụng nghe tín hiệu khác

Một số chương trình dùng SIGQUIT hay SIGHUP để dừng tử tế — nginx và một số máy chủ cũ chẳng hạn. Tôi thử một ứng dụng chỉ nghe SIGHUP:

STOPSIGNAL SIGHUP

Một dòng, và container chuyển từ "bị giết sau 5 giây" sang "dừng tử tế trong 0,1 giây".

Khai được ở cả ba chỗ: STOPSIGNAL trong Dockerfile, --stop-signal khi docker run, và stop_signal: trong Compose.

Bốn thứ cần đúng

Gộp lại từ bài này và phần 8:

1. Dùng dạng exec cho CMD và ENTRYPOINT, và entrypoint script kết thúc bằng exec "$@". Thiếu nó thì sh làm PID 1 và nuốt tín hiệu.
2. Thêm --init (hoặc init: true trong Compose) trừ khi ứng dụng của bạn tự nó là một init tử tế. Nó rẻ và sửa cả hai vấn đề của PID 1.
3. Xử lý SIGTERM trong ứng dụng — đóng kết nối, ghi nốt bộ đệm, rời bộ cân bằng tải.
4. Đặt --stop-timeout tường minh. Phần 3 đo được mặc định trên máy tôi là 1 giây, không phải 10 như tài liệu vẫn ghi.

Đọc mã thoát

Bảng nhỏ đáng dán lên tường:

Phân biệt hai nguyên nhân của 137 bằng OOMKilled, như phần 25 đã đo.

Thử ba mươi giây

docker run -d --name thu --stop-timeout 10 <anh-cua-ban>
docker exec thu ps -o pid,args | head -3
time docker stop thu
docker inspect thu --format 'ExitCode={{.State.ExitCode}}'
docker rm thu

Ba dấu hiệu cần nhìn:

• PID 1 là /bin/sh → thiếu dạng exec hoặc thiếu exec trong entrypoint script.
• time báo gần bằng --stop-timeout → ứng dụng không phản ứng với SIGTERM.
• ExitCode=137 → bị giết, và mọi bộ đệm chưa ghi đã mất.

Phần sau đo bốn chính sách khởi động lại, và chuyện gì xảy ra khi ứng dụng hỏng vĩnh viễn.