Cron иногда не работает

8

У меня есть 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версий после mine ( 1.4.4) и не нашел решения этой конкретной проблемы. Также проверил все сообщения коммита .

linux centos cron centos6 Луис
источник
1
Хорошее устранение неисправностей. Почему бы не попробовать добавить последнюю строку noop ( echo >/dev/nullнапример)?
Бельмин Фернандес
Есть ли какая-то из ваших команд сгенерировать ошибку. это может остановить сценарий. У меня был похожий опыт работы со скриптами init.d.
Hardik
Как быстро выполняется каждое из заданий? Если задание, которое вы запускаете каждую минуту, выполняется в течение двух минут каждый раз, тогда это может быть проблемой. Но если это завершится через две секунды, то это, вероятно, не проблема.
Касперд
1
Задание, которое выполняется каждую минуту (OTHERJOB), завершается за несколько секунд. Но это не проблема. Я только добавил OTHERJOB в журналы выше, чтобы показать, что crond работает и OTHERJOB был обработан правильно, в то время как pg_backup.sh просто не запускался.
Луис
Проверьте /var/log/audit/audit.log.
Майкл Хэмптон

Ответы:

6

Оригинальный 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.
Брайан
источник
2

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

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

т.е.

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

Вместо 

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

Это дало ту же ошибку, иди разберись.

Аарон Р.
источник
1

мы используем sssdдля удаленной аутентификации. crondдолжен проверять наличие доступных пользователей перед выполнением заданий, и он делает это каждые 60 секунд. sssdпо умолчанию client_idle_timeoutэто 60 секунд. поэтому у нас было состояние гонки между sssdиcrond

Мы только добрались до сути этой проблемы, потому что в версии 1.4.4-14crond стал немного более подробным о некоторых ошибках.

* 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 больше не пропускает задания.

Луис
источник