我有一个bash脚本 foo.sh 位于 /etc/cron.daily 目录中，chmoded 700，由root拥有，crontab列表为root用户是来自核心Debian安装的未更改（crontab -l）。我确实以不同于crontab -l和/或crontab -e的方式运行cronjob（例如，我没有按照特定的Debian案例中的/etc/init.d/cron重启cron守护进程）。尽管测试作业文件在类似条件下运行。该脚本已调试，可以作为独立任务运行，而不会返回错误。我还检查了日志（/ var / log / syslog）并且没有任何错误。
但是：这项特殊工作根本没有执行。
答案 0 :(得分：13)
糟糕。猜猜我发现了“为什么”或者至少是“如何”：
仅重命名没有“.sh”扩展名的作业文件名解决了这个问题。
我认为这是Debian的错误，但不是，如下面的其他答案所述。
解决方案：通过从名称中删除所有.或+字符来重命名脚本
答案 1 :(得分：8)
/etc/cron.daily脚本由run-parts执行（参见man 8 run-parts）。
您可以从联机帮助页中获取剪辑：
来自/ etc / crontab的如果既没有--lsbsysinit选项也没有 然后给出--regex选项 名称必须完全由鞋帮组成 小写字母，数字， 下划线和连字符。
您可以看到每天的cron作业正在运行：
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
debian不使用anacron，并且没有为run-parts指定--lsbsysinit选项（在这种情况下'。'将在cron脚本文件名中根据LSB层次结构和保留名称空间接受）
无论如何，为了确保cron能够运行你的脚本，你总是可以运行run-parts并检查你的脚本是否在run-parts输出中列出：
run-parts --test /etc/cron.daily
或
run-parts --list /etc/cron.daily
我希望我的评论可以帮助您了解真正的问题。
答案 2 :(得分：0)
之前给出的所有答案都是好的，并且可以接受。但是，我相信我应该加上我的观点，以表明Debian Linux操作系统不支持包含.或+字符的cron作业文件名。请参阅relevant section中的Debian Policy Manual。
所以这只是为了避免混淆，这不是一个错误。这就是Debian的工作方式。