cron 作业偶尔不运行

Question

我有一个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但这种情况一直在发生。这会影响具有相同操作系统、内核和cronRPM版本的多台服务器。

cronie( 1.4.12)有更新版本，但是升级它不是一种选择，因为我们已经在使用最新的可用版本Centos 6.6

我浏览了cronie我 ( 1.4.4)之后所有版本的变更日志，但似乎没有解决这个特定问题。还检查了所有提交消息。

Answer 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)：crontab查看底部的诊断部分，其中指出警告将写入系统日志。

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. 

Answer 2

我们用于sssd远程身份验证。crond必须在运行作业之前检查可用用户，并且每 60 秒执行一次。\nsssd默认client_idle_timeout值为 60 秒。sssd所以我们在和 之间有一个竞争条件crond

\n\n

我们只是深入了解了这个问题，因为在1.4.4-14crond 版本上，一些错误开始变得更加详细。

\n\n

* Thu Feb  5 12:00:00 2015 Tom\xc3\xa1\xc5\xa1 Mr\xc3\xa1z <tmraz@redhat.com> - 1.4.4-14\n- add log message when getpwnam fails\n

\n\n

更新到该版本后，我们开始看到以下错误，同时作业无法运行：

\n\n

[cron.err] crond[8654]: (user) ERROR (getpwnam() failed): Broken pipe\n

\n\n

这给我们带来了这个：\n https://bugzilla.redhat.com/show_bug.cgi?id=1209600#c2

\n\n

最后是：\n https://access.redhat.com/solutions/1125133

\n\n

\n

问题：sssd_be由于 getpwnam() 返回 EPIPE\n（即损坏的管道）而以 SIGKILL 终止，可能会导致 crond 默默地跳过 cron 作业条目。

\n

\n\n

上面链接上的建议解决方案是将以下行添加到/etc/sssd/sssd.conf：

\n\n

client_idle_timeout = 75\n

\n\n

上面的更改解决了我们的问题，并且 cron 不再跳过作业。

\n