задание cron иногда не запускается

у меня есть 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 Обороты.

Есть более новая версия cronie (1.4.12), однако его нельзя обновить, поскольку мы уже используем последнюю доступную версию для Centos 6.6

Я просмотрел список изменений для всех cronie версии после моей (1.4.4) и, похоже, не решает эту конкретную проблему. Также проверил все сообщения фиксации.

Исходный 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.

Это первый ответ, который приходит с поисковым текстом cron error getpwname failed поэтому я подумал, что опубликую причину своей проблемы:

Я использовал / etc / crontab, но забыл указать пользователя перед командой.

т.е.

*/5   *  *  *  * /bin/bash <filename>

Вместо того

 */5   *  *  *  * root /bin/bash <filename>

Он дал ту же ошибку, поймите.

мы используем 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 <tmraz@redhat.com> - 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 завершается с помощью SIGKILL из-за того, что getpwnam () возвращает EPIPE (т.е. сломанный канал), может заставить crond молча пропускать записи задания cron.

Предлагаемое решение по ссылке выше - добавить строку ниже в /etc/sssd/sssd.conf:

client_idle_timeout = 75

Приведенное выше изменение устранило проблему, и cron больше не пропускает задания.