Задания крона, не работающие больше

Задания крона работали в течение многих месяцев в прошлом, но недавно у меня была высокая загрузка сервера, и теперь задания крона не выполняют мои php файлы (те же, которые работали прежде). То, когда я проверяю журнал крона, я вижу это, которому я верю, имеет некоторое отношение к проблеме:

(CRON) EXEC FAILED (/usr/sbin/sendmail): Resource temporarily unavailable

Что я должен сделать для решения этой проблемы? Я выполняю CentOS 7.

Править: Я отметил это, как отвечено, поскольку я думал, что зависание процесса вызывало эту проблему. Сегодня, я проснулся, и та же проблема произошла. Интересно, что могло вызывать это.

В журнале крона я вижу:

Oct 11 05:01:01 run-parts(/etc/cron.hourly)[25431]: starting 0anacron
Oct 11 05:01:01 run-parts(/etc/cron.hourly)[25444]: finished 0anacron
Oct 11 05:01:01 run-parts(/etc/cron.hourly)[25431]: starting 0yum-hourly.cron
Oct 11 05:01:01 run-parts(/etc/cron.hourly)[25450]: finished 0yum-hourly.cron
Oct 11 05:01:01 CROND[25434]: (CRON) EXEC FAILED (/usr/sbin/sendmail): Resource temporarily unavailable
Oct 11 05:01:01 CROND[25429]: (apache) MAIL (mailed 71 bytes of output but got status 0x0001

ОБНОВЛЕНИЕ:

Я заметил две вещи, которые смотрят прочь в моем почтовом журнале.

Oct  8 14:01:39 postfix/local[12886]: 5180C2D098A5: to=<N@mail.domain.com>, orig_to=<N>, relay=local, delay=1.1, delays=0.07/0.01/0/1, dsn=5.1.1, status=bounced (unknown user: "n")
Oct  9 04:19:10 postfix/local[12452]: C8F762D012D6: to=<root@mail.domain.com>, orig_to=<apache>, relay=local, delay=0.22, delays=0.13/0.02/0/0.07, dsn=5.2.0, status=bounced (cannot update mailbox /var/mail/root for user root. cannot open file: Is a directory)
2
задан 11 October 2015 в 22:02
1 ответ

(CRON) EXEC FAILED (/ usr / sbin / sendmail): ресурс временно недоступен

Это не проблема cron. из exec (3):

  Функции execl (), execle (), execlp (), execvp () и execvP () могут завершиться ошибкой
  и установите errno для любой из ошибок, указанных для библиотечных функций
  execve (2) и malloc (3).
 

Из execve (2):

  [ENOMEM] Новому процессу требуется больше виртуальной памяти, чем
  разрешено наложенным максимумом (getrlimit (2)).
 

Из malloc (3):

  ЭНОМЕМ
  Ошибка выделения памяти.
 

В большинстве систем UNIX любой вышедший из-под контроля процесс может потреблять достаточно ресурсов, чтобы вызвать сбой нормального выделения виртуальной памяти неуправляемыми процессами.

Это не проблема cron, это проблема системных ресурсов, использования или настройки .

5
ответ дан 3 December 2019 в 09:34

Теги

Похожие вопросы