- Bài viết cảnh báo các lỗi tác vụ cron xảy ra khi chuyển đổi giờ tiết kiệm ánh sáng ban ngày (DST) trên máy chủ Linux
- Mỗi năm hai lần, khi múi giờ thay đổi vào 2 giờ hoặc 3 giờ sáng Chủ nhật, có thể xảy ra việc tác vụ cron chạy lặp hoặc bị bỏ sót
- Một trường hợp thực tế cho thấy trong môi trường vixie-cron, các tác vụ từ 3:00 đến 3:01 đã lặp lại 60 lần với khoảng cách 1 giây, gây tắc nghẽn email
- Các giải pháp được đề xuất gồm đặt múi giờ UTC hoặc tránh lập lịch tác vụ vào khung giờ đó, cùng với việc phát triển một trình lập lịch mã nguồn mở tốt hơn
- Đây là ví dụ nhắc nhở các quản trị viên máy chủ và kỹ sư DevOps về tầm quan trọng của việc quản lý rủi ro khi chuyển đổi múi giờ
Xung đột giữa giờ tiết kiệm ánh sáng ban ngày và tác vụ cron
- Nếu thiết lập tác vụ vào 2 giờ hoặc 3 giờ sáng Chủ nhật, nó có thể trùng với thời điểm chuyển đổi giờ tiết kiệm ánh sáng ban ngày (DST) và gây ra lỗi chạy ngoài dự kiến
- Khi DST bắt đầu, đồng hồ sẽ nhảy tiến lên một giờ; khi DST kết thúc, đồng hồ sẽ lùi lại một giờ, dẫn đến hiện tượng trùng lặp hoặc thiếu mất một khoảng thời gian
- Vì vậy, các tác vụ trong khung giờ đó có thể chạy hai lần hoặc hoàn toàn không chạy
- Đặc biệt, các tác vụ chạy vào rạng sáng Chủ nhật hằng tuần sẽ bị ảnh hưởng tại hai thời điểm chuyển DST mỗi năm
- Bình thường chúng hoạt động ổn định, nhưng vào ngày chuyển DST có thể xuất hiện việc lặp chạy bất thường
Trường hợp thực tế: vấn đề chạy lặp trong vixie-cron
- Trong môi trường Linux dùng vixie-cron, đã có báo cáo rằng khi DST bắt đầu, các tác vụ từ 3:00 đến 3:01 bị chạy khoảng 60 lần với khoảng cách 1 giây
- Các tác vụ va chạm lẫn nhau, gây hỗn loạn như email thông báo bị gửi dồn dập
- May mắn là các tác vụ này không mang tính sống còn nên không làm hỏng hệ thống
- Vấn đề này bắt nguồn từ cấu trúc lập lịch đơn thuần theo thời gian của cron
- Cron không nhận biết việc thay đổi múi giờ hay chuyển DST, mà chỉ đơn giản chạy theo thời điểm đã chỉ định
Các cách khắc phục và phương án thay thế
- Cách đơn giản nhất là không đặt tác vụ vào khung 2 giờ và 3 giờ sáng Chủ nhật
- Tránh khung giờ này sẽ loại bỏ hoàn toàn vấn đề chạy lặp do chuyển DST
- Đặt múi giờ của máy chủ sang UTC cũng là một lựa chọn hiệu quả
- UTC không áp dụng giờ tiết kiệm ánh sáng ban ngày nên sẽ không có thay đổi thời gian
- Một giải pháp căn cơ hơn là phát triển trình lập lịch tác vụ thông minh hơn
- Cần có công cụ thay thế mã nguồn mở với các tính năng như ngăn chạy trùng, giới hạn thời gian chạy, và nhận biết múi giờ
Đề xuất dài hạn: bãi bỏ giờ tiết kiệm ánh sáng ban ngày
- Tác giả cho rằng bãi bỏ DST ở cấp chính phủ là giải pháp đáng mong muốn nhất
- Việc đổi giờ hai lần mỗi năm tạo ra sự phức tạp không cần thiết cho cả vận hành hệ thống lẫn đời sống con người
- Tuy nhiên, chừng nào DST vẫn còn được duy trì, quản trị viên hệ thống và kỹ sư DevOps phải chủ động phòng ngừa
- Đặc biệt cần cẩn trọng với các tác vụ phụ thuộc vào thời gian như batch tự động, sao lưu, xoay vòng log
Kết luận: nguyên tắc lập lịch cron an toàn
- Cần tránh các tác vụ trong khung 2:00~3:00 tại thời điểm chuyển DST
- Nếu có thể, hãy vận hành máy chủ theo UTC để loại bỏ vấn đề múi giờ
- Cần nhận thức giới hạn của cron và cân nhắc đưa vào các công cụ lập lịch vững chắc hơn
- Trong môi trường DevOps, quản lý múi giờ và đảm bảo độ tin cậy của tự động hóa là yêu cầu thiết yếu
2 bình luận
Tôi cũng luôn tránh các tác vụ được đặt vào lúc 2 giờ sáng, vì sau khi gặp sự cố với một tác vụ chạy vào 2 giờ sáng (có lần thì chạy hai lần, có lần thì không chạy) thì tôi rút kinh nghiệm như vậy.
Ý kiến trên Hacker News
Tôi nghĩ DST (giờ tiết kiệm ánh sáng ban ngày) là một chế độ hoàn toàn sai lầm
Nó chẳng giải quyết được vấn đề gì mà còn chỉ gây bất tiện
Cứ cố định ở giờ chuẩn thôi, rồi thay vào đó đẩy giờ làm lên sớm hơn một tiếng như giờ mùa hè là được
Ví dụ mở cửa hàng lúc 6 giờ thay vì 7 giờ, và đóng lúc 9 giờ thay vì 10 giờ
Dù sao mỗi năm cũng phải có giai đoạn thích nghi hai lần, nên chỉ đổi một lần là đủ
Tôi muốn được thấy ánh sáng mặt trời nhiều hơn sau giờ làm. Mùa đông thì lại càng như vậy, còn việc trời sáng lúc đi làm thì tôi không quan tâm
Đằng nào tôi cũng bị nhốt trong nhà 9 tiếng, nên tôi muốn có ánh nắng khi còn thời gian tự do
Ví dụ có thử nghiệm DST quanh năm ở Mỹ giai đoạn 1973~1975
Ban đầu dư luận ủng hộ khá cao vì các lý do như tiết kiệm năng lượng và giảm tội phạm,
nhưng sau đó tai nạn trên đường đi học buổi sáng trời tối khiến dư luận xấu đi rất nhanh và cuối cùng nó bị bãi bỏ
(trích dẫn Wikipedia)
Nghe như là đang muốn một mức dịch chuyển thời gian còn lớn hơn nữa
Chỉ có giờ chuẩn và giờ tiết kiệm ánh sáng ban ngày mà thôi
Cách nói rằng nên luôn duy trì “giờ mùa đông” không hấp dẫn về mặt tâm lý
Mọi người muốn bắt đầu ngày mới khi trời đã sáng
Lập trình viên đúng là khổ vì DST, nhưng tôi nghĩ đó là vấn đề cần xử lý tốt các edge case
Mỗi người có nhịp ngủ khác nhau, nên nếu ai cũng có thể chọn khung giờ làm phù hợp với mình thì xung đột sẽ giảm đi
Hồi trước khi thiết lập máy chủ reddit, tôi đặt tất cả theo múi giờ Arizona
Arizona không dùng DST, nên chỉ lệch California 1 tiếng
Lý do không dùng UTC là vì khi đọc log, ‘trừ 1 dễ hơn trừ 8’
Bây giờ thì đã chuyển sang UTC vì có đội ngũ toàn cầu rồi
Tốt nhất là ngay từ đầu cứ thống nhất toàn bộ bằng UTC
Kiểu thay đổi này diễn ra khá thường xuyên trên toàn thế giới, nên với lập trình viên làm ứng dụng lịch thì thật sự rất đau đầu
Nếu đã chọn UTC thì nên mặc định người dùng hiểu định dạng YYYY-MM-DD 24 giờ
nhưng vì trong tổ chức ai cũng tự đổi sang PST để dùng nên sinh ra hỗn loạn do log nào cũng có thời gian khác nhau
Cuối cùng lãnh đạo phải đứng ra thống nhất mọi ứng dụng và DB theo PST
Dù vậy giờ thì tôi đã gần như giải nghĩa UTC theo bản năng rồi
Trước đây tôi từng cấu hình máy chủ công ty theo BST (giờ mùa hè Anh) và dùng cron rất nhiều,
nên mỗi năm hai lần sự hỗn loạn lại lặp lại
Cuối cùng cho tới lúc công ty phá sản vẫn không sửa được
Bài học rất đơn giản — hãy dùng UTC, trừ khi có lý do đặc biệt
Ví dụ reset giới hạn sử dụng hay batch job tính cước sẽ chạy theo giờ khu vực
Ví dụ báo cáo 8 giờ ở Anh sẽ có mốc UTC khác nhau tùy DST
Vì vậy chỉ dùng UTC là không đủ, mà cần lưu cả thông tin múi giờ
Ở một số quốc gia (Cuba, Ai Cập, Lebanon), việc đổi DST diễn ra vào lúc nửa đêm
(liên kết liên quan)
Ở Brazil, chuyện đổi vào 00:00~01:00 hoặc 00:00~23:00 từng khá phổ biến
Có nghiên cứu cho thấy vào ngày điều chỉnh DST, tỷ lệ tử vong và số ca vào phòng cấp cứu tăng vọt
(bài ScienceAlert)
Đây không chỉ là vấn đề cron nữa, mà DST còn là một chế độ có hại cho sức khỏe
Vấn đề này thật ra đã được OpenBSD và Debian giải quyết từ lâu
Trong trang hướng dẫn cron(8) của Debian có mô tả logic xử lý khi thời gian dịch chuyển dưới 3 tiếng lúc điều chỉnh DST
(liên kết bản vá,
hướng dẫn,
báo cáo lỗi)
Đây là lời khuyên rằng đừng lên lịch tác vụ vào nửa đêm (00:00)
Vì rất dễ nhầm ngày, nên tốt hơn là dùng những thời điểm lưng chừng như 00:01 hay 01:45
Khi hệ thống có gì bất thường vào một thời điểm cụ thể thì sẽ dễ lần ra nguyên nhân hơn
Chỉ là trong môi trường dùng đồng hồ 12 giờ thì có thể phát sinh nhầm lẫn
Trước khi tự mình gặp vấn đề múi giờ thì tôi không hề biết,
trên đời lại có những thời điểm không tồn tại và những thời điểm mơ hồ
Ví dụ khi chuyển từ 2 giờ sang 3 giờ thì 2:30 không tồn tại,
còn khi chỉnh lùi giờ thì 2:30 lại xuất hiện hai lần
Thời điểm điều chỉnh DST khác nhau theo từng quốc gia, nên có nơi như Chile bị biến mất cả nửa đêm
(blog liên quan)
Tôi nhớ hồi đầu làm ở Stripe, Java và Ruby xử lý tình huống này khác nhau nên đã gây ra 3 sự cố liên tiếp
Với cron job, hãy tránh đúng đầu giờ, và nếu có thể thì đặt sau 4 giờ sáng hoặc trước nửa đêm
Vì trên hạ tầng dùng chung, cạnh tranh tài nguyên vào đúng đầu giờ rất gay gắt
sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ;trước lệnh cronđể tạo độ trễ ngẫu nhiên 0~59 phút cũng là một cách hay
Các tác vụ lên lịch quan trọng nên được thiết kế idempotent (an toàn khi chạy lặp) nếu có thể
Đặc biệt khi có hệ thống hàng đợi liên quan, kiểu thiết kế này là chìa khóa để phòng ngừa sự cố