我有一個 cron，設定為每週一凌晨 1 點運行
0 1 * * 1 /script/dir/script >> /script/dir/file.log
按照預期運行兩年後，它於 6 月 18 日運行了兩次，第二次調用發生在第一次調用後 0.5 - 1 秒。什麼可能導致這種情況發生？
它第一次或第二次都不是由人類運作的。
該腳本與網站關聯，但位於文件根目錄之外。
是否有可能時鐘在同一時刻同步，迫使其向後 1 秒並在凌晨 1 點重新運行 cron？
答案1
可能 jippie 終於發現了什麼：雖然閏秒確實是在 7 月 1 日插入的，但目前某些 GPS 時間系統中的錯誤（請閱讀全文），這會導致閏秒被連續宣布。換句話說，自 6 月 30 日以來，每天都有許多頂級排名時間來源宣布閏秒標誌。正如我們所說，它正在修復，請再次參考 NTP 問題郵件線程。因此，7 月 31 日/8 月 1 日，許多系統受到攻擊，就像6 月 30 日（Linux 核心崩潰）/7 月 1 日（Java CPU 問題）。
奇怪的是，它發生在6月18日。您的內核日誌大約在同一時間有任何“插入閏秒”訊息嗎？您的伺服器目前是否採用 UTC+1 (BST)？如果您在核心日誌中看到跳躍訊息，您正在執行哪個 ntpd 版本和核心版本？在我遇到的所有 ntpd 版本中，閏秒僅在該月的最後一天傳播到內核，因此整個閏秒理論在這裡可能是一個轉移注意力的東西。
答案2
我下面的回答一定是錯誤的，我混淆了日期：最近的閏秒是在 2012 年 6 月 30 日 23:59:60 UTC 插入的。不是 6 月 18 日。
當天推出的閏秒。
閏秒不像閏年那樣可預測，它們通常是由於大地震、海嘯……之類的事情引起的。哪裡有飛躍年是可以合理預測的（大約每四年） 閏秒是不是。有一個由聰明人組成的委員會（我相信在聯合國）決定應該引入閏秒。這只能提前大約 60 天預測。許多系統不喜歡在到達 ...:00 之前從 ...:59 到 ...:60 的時間。資料庫不喜歡時間被倒退一秒，它們對只出現一次的時間戳非常挑剔。
https://en.wikipedia.org/wiki/Leap_second#Announcement_of_leap_seconds
答案3
我也得到了雙重運行的 cron 。兩個同步腳本讀取和刪除錯誤訊息。不斷回到這個線程，看看是否有人發現了新的東西！
但我剛剛意識到這是 cron 的雙重輸入。我在 /etc/crontab 中有一個條目來運行 /etc/cron.quarter 中的所有腳本，並且在 /etc/cron.d 中有一個條目也同時調用相同的腳本。
不像調試閏秒問題那樣在智力上嚴格！