¿Aumentar el tiempo de espera para Postfix/Cyrus "Se excedió el límite de tiempo de comando"?

¿Aumentar el tiempo de espera para Postfix/Cyrus "Se excedió el límite de tiempo de comando"?

Tengo un antiguo OS X Server 10.4.x que ejecuta Postfix 2.1.5 y que está configurado para usar cyrus como transporte de buzones.

Aquí está 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 en cuando, necesita un arranque rápido (reemplazando todo el servidor pronto), pero cuando tiene problemas, se envían avisos de no entregable con:

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

En master.cf, ese comando aparece 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}

Normalmente detectamos el problema y reiniciamos los servicios para resolverlo, pero hoy nos tomó una o dos horas detectarlo y muchos remitentes recibieron este aviso, lo cual no es lo ideal.

¿Hay alguna forma de aumentar el límite de tiempo de comando?

Respuesta1

Esta respuesta está casi fuera de tema, pero podría ayudarlo a reparar su Cyrus si es lo suficientemente antiguo (v2.1.x o anterior) o si usa el backend BerkeleyDB en lugar de Skiplist, que se presentó más adelante.

El problema con el Cyrus IMAPd anterior era que, de forma predeterminada, BerkeleyDB usaba la configuración predeterminada de BDB. Los valores predeterminados son increíblemente pequeños; 256kilobytesde caché en memoria, etc. Eso lleva muy rápidamente a puntos muertos en BerkeleyDB si hay mucho correo para entregar a Cyrus.

Para ver su estado actual de Cyrus BerkeleyDB:

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

(El db_statcomando podría muy bien tener el formato db_XYstat, donde XY significa versión BerkeleyDB)

Si eso muestra valores muy bajos para el tamaño de la caché, continúe y auméntelos a voluntad.

Primero, detenga Cyrus y haga una copia de seguridad de ese directorio de datos, sólo para estar seguro.

Luego, en el directorio de datos, cree un archivo llamado ´DB_CONFIG` y haga que contenga al menos esta línea

set_cachesize    0   16777216  0

Eso aumentaría el tamaño de la caché en memoria a 16 megabytes, lo que también es suficiente para instalaciones bastante grandes.

Asegúrese de que el archivo DB_CONFIG pertenezca a la misma cuenta de usuario que Cyrus.

Para activar realmente los cambios de caché, ejecute un comando con un nombre aterrador db_recover(también puede tener el formato dbXY_recover. Asegúrese de ejecutar el comando como usuario de Cyrus y no, por ejemplo, como root).

Reinicie Cyrus, vea si funciona, ejecútelo db_stat -m *.dbnuevamente para ver si los valores cambiaron.

información relacionada