cron 作业不是每天都开始的答案

【问题标题】：cron job not started dailycron 作业不是每天都开始的
【发布时间】：2011-11-17 16:04:53
【问题描述】：

我在 /etc/cron.daily/backup.sh 文件中有一个脚本被允许执行和运行但没有开始发生，我阅读了手册并使用了搜索但没有掌握决定。

ls -l /etc/cron.daily/
total 52
-rwxr-xr-x 1 root root 8686 2009-04-17 10:27 apt
-rwxr-xr-x 1 root root 314 2009-02-10 19:45 aptitude
-rwxr-xr-x 1 root root 103 2011-05-22 19:08 backup.sh
-rwxr-xr-x 1 root root 502 2008-11-05 03:43 bsdmainutils
-rwxr-xr-x 1 root root 89 2009-01-27 00:55 logrotate
-rwxr-xr-x 1 root root 954 2009-03-19 16:17 man-db
-rwxr-xr-x 1 root root 646 2008-11-05 03:37 mlocate

【问题讨论】：

脚本是否可执行？ (ls -l)
它是否以正确的#开头！线？你是否指定了你正在使用的 shell 的完整路径，例如#!/bin/bash ?
@arruah 检查您的根电子邮件，看看是否有任何错误通过电子邮件发送给您！例如sudo more /var/spool/mail/root 或者如果该文件非常大，只需像这样尾随最后几百行：sudo tail -100 /var/spool/mail/root
你的/etc/cron.deny 文件应该是空的，你的/etc/cron.allow 文件应该不存在，除非你真的想使用这些文件来获得关于谁可以运行什么的细粒度权限

标签： linux ubuntu cron

【解决方案1】：

在某些 ubuntus 上，cron 作业文件名中不能有句点。见this。特别是，以下引用：

虽然目录名称中包含句点，但运行部分将不接受包含句点的文件名，并且会静默失败遇到他们的时候

正确地说，这是 ubuntu cron 运行的 run-parts 的问题，而不是 cron 本身的问题。尽管如此，它还是让我感到痛苦。

【讨论】：

仅在 Ubuntu 上吗？我在 Fedora 上，实际上我的 /etc/cron.daily/ 文件中有一个句点——例如命名为 something.cron
如果 Fedora 使用相同的 run-parts 二进制文件，那么很有可能。可以在实际的 crontab 中窥探，看看它执行/etc/cron.* 的内容做了什么，或者只是尝试在 cron.hourly 中复制一个（也许将日期回显到某个文件。）
我不知道在 Fedora 上工作，但在 Ubuntu 上不工作
是的，它正在使用 /usr/bin/run-parts 。 cheez - 我真的更喜欢将东西直接放入 crontab 的旧方法：-P
你是如何测试的？我假设你重命名了文件以删除.sh，但是你是如何测试工作的触发的？摆弄你的时钟可能不会这样做。如果我是你，我会通过从 crontab 中获取实际使用的命令来进行测试，因为 cron 本身（正如其他人指出的那样）可能不是问题。

【解决方案2】：

请检查：

1a) 是脚本可执行文件并且具有正确的所有者/组设置吗？

1b) 它是否以正确的 #! 开头？线？你是否指定了你正在使用的 shell 的完整路径，例如#!/bin/bash ?

2) 脚本在执行时会产生错误吗？例如您可以从中写入日志文件吗？您是否看到日志消息？

另外：检查拥有 crontab 的用户的电子邮件收件箱——错误会通过电子邮件发送给用户/例如根

ls -l /etc/cron.daily/ 的输出是什么样的？可以发一下吗？

注意：

您始终可以自己为此创建一个 crontab 条目，在这些 cron.xxx 目录结构之外；-)

见：man 5 crontab

 10 1 * * * /somewhere/backup.sh >> /somewhere/backup.log 2>&1

这样做的好处是您可以选择它运行的确切时间（例如这里的凌晨 1:10），并且您可以重定向 STRERR 和 STDOUT 以附加到该特定脚本的日志文件中

出于测试目的，您可以每 10 分钟运行一次，如下所示：

 0,10,20,30,40,50 * * * * /somewhere/backup.sh >> /somewhere/backup.log 2>&1

执行touch /somewhere/backup.log 以确保它存在

【讨论】：

手动此脚本运行良好，没有错误。文件是可执行的。
我知道这种解决问题的方法，但实际上有一个特殊的文件夹，不知道为什么它不能这样工作。
很奇怪。您是否尝试像@phs 建议的那样在没有 .sh 的情况下重命名脚本？
再次查看您的脚本，您正在执行 rsync... 也许 root 没有与您手动运行时相同的权限（例如 .ssh 密钥）？可能是它试图等待密码，这就是为什么你看不到它正在处理