Aumenta o tempo limite do Postfix / Cyrus “Limite de tempo de comando excedido”?

Question

Eu tenho um antigo OS X Server 10.4.x executando o Postfix 2.1.5 que é configurado para usar o cyrus como transporte de caixa de correio.

Aqui está o postconf -n:

# postconf -n
alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
enable_server_options = yes
html_directory = no
inet_interfaces = all
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
luser_relay = 
mail_owner = postfix
mailbox_size_limit = 0
mailbox_transport = cyrus
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maps_rbl_domains = 
message_size_limit = 15728640
mydestination = $myhostname,localhost.$mydomain,livingnow.com.au,localhost
mydomain = livingnow.com.au
mydomain_fallback = localhost
myhostname = server.livingnow.com.au
mynetworks = 127.0.0.1/32,192.168.16.0/24
mynetworks_style = host
newaliases_path = /usr/bin/newaliases
owner_request_special = no
queue_directory = /private/var/spool/postfix
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
sample_directory = /usr/share/doc/postfix/examples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_client_restrictions = permit_mynetworks  reject_rbl_client sbl-xbl.spamhaus.org reject_rbl_client bl.spamcop.net permit
smtpd_pw_server_security_options = cram-md5,login,plain
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,permit
smtpd_sasl_auth_enable = yes
smtpd_tls_key_file = 
smtpd_use_pw_server = yes
unknown_local_recipient_reject_code = 550

De vez em quando, ele precisa de um kickstart (substituindo o servidor inteiro em breve), mas quando ele tem problema, avisos não entregues são enviados com:

Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; Command time limit exceeded:
   "/usr/bin/cyrus/bin/deliver"

No master.cf, esse comando é listado como:

# Also specify in main.cf: cyrus_destination_recipient_limit=1
cyrus     unix  -       n       n       -       10      pipe
  user=cyrusimap argv=/usr/bin/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user}

Geralmente, detectamos o problema e reiniciamos os serviços que o resolvem, mas demoramos uma ou duas horas para detectá-lo hoje, e muitos remetentes receberam esse aviso, que é menos que o ideal.

Existe alguma maneira de aumentar o limite de tempo de comando?

    

Answer 1

Esta resposta é quase fora do tópico, mas pode ajudá-lo a consertar seu Cyrus se ele for antigo o suficiente (v2.1.x ou mais antigo) ou estiver usando o backend do BerkeleyDB em vez do Skiplist que foi introduzido posteriormente.

O problema com o antigo Cyrus IMAPd era que, por padrão, o BerkeleyDB estava usando as configurações padrão do BDB. Os padrões são insanamente pequenos; 256 kilobytes de cache na memória e assim por diante. Isso leva rapidamente a deadlocks do BerkeleyDB se houver muitos emails para entregar ao Cyrus.

Para ver seu status atual do Cyrus BerkeleyDB:

cd /path/to/your/cyrus/datadir (the dir with mailboxes.db and so on)
db_stat -m *.db

(O comando db_stat pode muito bem estar no formato db_XYstat , em que XY representa a versão do BerkeleyDB)

Se isso mostrar valores muito baixos para os tamanhos de cache, continue e aumente-os à vontade.

Primeiro, pare o Cyrus e faça uma cópia de segurança desse diretório de dados, só para ter certeza.

Então, no diretório de dados, crie um arquivo chamado 'DB_CONFIG' e faça com que ele contenha pelo menos essa linha

set_cachesize    0   16777216  0

Isso aumentaria o tamanho do cache na memória para 16 megabytes, o que é suficiente para instalações bastante grandes também.

Verifique se o arquivo DB_CONFIG pertence à mesma conta de usuário que o Cyrus.

Para realmente ativar as alterações de cache, execute um comando assustadoramente chamado db_recover (também pode estar no formato dbXY_recover . Certifique-se de executar o comando como o usuário Cyrus e não, por exemplo, raiz.

Reinicie o Cyrus, veja se funciona, execute db_stat -m *.db novamente para ver se os valores mudaram.