☰

Увеличить тайм-аут для Postfix/Cyrus «Превышен лимит времени выполнения команды»?

tag-icon • tag-icon postfix cyrus
Увеличить тайм-аут для Postfix/Cyrus «Превышен лимит времени выполнения команды»?

У меня есть старый OS X Server 10.4.x, на котором работает Postfix 2.1.5, настроенный на использование Cyrus в качестве почтового транспорта.

Вот 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

Время от времени ему требуется быстрый запуск (скорая замена всего сервера), но когда возникают проблемы, отправляются уведомления о невозможности доставки:

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

В master.cf эта команда указана как:

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

Обычно мы обнаруживаем проблему и перезапускаем службы, что решает ее, но сегодня нам потребовалось час или два, чтобы обнаружить ее, и многие отправители получили такое уведомление, что далеко от идеала.

Есть ли способ увеличить лимит времени выполнения команды?

решение1

Этот ответ не совсем по теме, но может помочь вам исправить Cyrus, если он достаточно старый (v2.1.x или старше) или использует бэкэнд BerkeleyDB вместо Skiplist, который был представлен позже.

Проблема со старым Cyrus IMAPd была в том, что по умолчанию его BerkeleyDB использовал настройки BDB по умолчанию. Настройки по умолчанию безумно малы; 256килобайтыкэша в памяти и т. д. Это очень быстро приводит к тупиковым ситуациям BerkeleyDB, если нужно доставить Cyrus много почты.

Чтобы увидеть ваш текущий статус Cyrus BerkeleyDB:

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

( db_statКоманда вполне может быть в форме db_XYstat, где XY обозначает версию BerkeleyDB)

Если вы увидите очень низкие значения размеров кэша, продолжайте и увеличивайте их по своему усмотрению.

Сначала остановите Cyrus и сделайте резервную копию этого каталога данных, просто чтобы быть уверенным.

Затем в каталоге данных создайте файл с именем ´DB_CONFIG` и сделайте так, чтобы он содержал как минимум эту строку

set_cachesize    0   16777216  0

Это увеличило бы размер кэша в памяти до 16 мегабайт, что также достаточно для довольно больших инсталляций.

Убедитесь, что файл DB_CONFIG принадлежит той же учетной записи пользователя, что и Cyrus.

Чтобы фактически активировать изменения кэша, выполните команду со страшным названием db_recover(также может иметь вид dbXY_recover. Убедитесь, что вы запускаете команду как пользователь Cyrus, а не, например, root.

Перезапустите Cyrus, проверьте, работает ли он, запустите db_stat -m *.dbснова, чтобы проверить, изменились ли значения.

Связанный контент