我有一个运行24×7的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以查看它是否正常运行。
有没有人有其他build议？
问题原来是Debian不允许'。' 在/etc/cron.(d|daily|weekly|monthly)存储的cron作业的文件名中。 删除'。'，作业运行良好。
是cron的日志显示任何错误，或者他们在指定的时间运行？
如果你看到进程在运行的时候运行（如果他们计划在下午4点运行，那么系统在进程列表中看起来如何，在4点01分logging呢？
愚蠢的问题，但你说你从日志看到电子邮件，但没有任何其他工作。 你是否仔细检查过这些工作实际上是否失败，而不是通过电子邮件通知你完成的工作？
作业是否以正确的用户上下文运行，并且有权限执行所需的操作？ 这些只是有时失败，而不是别人？
你能发现在那些失败的时代发生了什么事情吗？但是在其他时候（你说这是一个非停机时间的系统……它是在做一些脚本重叠的事情，所以他们不能完成？或者有一些stream程阻止他们？）
系统上是否configuration了某些负载级别杀死进程的东西？ 看门狗定时器等可能会在进程负载过大或处理器/ RAM配额过高等情况下终止进程，或者系统无响应。 另外一个原因是，当服务器应该运行这个工作的时候，有人可以通过ssh会话来关注它。
巴特钉了我会寻找的一切，除了磁盘空间。 当这些工作一起运行到空间不足时？ 当时是否还有其他事情发生，可能会给驱动器空间带来巨大的临时负载？
如果可以的话，你可以尝试的另一件事是在不同的时间运行它们。 要么一下子说5点，要么一个一个，4点/ 4点半/ 5点/ 5点半/等等…
另一件事可能是环境。 有脚本已经成功运行通过cron？ cron环境可能与您的testing环境（PATH，…）不同。 是否有可能使用logging器或回显命令将日志logging添加到备份脚本？
我也遇到了同样的问题。 在脚本名称。 删除任何'。' 在脚本名称解决了我的问题（甚至扩展名“.sh”！）
运行部件的–lsbsinit或–regex选项允许您更改哪些文件名被认为是有效的。