我有一台 Debian GNU/Linux 4.0 机器（无法升级），全天候运行。/etc/cron.daily 中有几项任务，包括我们的备份脚本。几周前我注意到备份脚本没有按任何规律运行。
今天早上，我手动运行了 cron 目录 ( nice run-parts --report /etc/cron.daily)，它在/etc/anacrontab和中都可以看到/etc/crontab。我收到了 logwatch 的电子邮件，但没有收到其他任何作业的电子邮件。具体来说，我们的备份脚本有大量输出，需要几个小时。我尝试重新安排 中的作业/etc/cron.daily，但没有效果，我最近删除了anacron，因为这个框“永远”不应该遇到停机。
单独运行任何作业似乎都运行良好。我刚刚/etc/crontab手动添加了备份脚本，以查看它是否运行正常。
还有其他建议吗？
答案1
问题在于 Debian 不允许在 中存储的 cron 任务的文件名中使用“.” 。/etc/cron.(d|daily|weekly|monthly)删除“.”，任务就可以正常运行。
答案2
cron 的日志是否显示任何错误，或者它们是否在指定的时间运行？
如果您观察进程在预定运行时间运行时，会发生什么情况（例如，如果它们计划在下午 4:00 运行，那么系统在 4:01 的进程列表和日志中是什么样子的？
愚蠢的问题，但您说您收到了来自 logwatch 的电子邮件，但没有收到任何其他作业的电子邮件。您是否仔细检查过这些作业是否确实失败了，而不是通知您作业已完成的电子邮件存在通信问题？
作业是否在适当的用户上下文中运行，并具有执行所需操作的权限？这些作业有时失败，有时失败？
您是否发现在它们失败而在其它时间没有发生的那些时间里发生了什么事情（您说这是一个无停机系统...它是否在做一些脚本重叠的事情以至于它们无法完成？或者有进程会阻止它们？）
系统上是否配置了某些功能来终止特定负载级别的进程？如果负载过大、处理器/内存配额过高等，或者系统变得无响应，看门狗定时器等可能会终止进程。另一个原因是，看看是否有人在服务器应该运行作业时通过 ssh 会话来监视它。
答案3
Bart 几乎说出了我要寻找的所有问题，除了磁盘空间。当所有作业同时运行而空间不足时？那时是否还有其他事情发生，可能会对驱动器空间造成巨大的临时负载？
如果可以的话，您还可以尝试在不同的时间运行它们。要么同时运行，比如 5:00，要么分别运行，比如 4:00 / 4:30 / 5:00 / 5:30 / 等等...
答案4
我也遇到了与脚本名称中的“.”相同的问题。删除脚本名称中的任何“.”即可解决我的问题（甚至扩展名“.sh”！）