经常, crontab 脚本不会按计划或按预期执行。 这有很多原因:
- 错误的crontab符号
- 权限问题
- 环境变量
这个社区维基的目的是汇总 crontab 未按预期执行的脚本。 将每个原因写在单独的答案中。
请在每个答案中包含一个原因-关于为什么不执行的详细信息-并为此原因修复（es）。
请只编写特定于cron的问题，例如从shell中按预期执行但cron错误执行的命令。
不同的环境
Cron将一组最小的环境变量传递给您的作业。 要查看差异，请添加一个像这样的虚拟作业:
>*****env/tmp/env。输出
等待 /tmp/env.output 要创建，然后再次删除作业。 现在比较一下 /tmp/env.output 随着输出 env 在您的常规终端运行。
一个常见的"问题"是 PATH 环境变量是不同的。 也许你的cron脚本使用命令 somecommand 发现于 /opt/someApp/bin，你已经添加到 PATH 在 /etc/environment? cron忽略 PATH 从该文件，所以runnning somecommand 使用cron运行时，脚本将失败，但在终端中运行时可以工作。 值得注意的是，变量从 /etc/environment 将传递给cron作业，只是不是cron专门设置自己的变量，例如 PATH.
要解决这个问题，只需设置自己的 PATH 脚本顶部的变量。 例如。
#!/bin/bashPATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin# rest of script follows有些人更喜欢只使用绝对路径来代替所有命令。 我建议不要这样做. 考虑一下，如果你想在不同的系统上运行你的脚本会发生什么，并且在该系统上，命令在 /opt/someAppv2.2/bin 相反。 你必须通过整个脚本替换 /opt/someApp/bin 与 /opt/someAppv2.2/bin 而不是只在脚本的第一行做一个小的编辑。
您还可以在crontab文件中设置PATH变量，该变量将应用于所有cron作业。 例如。
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin15 1 * * * backupscript --incremental /home /root我的top gotcha：如果你忘记在 crontab 档案。 换句话说，crontab文件应该以空行结尾。
以下是此问题手册页的相关部分（man crontab 然后跳到最后）:
Although cron requires that each entry in a crontab end in a newline character, neither the crontab command nor the cron daemon will detect this error. Instead, the crontab will appear to load normally. However, the command will never run. The best choice is to ensure that your crontab has a blank line at the end. 4th Berkeley Distribution 29 December 1993 CRONTAB(1)Cron守护进程未运行。 几个月前我真的搞砸了。
类型:
pgrep cron 如果你看到没有数字（即cron的主PID），那么cron没有运行。 sudo /etc/init.d/cron start 可用于启动cron。
编辑：而不是通过/etc/init调用init脚本。d、使用serviceutility，例如
sudo service cron start编辑：你也可以在现代Linux中使用systemctl，例如
sudo systemctl start cron脚本文件名在 cron.d/, cron.daily/, cron.hourly/ 等。，不应包含点（.），否则run-parts将跳过它们。
见运行部件(8):
If neither the --lsbsysinit option nor the --regex option is given then the names must consist entirely of upper and lower case letters, dig‐ its, underscores, and hyphens. If the --lsbsysinit option is given, then the names must not end in .dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to one or more of the following namespaces: the LANANA-assigned namespace (^[a-z0-9]+$); the LSB hierarchical and reserved namespaces (^_?([a-z0-9_.]+-)+[a-z0-9]+$); and the Debian cron script namespace (^[a-zA-Z0-9_-]+$).所以，如果你有一个cron脚本 backup.sh, analyze-logs.pl 在 cron.daily/ 目录，你最好删除扩展名。
在许多环境中，cron使用 sh，而许多人认为它会使用 bash.
针对失败的命令测试或修复此问题的建议:
-
尝试运行命令
sh看看是否有效:sh -c "mycommand" -
将命令包装在bash子shell中，以确保它在bash中运行:
bash -c "mybashcommand" -
告诉cron通过在crontab顶部设置shell来运行bash中的所有命令:
SHELL=/bin/bash -
如果命令是脚本，请确保脚本包含一个shebang:
#!/bin/bash
我在时区方面有些问题。 Cron正在使用全新安装时区运行。 解决方案是重新启动cron:
sudo service cron restart脚本应该使用绝对路径:
例如, /bin/grep 应该使用而不是 grep:
# m h dom mon dow command0 0 * * * /bin/grep ERROR /home/adam/run.log &> /tmp/errors而不是:
# m h dom mon dow command0 0 * * * grep ERROR /home/adam/run.log &> /tmp/errors这特别棘手，因为从shell执行时相同的命令将起作用。 原因是 cron 不具有相同 PATH 环境变量作为用户。
如果你的crontab命令有一个 % 符号在其中，cron试图解释它。 所以，如果你使用任何命令与 % 在其中（例如日期命令的格式规范），您将需要转义它。
Cron正在调用不可执行的脚本。
通过运行 chmod +x /path/to/script，脚本变为可执行文件，这应该可以解决此问题。
用户的密码也可能已过期。 甚至root的密码也可能过期。 你可以 tail -f /var/log/cron.log 你会看到cron失败，密码过期。 您可以通过执行此操作将密码设置为永不过期: passwd -x -1 <username>
在某些系统（Debian，Ubuntu）中，默认情况下不启用cron的日志记录。 在 /etc/rsyslog。conf 或 /etc/rsyslog。d/50-默认值。conf 该行:
# cron.* /var/log/cron.log应编辑（sudo nano /etc/rsyslog.conf）未提交给:
cron.* /var/log/cron.log之后，您需要通过以下方式重新启动rsyslog
/etc/init.d/rsyslog restart或
service rsyslog restart 资料来源: 在Debian Linux中启用crontab日志记录
在某些系统（Ubuntu）中，默认情况下不启用cron的单独日志记录文件，但系统日志文件中出现了cron相关日志。 一个可以使用
cat /var/log/syslog | grep cron -i以查看与cron相关的消息。
你必须关闭"crontab-e"才能影响cron。 例如，使用vim我编辑文件并使用：w'来写它，但是在我退出之前，作业不会添加到cron中。 所以直到I:q`之后我才会看到工作。
我认为调试cron的最佳方法是检查syslog并找到问题。
在我的情况-电子邮件是去我的垃圾邮件文件夹，所以。… 在花费数小时进行调试之前，请检查一下：D
请检查一下这个https://askubuntu.com/a/1223213/297387