我尝试过很多东西，但似乎无法让它发挥作用。 我的cron中有以下2个条目：
00 21 * * 0,2,4 /scratch/.auto_preflight/sys_reboot.pl >> /scratch/.auto_preflight/.auto_reboot.log 2>&1
30 21 * * 0,2,4 /scratch/.auto_preflight/check_new_build.pl /scratch/.auto_preflight/import.txt >> /scratch/.auto_preflight/.auto_buildcheck.log 2>&1
执行后检查时，我可以看到第一个脚本成功执行。它重新启动系统。我可以看到日志和一切。但半小时后执行作业的脚本由于某种原因没有运行。甚至不留下任何日志。
现在我已经尝试更改时间并重新启动cron，然后运行，但它没有在预定的时间运行。系统重启会阻碍cron作业以某种方式执行吗？
这是我的cron版本： 了vixie-时钟守护4.1-81.el5
答案 0 :(得分：1)
cron总是留下日志：/ var / log / cron说什么？你看到你的入境试图跑吗？
重启后机器什么时候启动？这是一个真正长时间重启的情况吗？有些脚本会阻止关机/启动吗？
同时检查/ var / log / cron中同一时间范围内的其他条目。
在黑暗中刺伤：是SELinux吗？根据您的描述，它应该无关紧要，但是例如，如果您的机器以Enforcing模式启动，但稍后会将其更改为Permissive - 这可能是需要考虑的事情。所以/ etc / sysconfig / selinux的状态在这里很重要，当你可以通过调整时间成功执行你的作业时输出“sestatus”命令。
在SELinux问题的情况下，查看/var/log/audit/audit.log可能会对它有所了解。
最后一件事：简化问题而不是“特殊”脚本 - 创建“虚拟”脚本：
00 21 * * 0,2,4 reboot
30 21 * * 0,2,4 touch /tmp/foo
现在如果/ tmp / foo不存在 - 有些东西与系统搞砸了，否则它必须是失败的脚本中的某些逻辑（锁定文件等）cron没有理由不在帐户上运行重启。这样可以防止所有其他cron作业被解雇。