O que faz com que o cron envie mensagens continuamente e como posso desativá-lo?

Question

Eu tenho um problema no sistema CentOS 6.3 onde o processo crond tenta enviar e-mails sem sucesso várias vezes (pelo menos eu acho que isso é o que está fazendo) até que o SO eventualmente gere um erro "muitos arquivos abertos". Este computador não está conectado a uma rede.

Sintomas

Após a execução durante a noite, o sistema produz um erro "too may files open" quando um usuário tenta efetuar login.
Se eu examinar a lista de processos depois que ela estiver em execução por algumas horas, vejo esse trio de processos listado várias vezes (o número ou as repetições continuam crescendo à medida que o tempo passa):

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

Tentativas de correção

• Desativei o processo de postfix, que parece estar relacionado aos recursos de envio de e-mail

• Eu modifiquei /etc/crontab e /etc/anacrontab e mudei a linha:

  MAILTO=root
  

  para

  MAILTO=""
  

Nenhuma dessas tentativas de tentativa resolveu o problema. Parece que, na verdade, é o processo postdrop pendente. Se eu matar, os outros dois processos também morrem. Salvo uma solução mais elegante, meu próximo plano de ataque é substituir postdrop por um script bash que não faz nada e sai para evitar que esses processos se acumulem. Qualquer conselho é apreciado!

    

Answer 1

Eu estou supondo que a entrada do cron ofensivo não está em /etc/crontab . MAILTO="" deve funcionar, mas deve estar no mesmo arquivo que a entrada do cron ( /etc/cron.d/0hourly , etc).

Além disso, estou surpreso que isso seja um problema, acho que, por padrão, se você não especificar um endereço de e-mail para root ( /etc/aliases ), o e-mail deve ser entregue localmente.

Alternadamente / adicionalmente, modifique cada entrada do cron para redirecionar a saída para /dev/null :

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

    

Answer 2

O problema que causa os numerosos processos de sendmail e post-up não é que eles sejam iniciados pelo cron, o que é um comportamento normal. O problema é que eles não terminam quase que imediatamente, como de costume, mas continuam sendo executados, ou melhor, travados, resultando em uma lista de processos muito longa:

/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

Como o manual explica: o comando postdrop(1) cria um arquivo no diretório maildrop e copia sua entrada padrão para o arquivo.

O motivo pelo qual o sendmail e os processos de pós-lançamento associados estavam suspensos em nosso ambiente foi porque o sistema de arquivos com o diretório maildrop /var/spool/postfix se tornou somente leitura. Como todo o /var/ era somente de leitura, nenhum erro foi registrado nos registros.

Verifique /proc/mounts para um sistema de arquivos somente leitura e tente resolver com mount -o remount,rw /var .