This morning, mails stuck in the deferred queue, monit not reporting anything, all green, no warnings or failed restarts. Mails stuck because of unresponsiveness of amavis on port 10026. Solved by manually restarting amavis followed by a postqueue -f Code: Sep 13 06:35:25 alfred postfix/smtp: 263A5521D1C: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10026, delay=300, delays=0.01/0/300/0, dsn=4.4.2, status=deferred (conversation with 127.0.0.1[127.0.0.1] timed out while receiving the initial server greeting) monit amavis config looking like this: Code: check process amavisd with pidfile /var/run/amavis/amavisd.pid group mail start program = "/etc/init.d/amavis start" stop program = "/etc/init.d/amavis stop" if failed port 10024 protocol smtp then exec /root/restart_mailserver.sh if failed port 10026 protocol smtp then exec /root/restart_mailserver.sh if 5 restarts within 25 cycles then timeout help please?
this morning I found my deferred queue had accumulated 22 emails. Code: qshape deferred T 5 10 20 40 80 160 320 640 1280 1280+ TOTAL 22 0 0 0 2 7 2 6 5 0 0 domain1 15 0 0 0 2 6 1 5 1 0 0 domain2 2 0 0 0 0 0 0 0 2 0 0 domain3 2 0 0 0 0 0 0 1 1 0 0 domain4 1 0 0 0 0 0 0 0 1 0 0 domain5 1 0 0 0 0 0 1 0 0 0 0 domain6 1 0 0 0 0 1 0 0 0 0 0 amavis was running: Code: /etc/init.d/amavis status amavisd is running. sample from log files: Code: Sep 15 07:28:34 alfred postfix/error: 1AC67521F19: to=<root@localhost>, relay=none, delay=0.06, delays=0.06/0/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10026: Connection refused) Any ideas please? Monit was simply idling along, showing all green. Code: monit status Process 'amavisd' status Running monitoring status Monitored pid 12477 parent pid 1 uid 108 effective uid 108 gid 114 uptime children 2 memory kilobytes 130.4 MB memory kilobytes total 384.1 MB memory percent 0.7% memory percent total 2.3% cpu percent 0.0% cpu percent total 0.0% port response time 0.000s to localhost:10026 [SMTP via TCP] port response time 0.000s to localhost:10024 [SMTP via TCP] data collected Thu, 15 Sep 2016 07:33:34
OK; solved by losing the client. And yet the underlying problem is still here. amavis is running. postfix is running. and yet mails don't get past port 10026 :-( Code: netstat -tap | grep 100 tcp 0 0 localhost.localdo:10024 *:* LISTEN 3329/amavisd-new (m tcp 0 0 localhost.localdo:10025 *:* LISTEN 5647/master tcp 0 0 localhost.localdo:10026 *:* LISTEN 3329/amavisd-new (m tcp 0 0 localhost.localdo:10027 *:* LISTEN 5647/master tcp 0 0 *:sunrpc *:* LISTEN 1005/rpcbind tcp 0 0 localhost.localdo:10026 localhost.localdo:44244 TIME_WAIT - tcp6 0 0 localhost:10024 [::]:* LISTEN 3329/amavisd-new (m tcp6 0 0 localhost:10026 [::]:* LISTEN 3329/amavisd-new (m tcp6 0 0 [::]:sunrpc [::]:* LISTEN 1005/rpcbind found this link and according to it I made the changes below: https://www.ijs.si/software/amavisd/amavisd-new-docs.html#max_requests Code: amavis unix - - - - 2 lmtp -o smtp_data_done_timeout=2400 -o smtp_send_xforward_command=yes -o max_use=20 changed SMTP to LMTP and added max_use=20 while the number 20 corresponds to the amavis setting $max_requests = 20; this worked for 2 days until this morning.
Looks like I finally fixed this albeit too late for myself. The /etc/cron.daily/spamassassin script was throwing an error related to the "reload" part so I comment this complete section seeing that SA is being called by amavis and not running as a daemon Code: # Tell a running spamd to reload its configs and rules. #reload() { # Reload #if which invoke-rc.d >/dev/null 2>&1; then # invoke-rc.d spamassassin reload > /dev/null #else # /etc/init.d/spamassassin reload > /dev/null #fi #if [ -d /etc/spamassassin/sa-update-hooks.d ]; then # run-parts --lsbsysinit /etc/spamassassin/sa-update-hooks.d #fi #} no more cron errors and no more amavis errors.
