Eu notei um problema com os logs do postfix, que as informações sobre alguns status de entrega de e-mails estão ausentes. O problema afeta cerca de 1% dos e-mails.
Log "saudável":
<server># grep 8EB992EFBB44 postfix_log/mail04.log
Jun 5 03:09:29 mail04 postfix/smtpd[8537]: 8EB992EFBB44: client=xxx.xxx.xxx[xxx.xxx.xxx.xxx]
Jun 5 03:09:29 mail04 postfix/cleanup[34349]: 8EB992EFBB44: message-id=<[email protected]>
Jun 5 03:12:02 mail04 postfix/qmgr[76377]: 8EB992EFBB44: from=<[email protected]>, size=48845, nrcpt=1 (queue active)
Jun 5 03:15:12 mail04 postfix/smtp[35058]: 8EB992EFBB44: to=<[email protected]>, relay=mx.baz.com[xxx.xxx.xxx.xxx]:25, conn_use=70, delay=343, delays=153/190/0/0.24, dsn=2.0.0, status=sent (250 ok)
Jun 5 03:15:12 mail04 postfix/qmgr[76377]: 8EB992EFBB44: removed
Log "quebrado":
<server># grep F3C362EF37CA postfix_log/mail04.log
Jun 5 04:03:27 mail04 postfix/smtpd[39666]: F3C362EF37CA: client=xxx.xxx.xxx[xxx.xxx.xxx.xxx]
Jun 5 04:03:27 mail04 postfix/cleanup[41287]: F3C362EF37CA: message-id=<[email protected]>
Jun 5 04:03:28 mail04 postfix/qmgr[76377]: F3C362EF37CA: from=<[email protected]>, size=48892, nrcpt=1 (queue active)
** here should be a log line from postfix/smtp but there is none **
Jun 5 04:03:29 mail04 postfix/qmgr[76377]: F3C362EF37CA: removed
Informações básicas:
system: FreeBSD xxx.xxx.xxx 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64
O postfix é instalado dentro da cadeia. Os logs estão na mesma máquina, o diretório log é montado através de nullfs. O site tem picos de carga pesada, fazendo com que os discos (locais) sejam executados a 100%.
Atualizar
O log é rotacionado diariamente, o tamanho atual é de ~ 500MB.
Eu fiz um teste ao enfileirar 99000 mensagens para o mesmo destino (para descartar problemas com dns / network / mx). 5715 mensagens não têm nenhum registro DSN. O tempo da fila de mensagens com falha é distribuído uniformemente ao longo do tempo, não vejo nenhum problema com limite de tempo.
Alguns e-mails não entregues:
envelopeid | processed_time
--------------+----------------------------
8D7652EF3BAE | 2012-06-06 13:19:11.072715
DD53A2EF3C5C | 2012-06-06 13:33:24.374783
8C52F2EF4E3F | 2012-06-06 13:39:15.810616
BBC572EF525C | 2012-06-06 13:44:22.762812
E95822EF54D1 | 2012-06-06 13:52:01.134533
839DD2EF4FBB | 2012-06-06 14:13:48.511236
017EE2EF6234 | 2012-06-06 15:04:48.618963
Essas são algumas escolhas, tais registros de e-mails não entregues ocorrem quase a cada segundo.
<server># egrep '(8D7652EF3BAE|BBC572EF525C|017EE2EF6234)' mail04.log
Jun 6 13:19:10 mail04 postfix/smtpd[20350]: 8D7652EF3BAE: client=xxx.xxx.xxx[xxx.xxx.xxx.xxx]
Jun 6 13:19:10 mail04 postfix/cleanup[21024]: 8D7652EF3BAE: message-id=<[email protected]>
Jun 6 13:19:10 mail04 postfix/qmgr[7939]: 8D7652EF3BAE: from=<[email protected]>, size=63718, nrcpt=1 (queue active)
Jun 6 13:19:11 mail04 postfix/qmgr[7939]: 8D7652EF3BAE: removed
Jun 6 13:44:22 mail04 postfix/smtpd[20346]: BBC572EF525C: client=xxx.xxx.xxx[xxx.xxx.xxx.xxx]
Jun 6 13:44:22 mail04 postfix/cleanup[24811]: BBC572EF525C: message-id=<[email protected]>
Jun 6 13:44:22 mail04 postfix/qmgr[7939]: BBC572EF525C: from=<[email protected]>, size=63758, nrcpt=1 (queue active)
Jun 6 15:04:49 mail04 postfix/smtpd[20344]: 017EE2EF6234: client=xxx.xxx.xxx[xxx.xxx.xxx.xxx]
Jun 6 15:04:49 mail04 postfix/cleanup[35585]: 017EE2EF6234: message-id=<[email protected]>
Jun 6 15:04:49 mail04 postfix/qmgr[7939]: 017EE2EF6234: from=<[email protected]>, size=63706, nrcpt=1 (queue active)
<server>#
<server># find /var/spool/postfix/active/ -type f -print | wc -l
1
<server>#
IMPORTANTE: Como você pode ver acima, alguns dos e-mails não têm o evento removed .
Qual versão do postfix é essa?
Já tentou sintonizar o syslog?
Se o disco estiver em sua capacidade de E / S ou próximo a ela, os syslogs poderão demorar mais do que o esperado.
Além disso, o que é "mail04.log"? Quão grande é isso ? Tem certeza de que a totalidade dessa mensagem foi registrada nesse arquivo?
Envie os logs para fora do local usando o syslog remoto UDP ou (melhor) TCP e verifique se a mensagem está faltando em todos os registros.
Se algum processo do Postfix estiver configurado em $config_directory/master.cf para ser executado no chroot jail, você precisará configurar o syslogd para escutar $queue_directory/dev/log além do padrão /dev/log socket (para que os processos chrooted tenham acesso a /dev/log dentro do chroot). Se você não fizer isso, inicialmente as coisas parecem funcionar, mas o log das quebras de processos chrooted quando o syslogd é reiniciado por algum motivo (o que pode acontecer durante a rotação do log).