并非 /etc/cron.daily 中的所有 cron 作业都在运行

Question

我有一个 Debian GNU/Linux 4.0 机器（无法升级）24x7 运行。它在 /etc/cron.daily 中有几个作业，包括我们的备份脚本。几周前我注意到备份脚本没有正常运行。

今天早上，我手动运行了 cron 目录 ( nice run-parts --report /etc/cron.daily)，它在/etc/anacrontab和/etc/crontab. 我收到了一封关于 logwatch 的电子邮件，但没有收到任何其他工作的电子邮件。具体来说，我们的备份脚本有大量输出，需要几个小时。我曾尝试重新安排 中的工作/etc/cron.daily，但没有效果，最近我删除了anacron，因为此框应该“永远”不会停机。

单独运行任何作业似乎都可以正常工作。我刚刚/etc/crontab手动添加了备份脚本以查看它是否正常运行。

有人有其他建议吗？

Answer 1

问题原来是 Debian 不允许 '.' 在存储在 .cron 中的 cron 作业的文件名中/etc/cron.(d|daily|weekly|monthly)。删除“.”，作业运行良好。

Answer 2

cron 的日志是否显示任何错误，或者它们是否在指定时间运行？

如果您观察进程在它们应该运行的时间运行会发生什么（即，如果它们被安排在下午 4:00 运行，系统在 4:01 的进程列表和日志中是什么样的？

愚蠢的问题，但你说你会从 logwatch 收到电子邮件，但不会收到任何其他工作的电子邮件。您是否仔细检查过作业实际上失败了，而不是通知您作业已完成的电子邮件存在通信问题？

作业是否作为适当的用户上下文运行，并有权执行所需的操作？这些只是有时会失败，而其他人不会？

你能找到在它们失败的那些时间发生的事情而不是其他时间（你说这是一个没有停机时间的系统......它是否在脚本重叠的地方做一些事情以至于它们无法完成？或者有进程会阻止他们？）

系统上是否有任何配置可以在特定负载级别杀死进程？如果负载太大或处理器/内存配额过高等或系统变得无响应，看门狗定时器等可能会终止进程。查看是否有人可以在服务器应该运行作业时通过 ssh 会话密切关注它的另一个原因。