我有一个安装了以下软件包的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的最新版本
我经历了我的（1.4.4）之后的所有cronie版本的更新日志，并且似乎没有解决这个问题。 还检查了所有提交消息 。
原来的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查看底部的诊断部分，其中指出将向syslog写入警告。
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.
这是search文字cron error getpwname failed的第一个答案，所以我想我会张贴我的问题的原因：
我正在使用/ etc / crontab，但忘记把用户放在命令前面。
即
*/5 * * * * /bin/bash <filename>
代替
*/5 * * * * root /bin/bash <filename>
它给出了同样的错误，去图。
我们使用sssd进行远程authentication。 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
问题：由于getpwnam（）返回EPIPE（即断开的pipe道），sssd_be以SIGKILL终止，可能会导致crond以静默方式跳过cron作业条目。
上面链接的build议解决scheme是/etc/sssd/sssd.conf添加到/etc/sssd/sssd.conf ：
client_idle_timeout = 75
上面的改变已经解决了我们的问题，克朗不再跳过工作。