![Debian/Ubuntu 上 /etc/cron.d/ 中看似正常的 cron 文件存在问题](https://linux22.com/image/523260/Debian%2FUbuntu%20%E4%B8%8A%20%2Fetc%2Fcron.d%2F%20%E4%B8%AD%E7%9C%8B%E4%BC%BC%E6%AD%A3%E5%B8%B8%E7%9A%84%20cron%20%E6%96%87%E4%BB%B6%E5%AD%98%E5%9C%A8%E9%97%AE%E9%A2%98.png)
我注意到 /etc/cron.d/ 中的作业没有运行,奇怪的是 X 数量的作业可以运行,但其余的不会运行。
我读过人们关于在文件名中不使用“。”的评论,我的文件中都没有任何点。
我还读到过你应该始终在每个文件末尾放置一个空白行,但这似乎没有什么区别。
最后,我从 /etc/cron.d/ 中的每个文件中删除了所有注释,这使得所有作业都能正确运行。
Cron 没有将任何错误消息放入 /var/log/syslog 或 /var/log/messages,没有 /var/log/cron(d).log
有人遇到过类似的事情吗?如果遇到过,有没有解决方案可以让评论不造成问题?
答案1
使用#
开始行进行评论。
Crontab 是不是应该在末尾有一个空行 - 也许他们在最近的版本中接受了它(?)但很长一段时间以来它一直引起问题。
通常会向 crontab 所有者发送一封邮件,告知其输出/问题。如果 crontab 属于root
,则应打开其邮箱。
答案2
快速更新上述评论
@Dennis-它们运行起来没有任何问题。
@Richard - 所有罚款都包含 Unix 行尾,如果我的任何开发人员使用 Windows 行尾,他们会立即感受到我的禁令。
没有任何输出或问题,因为 cron 文件根本就没有运行。检查邮箱是我的第一个想法。
向一项作业添加一个简单的 - echo "file ran" > /root/cron-has-worked - 确认它没有工作,同时坐在一个 shell 中观察 /var/log/syslog 并在另一个 shell 中查看 top 确认 cron 作业没有运行。
感谢您关于使用#的评论,但我知道如何评论cron文件。=P