郵件無緣無故卡在進出口隊列中？

在我的伺服器上，郵件有時會因為顯然沒有特定原因而延遲。

systemd-cron在此範例中，關於失敗的 cron 作業生成了兩封郵件：

mailq輸出（編輯的域）：

3m  1.9K 1i6W6d-0003UT-Ut <server@example.com>
         www-data@server

3m  1.8K 1i6W6e-0003Uh-1y <server@example.com>
         root@server

幾分鐘後或當我發出exim -qf郵件時，郵件最終被發送並傳遞，沒有任何問題。

/var/log/exim4/mainlog（已編輯的域/IP）：

2019-09-07 10:30:04 1i6W6d-0003UT-Ut <= server@example.com U=nobody P=local S=1914
2019-09-07 10:30:04 1i6W6e-0003Uh-1y <= server@example.com U=nobody P=local S=1875
2019-09-07 10:34:13 Start queue run: pid=13447 -qf
2019-09-07 10:34:14 1i6W6d-0003UT-Ut => me@example.com <www-data@server> R=smarthost T=remote_smtp_smarthost H=smtp.example.com [1.2.3.4] X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes DN="…" A=plain C="250 2.0.0 Ok: queued as 268D26139FAA"
2019-09-07 10:34:14 1i6W6d-0003UT-Ut Completed
2019-09-07 10:34:14 1i6W6e-0003Uh-1y => me@example.com <root@server> R=smarthost T=remote_smtp_smarthost H=smtp.example.com [1.2.3.4] X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes DN="…" A=plain C="250 2.0.0 Ok: queued as BA7EE6139FAC"
2019-09-07 10:34:14 1i6W6e-0003Uh-1y Completed
2019-09-07 10:34:14 End queue run: pid=13447 -qf

當我從命令行發送電子郵件時echo 'Test' | mail -s test root，郵件會立即發送，沒有開始/結束隊列執行的日誌條目：

2019-09-07 10:35:21 1i6WBk-0003V9-VR <= server@example.com U=root P=local S=397
2019-09-07 10:35:21 1i6WBk-0003V9-VR => me@example.com <root@server> R=smarthost T=remote_smtp_smarthost H=smtp.example.com [1.2.3.4] X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes DN="…" A=plain C="250 2.0.0 Ok: queued as 723116139F77"
2019-09-07 10:35:21 1i6WBk-0003V9-VR Completed

你知道延遲的原因嗎？我怎樣才能讓 exim 立即處理所有郵件？

我的配置：

• 最新的 Debian Buster
• exim 版本 4.92-8+deb10u2
• 兩者root和www-data（除其他外）都有 me@example.com 的別名（外部）
• 標準 Debian exim 配置（使用update-exim4.conf）

/etc/exim4/update-exim4.conf.conf:

dc_eximconfig_configtype='smarthost'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost='server'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='smtp.example.com::587'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'

顯然，這種情況是由systemd-devel 郵件列表中描述的 exim 和 systemd 的組合引起的。

TL;DR：從命令行發送郵件 exim 派生了一個程序來立即傳遞郵件。然而，由於父程序存在，這個 cron 作業的 systemd 單元終止，並且 systemd 殺死控制組中的所有剩餘程序，包括之前負責郵件傳遞的分叉程序。

為了防止這種情況，我找到了兩種解決方案（除了修復 exim 本身）：

• 使用 SMTP 客戶端通過 TCP 將郵件發送到本地 exim 守護程序，例如swaks(1).
• 延遲 systemd 單元的結束，例如，在呼叫exim -qf之後呼叫 (queue flush) mail。

兩種解決方案都不是最優的。第一個需要額外的軟體並打開本地 tcp 連接，而第二個需要 root 權限。目前，我會堅持使用swaks.

引用自：https://serverfault.com/questions/982318