Eu sou um novato em exim - e herdei um sistema executando o exim que está se comportando mal.
Minha instância parou de enviar e-mails. Ele está aceitando mensagens na fila e está sendo executado com -q1h
- a cada hora, para cada mensagem na fila, ele relata...
defer (-53): retry time not reached for any host
Ele está configurado para usar um host inteligente altamente disponível - portanto, isso não é um problema com o MTA remoto. De fato, executando exim -v
a partir da linha de comando para enviar um e-mail, ele é transmitido imediatamente para o módulo lógico. ou seja, não há problema com o roteamento, autenticação, disponibilidade. O Exim simplesmente não está tentando encaminhar esses e-mails.
Eu vejo muitas e MUITAS pessoas dizendo que a maneira de corrigir isso é redefinir o banco de dados de repetição, excluindo apenas os arquivos de bloqueio ou os lockfles e o banco de dados de repetição. Nenhum dos métodos teve qualquer impacto no meu mailq.
NB isto não é uma nova tentativa após uma falha - o exim nunca tentou passar a mensagem.
A configuração de repetição é conforme o padrão:
begin retry
* * F,2h,15m; G16h,1h,1.5; F,4d,6h
Imagino que -q1h
seja por isso que ele não tenta transmitir a mensagem imediatamente. Mas por que não está pegando mensagens da fila?
Como isso está sendo transferido para um relé inteligente, não preciso fazer backup das mensagens por uma hora. Se eu remover o -q1h das opções, o exim continuará verificando a fila regularmente ou simplesmente o ignorará?
O
-q1h
significa que o daemon processará a fila uma vez a cada hora. Fazê-lo processar a fila é sensato, pois mesmo que você esteja enviando por meio de um host inteligente, mesmo que possa estar offline / inacessível por qualquer motivo, fará com que as mensagens sejam colocadas na fila. Não executar a fila significaria que essas mensagens nunca seriam enviadas.O fato de o exim estar relatando "tempo de repetição não alcançado para nenhum host" significa que o smarthost aparentemente estava inacessível em algum momento. Para evitar o desperdício de recursos tentando acessar repetidamente um host offline, um tempo de repetição é imposto e esse tempo aparentemente ainda não foi atingido. Tenho certeza de que, se você pesquisar mais os logs, verá onde o smarthost estava inacessível.
Você pode forçar uma tentativa de entregar uma mensagem executando
exim -M messageID
(você pode ver os IDs da mensagem comexim -bp
oumailq
se o exim foi vinculado a este nome).Esqueci a regra nº 1:
Quando um sistema Redhat / Centos morde você no %^&*, provavelmente é SELinux / a política de destino