Augmenter le timeout d'attente pour Postfix / Cyrus "Limite de time de command dépassée"?

J'ai un ancien OS X Server 10.4.x exécutant Postfix 2.1.5 qui est configuré pour utiliser cyrus comme transport de boîte aux lettres.

Voici 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_ressortingctions = 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_ressortingctions = 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 time en time, il a besoin d'un kickstart (en rlocation de l'set du server bientôt), mais lorsqu'il y a problème, des avis non livrables sont envoyés avec:

 Final-Recipient: rfc822; user@host.com Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; Command time limit exceeded: "/usr/bin/cyrus/bin/deliver" 

Dans master.cf, cette command est répertoriée comme suit:

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

Nous détectons généralement le problème et redémarrons les services qui le résolvent, mais nous avons pris une heure ou deux pour le détecter aujourd'hui, et de nombreux expéditeurs ont reçu cet avis, ce qui n'est pas idéal.

Existe-t-il un moyen d'augmenter le timeout de command?

Cette réponse est presque hors sujet, mais pourrait vous aider à réparer votre Cyrus si c'est assez ancien (v2.1.x ou plus ancien) ou utilise BerendleyDB backend au lieu de Skiplist qui a été introduit plus tard.

Le problème avec l'ancien IMC de Cyrus était que, par défaut, BerkeleyDB utilisait les parameters par défaut de BDB. Les défauts sont incroyablement petits; 256 kilooctets de cache en memory et ainsi de suite. Cela conduit très rapidement à des blocages de BerkeleyDB s'il y a beaucoup de courrier à livrer à Cyrus.

Pour voir votre statut actuel de Cyrus BerkeleyDB:

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

(La command db_stat pourrait très bien être sous forme de db_XYstat , où XY signifie la version BerkeleyDB)

Si cela vous montre des valeurs très faibles pour les tailles de cache, continuez et augmentez-les à volonté.

D'abord, arrêtez Cyrus et faites une copy de sauvegarde de ce directory de données, juste pour être sûr.

Ensuite, dans le directory de données, créez un file appelé'DB_CONFIG` et faites qu'il contienne au less cette ligne

 set_cachesize 0 16777216 0 

Cela augmenterait la taille du cache en memory jusqu'à 16 mégaoctets, ce qui est suffisant pour des installations assez importantes.

Assurez-vous que le file DB_CONFIG appartient au même count d'user que Cyrus.

Pour activer les changements de cache, exécutez une command effrayante nommée db_recover (peut également être sous forme de dbXY_recover . Assurez-vous d'exécuter la command en tant qu'user Cyrus et non par exemple root.

Redémarrez Cyrus, voir si cela fonctionne, exécutez db_stat -m *.db nouveau pour voir si les valeurs ont changé.