Answers:
我发现的唯一可靠方法是检查日志。
cron
/etc/crontab
每分钟检查一次,并记录一条消息,指示已重新加载它或发现错误。
因此,在编辑后,运行以下命令:
sleep 60; grep crontab /var/log/syslog | tail
或者,不要等待一整分钟,而要等到下一分钟+ 5秒:
sleep $(( 60 - $(date +%S) + 5 )) && grep cron /var/log/syslog | tail
输出示例错误:
Jan 9 19:10:57 r530a cron[107258]: Error: bad minute; while reading /etc/crontab
Jan 9 19:10:57 r530a cron[107258]: (*system*) ERROR (Syntax error, this crontab file will be ignored)
好的输出:
Jan 9 19:19:01 r530a cron[107258]: (*system*) RELOAD (/etc/crontab)
那是在Debian 8上。在其他系统上,cron可能会记录到另一个文件。
(我以为我可以避免使用systemd的日志文件来寻找正确的日志文件journalctl -u cron
,但这并没有向我显示这些日志条目,并且实际上由于某些原因,它似乎已经在两天前停止记录cron事件了)
我在这里找到了这个很酷的解决方案:https : //crontab.guru
它不仅验证crontab,还明确告诉您crontab将在何时何地运行,并突出显示错误在哪里。
在Ubuntu上,似乎可以运行:
crontab path/to/crontab/file
注意:这具有启动此cronjob的副作用(感谢@NZD)
如果文件无效,我将报错,例如:
"crontab":11: bad minute
errors in crontab file, can't install.
* 4/0 * * /bin/myscript.sh
- 4/0
无效。但没有被这种方法捕获
0
禁止的吗?unix.stackexchange.com/questions/32027/…–