我有一个 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 中有一个条目也同时调用相同的脚本。
不像调试闰秒问题那样在智力上严格！