Home / server / Questions / 672623
In Process
jaydisc
Asked: 2015-03-03 21:51:43 +0800 CST

Increase timeout for Postfix/Cyrus "Command time limit exceeded"?

  • 772

I have an old OS X Server 10.4.x running Postfix 2.1.5 which is configured to use cyrus as mailbox transport.

Here's 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

Every now and then, it needs a kickstart (replacing the entire server soon), but when it has issue, undeliverable notices are sent out with:

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

In master.cf, that command is listed as:

# 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}

We usually detect the problem and restart the services which resolves it, but we took an hour or two to detect it today, and many senders got this notice, which is less than ideal.

Is there any way to increase the command time limit?

postfix

1 Answers

  1. This answer is almost off-topic, but might help you actually fix your Cyrus if it's ancient enough (v2.1.x or older) or is using BerkeleyDB backend instead of Skiplist which was introduced later.

    The problem with older Cyrus IMAPd was that by default its BerkeleyDB was using BDB's default settings. The defaults are insanely small; 256 kilobytes of in-memory cache and so on. That very quickly leads to BerkeleyDB deadlocks if there's lots of mail to deliver to Cyrus.

    To see your current Cyrus BerkeleyDB status:

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

    (The db_statcommand might very well be in form of db_XYstat, where XY stands for BerkeleyDB version)

    If that shows you very low values for cache sizes, go on and increase them at will.

    First, stop Cyrus and make a backup copy of that data directory, just to be sure.

    Then, in the data directory, create a file called ´DB_CONFIG` and make it contain at least this line

    set_cachesize    0   16777216  0

    That would increase the in-memory cache size to 16 megabytes, which is sufficient for quite large installations, too.

    Make sure that DB_CONFIG file is owned by the same user account than Cyrus.

    To actually activate the cache changes, run a scarily named command db_recover (might also be in form of dbXY_recover. Make sure you run the command as the Cyrus user and not for example root.

    Restart Cyrus, see if it works, run db_stat -m *.db again to see if the values changed.

    • 5