Call us Toll-Free:
1-800-218-1525
Live ChatEmail us

 Sponsors

Sendmail Troubleshooting

Dawn Rossi, 04-16-2007
Recently, on a server running sendmail, dovecot (for IMAP and POP3), and spamassassin, I kept getting complaints from users about their outgoing messages getting returned or stuck, and not being able to log in to get email. Finally, I got a bounce message myself so I decided to believe them:

----- Transcript of session follows -----
451 4.4.1 reply: read error from local
... Deferred: Operation timed out with local
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old

I took a look at the files in /var/spool/mqueue to see what was going on with the queue. There were a lot waiting, but this is a pretty active server. A good way to see how many emails are waiting to go out is to simply run "mailq|grep @|wc -l". I saw a lot of messages that included the error "451 4.4.1 reply: read error from local". I tried running the mail queue manually to see if I could see any extra info:

sendmail -v -q

When I ran this, it connected to the server (localhost), said hello and started transmitting data. Then it sat there for a minute and didn't do anything. Contorol-C wouldn't exit the running process, so I had to Control-Z and kill -9 it. Each time I ran the queue manually I would see 3 new procmail processes pop up. I ran an strace on most of them, and they were all inactive.

This changed my attention to procmail. Running "ps ax|grep procmail" showed that there were several stale processes running. This proved that it was happening with several messages. Since this mail server is handling a lot of domains/accounts, and the renegade procmail processes were not singled to one domain/account, that told me it was a global problem effecting everyone.

I opened up the default procmailrc file (/usr/local/etc/procmailrc on FreeBSD) and the I noticed all of the messages were being filtered through spamassassin:

:0fw
|/usr/local/bin/spamc -U /var/run/spamd.sock

:0:
* ^X-Spam-Status: Yes
/var/mail/spam

This is normally fine, but with this configuration there are no limits to the size message it processes. I changed it to skip messages that are over 256k:

:0fw
* < 256000
|/usr/local/bin/spamc -U /var/run/spamd.sock

:0:
* ^X-Spam-Status: Yes
/var/mail/spam

I ran the mail queue manually again, and viola. It skipped past that message and left no resident procmail messages. Maybe it was a big attachment that spamassassin kept choking on, I didn't look at the size of the queue file before it was gone.

Things seem to be back to normal, and I don't see any "read error from local" messages sitting in the queue. I guess we'll have to wait to see what happens, but for now all is good.

Dawn Rossi, 04-24-2007
Update on this:

If you're using Dovecot + Procmail + Sendmail, you're likely to run into mailbox locking race conditions.

The solution is to update Dovecot's conf file (/usr/local/etc/dovecot.conf on our machine) with:

mbox_read_locks = fcntl
mbox_write_locks = fcntl

This prevents the lock race between Dovecot and Procmail.

Might also be a good idea to enable a timeout on locks by turning on:

mbox_lock_timeout = 60
Enjoyed this post?

Subscribe Now to receive new posts via Email as soon as they come out.

 Comments
Post your comments












Note: No link spamming! If your message contains link/s, it will NOT be published on the site before manually approved by one of our moderators.



About Us  |  Contact us  |  Privacy Policy  |  Terms & Conditions