我在ubuntu服务器上使用crontab -e在每天凌晨02:00运行一个backup.sh文件。 我写道： 00 02 * * * root /home/backup.sh然后/etc/init.d/cron restart当crontab -l显示： 00 02 * * * root /home/backup.sh 。 我可以自己运行backup.sh，它工作正常。 但是它没有按计划自动工作。
当您以用户作业运行cron作业（使用crontab -e编辑作业）时，您不指定用户。 如果您运行系统cron作业，那么您可以指定用户。
可以使用vi或nano等编辑器将该行放入/etc/crontab或/etc/cron.d/yourfile或者在/home/backup.sh之前删除“root”
另外需要注意的是，要确保你的脚本中包含mysqldump这样的所有程序，要么使用完整path，要么确保它们在你的脚本执行环境PATH中（与shell的PATH不同）。 看到：
man 5 crontab
示例CRON文件
示例系统CRON文件
将错误消息redirect到日志文件并检查。
/home/backup.sh 2>1 /home/backup.output
这很可能是一个正确的或path的问题。
有两点要讲：
以下是我的想法：
你确定cron守护进程正在运行吗？ 核实。
如果是，应该logging它执行的所有作业，通常你可以在/ var / log / messages中find它。 检查当时是否真的试图执行这个命令。
检查cron脚本权限。
如果是这样，问题可能是不同的环境 – 在cron下执行的作业可能有不同的$ PATH（所以你需要在脚本中指定命令的完整path）。 Cron应该邮件错误（实际上是任何）输出的作业运行。 在/ etc / aliases中检查/ var / mail / root文件或设置邮件别名root – > yout @ email。
尝试以这种方式编辑crontab：
0 2 * * * root /home/backup.sh
并确保给脚本执行权限。
你不需要“根”部分。 这只适用于/ etc / crontab。
试试这个：
00 02 * * * /home/backup.sh。
并确保你的crontab在应该运行的行末有回车符。 这是许多Cron实现中的一个已知错误，它会阻止文件的最后一行执行。
更好的是，只需在你的crontab文件的底部添加一个“＃”字符。