我有一台CentOS 6.6
安装了以下软件包的服务器:
crontabs-1.10-33.el6.noarch
cronie-1.4.4-12.el6.x86_64
cronie-anacron-1.4.4-12.el6.x86_64
kernel-2.6.32-504.3.3.el6.x86_64
有时,计划每天运行的备份作业之一根本就不会运行。甚至不会根据调用脚本/var/log/cron.log
。有趣的是,计划在同一时间运行的其他作业运行没有任何问题。
我无法重现该问题,也没有发现任何模式。如果我什么都不做,那么第二天该作业就会按预期正确运行。
crond 只是忽略了在特定时间应该运行的多个作业中的一个。这种情况偶尔会发生。
我在其他几个地方看到有人谈论在文件末尾添加一个空行crontab
。偶尔无法运行的作业确实位于我的crontab
文件的最后一行。我找不到任何证据来证实这是一个真实或已知的错误。
# tail -2 /var/spool/cron/postgres
* * * * * OTHERJOB
0 21 * * * /pg_backup.sh
这就是我所有的一切/var/log/cron.log
Mar 31 21:00:02 SERVERNAME [cron.info] CROND[19394]: (root) CMD (OTHERJOB)
Mar 31 21:00:02 SERVERNAME [cron.info] CROND[19418]: (postgres) CMD (/pg_backup.sh)
Mar 31 21:01:02 SERVERNAME [cron.info] CROND[20062]: (root) CMD (OTHERJOB)
Apr 1 21:00:02 SERVERNAME [cron.info] CROND[31349]: (root) CMD (OTHERJOB)
Apr 1 21:01:01 SERVERNAME [cron.info] CROND[32080]: (root) CMD (OTHERJOB)
看看为什么OTHERJOB
总是在运行而Apr 1
pg_backup.sh
没有被执行。
我已经尝试过重启crond
,但这种情况还是会发生。这影响了多台具有相同版本操作系统、内核和cron
RPM 的服务器。
有cronie
( 1.4.12
) 的较新版本,但无法升级,因为我们已在使用最新可用版本Centos 6.6
我查看了cronie
在我之后的所有版本的更新日志(1.4.4
),似乎没有针对此特定问题的任何修复。还检查了所有提交信息。
答案1
原始 cron 要求每个条目以换行符结尾,所以有时您确实需要在末尾添加一个空行或其他内容。
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)
有些版本已修复此问题或发出警告,例如 Ubuntu Maverik (10.10):定时任务查看底部的诊断部分,其中指出将向系统日志写入警告。
DIAGNOSTICS
cron requires that each entry in a crontab end in a newline character.
If the last entry in a crontab is missing a newline (ie, terminated by
EOF), cron will consider the crontab (at least partially) broken. A
warning will be written to syslog.
答案2
这是搜索文本出现的第一个答案cron error getpwname failed
,所以我想我会发布我的问题的原因:
我正在使用 /etc/crontab,但忘记将用户放在命令前面。
IE,
*/5 * * * * /bin/bash <filename>
代替
*/5 * * * * root /bin/bash <filename>
它给出了同样的错误,去想想吧。
答案3
我们用于sssd
远程身份验证。crond
必须在运行作业之前检查可用用户,并且每 60 秒检查一次。
sssd
默认client_idle_timeout
值为 60 秒。所以我们在sssd
和之间有一个竞争条件crond
我们之所以能彻底解决这个问题,是因为1.4.4-14
crond 版本开始对某些错误进行更为详细的说明。
* Thu Feb 5 12:00:00 2015 Tomáš Mráz <[email protected]> - 1.4.4-14
- add log message when getpwnam fails
更新到该版本后,我们开始看到以下错误,同时作业无法运行:
[cron.err] crond[8654]: (user) ERROR (getpwnam() failed): Broken pipe
这让我们想到了这一点: https://bugzilla.redhat.com/show_bug.cgi?id=1209600#c2
最后是这个: https://access.redhat.com/solutions/1125133
问题:
sssd_be
由于 getpwnam() 返回 EPIPE(即管道损坏)而以 SIGKILL 终止,可能导致 crond 默默跳过 cron 作业条目。
上面链接中建议的解决方案是添加以下行/etc/sssd/sssd.conf
:
client_idle_timeout = 75
上述更改已为我们解决问题,并且 cron 不再跳过作业。