Что заставляет cron постоянно отправлять почту и как ее отключить?

У меня проблема с системой CentOS 6.3, где процесс crond пытается безуспешно отправлять почту снова и снова (по крайней мере, я думаю, что это именно то, что она делает), пока ОС в итоге не породит ошибку «слишком много файлов». Этот компьютер не подключен к сети.

симптомы

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

CROND /usr/sbin/sendmail -FCronDaemon -i -odi -oem -i -t ... /usr/sbin/postdrop -r 

Попытки исправления

  • Я отключил постфиксный процесс, который, похоже, связан с функциями отправки почты
  • Я изменил /etc/crontab и /etc/anacrontab и изменил строку:

     MAILTO=root 

    в

     MAILTO="" 

Ни одна из этих попыток не устранила проблему. Похоже, что на самом деле это процесс postdrop который висит. Если я его убью, другие два процесса также погибнут. Не имея более элегантного решения, мой следующий план атаки заключается в том, чтобы заменить postdrop bash, который ничего не делает и выходит, чтобы предотвратить накопление этих процессов. Любые советы приветствуются!

Я предполагаю, что нарушение записи cron не находится в /etc/crontab . MAILTO="" должно работать, но оно должно быть в том же файле, что и запись cron ( /etc/cron.d/0hourly и т. Д.).

Кроме того, я удивлен, что это проблема, я думаю, что по умолчанию, если вы не укажете адрес электронной почты для root ( /etc/aliases ), почта должна быть доставлена ​​локально.

В качестве альтернативы / дополнительно измените каждую запись cron для перенаправления вывода на /dev/null :

 * * * * * /some/script.sh >/dev/null 2>&1 

Проблема, вызывающая многочисленные процессы sendmail и postdrop, заключается не в том, что они начинаются cron, это нормальное поведение. Проблема в том, что они не прекращаются почти сразу, как обычно, но продолжают работать или, скорее, зависают, что приводит к чрезвычайно длинному списку процессов:

 /usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f root /usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f root /usr/sbin/postdrop -r /usr/sbin/postdrop -r /usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f root /usr/sbin/postdrop -r /usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f root /usr/sbin/postdrop -r 

Как объясняется в руководстве: команда postdrop(1) создает файл в каталоге maildrop и копирует его стандартный ввод в файл.

Причина, по которой процессы sendmail и связанные с ними процессы зависали в нашей среде, состояла в том, что файловая система с каталогом maildrop /var/spool/postfix стала /var/spool/postfix только для чтения. Поскольку весь /var/ был доступен только для чтения, в журналах не записывались ошибки.

Проверьте /proc/mounts для файловой системы только для чтения и попробуйте решить с помощью mount -o remount,rw /var .