Cannot restart exim

[hillbilly]

I've got this message in my mail queue (along with many other stuck emails) on Europa every few minutes...

exim failed @ Mon Jul 23 15:05:29 2007. A restart was attempted automagicly.

And when I try to restart manually using cPanel, I get...

ul 23 15:17:22 server1 exim: clamd shutdown succeeded
Jul 23 15:17:22 server1 exim: exim shutdown succeeded
Jul 23 15:17:22 server1 exim: antirelayd shutdown succeeded
Jul 23 15:17:22 server1 exim: spamd shutdown succeeded
Jul 23 15:17:22 server1 exim: clamd startup succeeded
Jul 23 15:17:22 server1 exim: exim startup succeeded
Jul 23 15:17:23 server1 exim: antirelayd startup succeeded
Jul 23 15:17:25 server1 exim: spamd startup succeeded
exim has failed, please contact the sysadmin.

I've been back and forth with support and they've raised my dgramrcvbuf resource limit a couple of times - I've had no QoS alerts in VZPP since Sunday night. Support restarted exim each time they raised the resource ceiling and I was able to deliver a few messages in the queue before exim shut down again.

After sending some test emails, it seemed that the messages getting stuck were to accounts with forwarding enabled, so I have disabled forwarding to non-local servers for all my clients. All my domains' default addresses are set to :fail:.

And I'm still seeing "exim failed" messages every few minutes. This seems to have started about the same time they ran an emergency fsck on Europa on 7/20, but I have no idea whether or not that is relevant to my problem.

Any ideas?

[hillbilly]

Looks like I jumped the gun with this thread. Support has solved my problem...

Exim mail trapper was causing problems in mail deleivery. I have corrected this problem and forcefully delivered all the emails in queue.

Thanks be to Edward and JPC support!

[Vin DSL]

Edward rocks!

[thisisit3]

In the past, i had problems with huge mail queues. Some of my clients send several thousand emails per week and some of them are "spamish". I've hunted those down and limited their ability to send.

Unfortunately, the problem isn't the large volume of messages but how badly exim is set to manage the mail queue.

After long hours of testing, reading documents and other weird voodoo stuff, i came up with the following:

Settings for /etc/exim.conf, i changed the defaults to:

ignore_bounce_errors_after = 12h
timeout_frozen_after = 1d
auto_thaw = 2d

Cron command

0 0 * * * /usr/sbin/exiqgrep -i -o 259200 | xargs /usr/sbin/exim -Mrm >/dev/null

The above is rather strict and thats how i like it. It basically does the following:

1) ignore bounce errors after 12 hours, these are dead emails are there is no point re-sending to them.

2) Re-run queued emails after one day.

3) Force un-freeze all emails no matter what after two days

4) Just abort all undelivered emails that reach 4 days in the queue, they are dead meat.

That will make sure that your queue will never grow and your server will never consume too much memory or cpu from bad emails.

[lamnk]

I think you should open a server management service thisisit

[hillbilly]

Thanks very much, Thisisit. I must say, your posts have been a tremendous help to this noob. Question:

Does your exim config keep the greylisters happy? It seems that more and more email providers are using greylisting these days, and I'm not quite sure what the optimum send/retry policies are for maximizing delivery to those guys.

Thanks again for all your help!

[thisisit3]

I think you should open a server management service thisisit

heh i wouldn't go that far

the way i see it is simple: since i've already searched and found a solution to a problem, why not share it, so others don't have to re-invent the wheel again.

something like... "open source knowledge"

[thisisit3]

Does your exim config keep the greylisters happy? It seems that more and more email providers are using greylisting these days, and I'm not quite sure what the optimum send/retry policies are for maximizing delivery to those guys.

It keeps them happy because most greylisting delays an email for a few minutes to a few hours. If your server is having delivery problems with greylisting that lasts for more than that (for example 1 day delays to yahoo.com) then your server is on a spam list.