Bộ giám sát của chúng tôi đã khởi động lại các dịch vụ mà chúng tôi đã chủ động dừng

Vận hành2026-10-31

Một trong các bộ giám sát của chúng tôi sẽ khởi động bất kỳ dịch vụ nào được bật nhưng chưa chạy. Hai lần trong tháng Mười, nó đã khởi động các dịch vụ mà chúng tôi đã chủ động dừng. Lần thứ hai, khách truy cập vào một trong các trang web của chúng tôi gặp lỗi trong khoảng 45 phút.

Lý do bộ giám sát này tồn tại

Một dịch vụ thoát sạch khi nhận SIGTERM, ví dụ vì một tiến trình nào đó đã kết thúc nó theo tên, không được systemd coi là "failed". Restart=on-failure không khởi động lại nó, và systemctl --failed cũng không liệt kê nó. Nó vẫn dừng cho đến khi ai đó tình cờ phát hiện ra. Vì vậy, bộ giám sát tìm kiếm các dịch vụ được bật nhưng chưa chạy, và khởi động chúng.

Vấn đề là một dịch vụ bạn dừng thủ công trông giống hệt như vậy.

Lần đầu tiên

Vào ngày 7 tháng Mười, chúng tôi đã dừng một worker xử lý video bằng systemctl stop lúc 12:47 để chỉnh sửa hàng đợi công việc của nó. Lúc 12:55, nó lại đang chạy: bộ giám sát đã khởi động nó.

Lần thứ hai

Vào ngày 21 tháng Mười, chúng tôi cần bộ nhớ của máy chủ cũng phục vụ hai trang web của chúng tôi cho một bài kiểm tra mô hình. Một tập lệnh đã dừng các web app của các trang web, một job đồng bộ hóa và một container cơ sở dữ liệu, cũng bằng systemctl stop. Khoảng năm phút sau, một bộ hẹn giờ theo dõi các trang web, và lúc 19:14 là bộ giám sát, đã khởi động lại tunnel và các web app.

Tunnel lại tiếp nhận lưu lượng truy cập, nhưng các web app không thể phản hồi: mô hình đang được kiểm tra chiếm 114 GiB bộ nhớ của máy chủ. Từ khoảng 19:14 đến 20:00, một số khách truy cập gặp lỗi 502. Lúc 20:00, chúng tôi đã tắt tunnel, các web app và job đồng bộ hóa, đồng thời dừng bộ hẹn giờ theo dõi.

Quy tắc chúng tôi sử dụng hiện nay

• Tạm dừng một dịch vụ bằng cách tắt nó: sudo systemctl disable --now <unit>. Khôi phục nó bằng sudo systemctl enable --now <unit>. Bộ giám sát của chúng tôi chỉ xem xét các dịch vụ được bật, nên một dịch vụ đã tắt sẽ được để yên.
• Tạm dừng mọi thứ có thể khởi động lại nó: tunnel phía trước nó và bất kỳ bộ hẹn giờ nào theo dõi nó.
• Dừng ngắn hạn là một cuộc chạy đua. Nếu bạn chỉ dùng stop, hãy hoàn thành trước lần kiểm tra tiếp theo, trên các máy chủ của chúng tôi diễn ra trong vài phút.

Hai cạm bẫy systemd khác từ cùng những tháng đó

• systemctl mask --runtime không có tác dụng với unit file trong /etc/systemd/system. Các unit trong /etc có ưu tiên cao hơn mask runtime trong /run, nên lệnh vẫn thành công và dịch vụ vẫn khởi động. Để giữ một dịch vụ, chúng tôi dùng drop-in với ConditionPathExists=!/etc/<name>.hold: khi file đó tồn tại, dịch vụ sẽ không khởi động, cả khi khởi động máy lẫn khi chạy thủ công.
• systemctl is-active báo một dịch vụ oneshot đang chạy là inactive. Trong khi dịch vụ Type=oneshot đang chạy, trạng thái của nó là "activating", nên is-active in ra trạng thái đó và trả về mã 3. Vòng lặp kiểu while systemctl is-active --quiet job.service; do sleep 60; done, dự định để chờ tác vụ chạy đêm, sẽ thoát ngay lập tức. Hãy đọc trạng thái thay vào đó: active, activating, reloading hoặc deactivating đều có nghĩa là nó vẫn đang chạy.

Factory Floor theo dõi các dịch vụ đã bật nhưng không chạy. Mặc định nó chỉ báo cáo, và chỉ khởi động chúng nếu bạn bật tính năng đó. Từ phiên bản 1.0.3, cảnh báo của nó cũng cho biết cách tạm dừng một dịch vụ theo ý muốn, và runbook của nó cũng nêu điều tương tự.