Exim delays

[andyf]

We're starting to notice a problem common across most of our machines.

Exim, instead of attempting to deliver a message when it is accepted just pushes it to the queue, and it can take an hour or more before this is actually attempted for delivery. *there is NO initial attempt*.

Some info:
The load on these machines is relatively low, one of them is idle.
It happens on all domains.
The messages are NOT frozen
Manually delivering the messages from WHM works fine.
So far we've only noticed this happening on mail recieved from 'nobody'.
We do not have the 'nobody' restrictions enabled.
It does not happen with all messages.

This is causing much annoyance among customers as so much outgoing mail is being delayed. This only appears to have started to happen since the new tweak features on 'nobody' mail, but these have never been enabled on these machines. We cannot be sure these two things are related, please don't assume they are.

Anyone else experiencing the same or can shed any light on this?

Thanks.

[jamesbond]

yup, I've been having these issues now and then for the past weeks.

Check out this thread :
http://forums.cpanel.net/showthread....&threadid=8658

In my case it helps running /scripts/newexim which will install an older version of exim (which works fine on my server)

Check if that resolves the problem.

If so, then you could run /scripts/upcp to update to the latest exim version again.

Sometimes the problem will come back, sometimes it won't.

What I do each time when mail from php forms is getting queued I just go back to the old version (/scripts/newexim)

[andyf]

Thanks for the info.

So not really a solution, but more of a temporary fix. I still believe this could well be related to the new features of how many messages per hour and the 'nobody' mail settings, all introduced recently.

Nick, is there anything which could have caused this?

[Curt]

I am having this problem on only one server out of 5. Very strange.

[TheCrazyHostGuy]

This might be slightly off the posted topic... but at the same time closely related....


There was a virus scanner add-on for exim on the Cpanel website that we recently installed... since we installed that we have been seeing extremly large e-mail ques... one day as high as about 30,000 plus messages.... needless to say we had a ton of unhappy customers.

We sort-of disabled it.... but we still get large mail ques regularly even when the server is under relitively low load.

Not sure if it is related or not.

Also... does anyone know how we can remove this virus scanner? it is causeing me tons of problems with people who are getting attachments returned!

Thanks,

James

[andyf]

I'm not sure how you can remove the virus scanner, but we don't have it installed on any of the machines, so unfortunately it's not that which is causing our problems.

[andyf]

I've put in a ticket about this and brought it to Nicks attention, so hopefully we'll see some progress of this soon.

Noticed quite a few more threads on this in other parts of the forum, and have directed those to here.

[Slav]

Yes i can say we are having the same problem on both our machiness too. Hope this gets fixed as i got people screaming at me all the time also....

[sexy_guy]

Originally posted by jamesbond
yup, I've been having these issues now and then for the past weeks.

Check out this thread :
http://forums.cpanel.net/showthread....&threadid=8658

In my case it helps running /scripts/newexim which will install an older version of exim (which works fine on my server)

Check if that resolves the problem.

If so, then you could run /scripts/upcp to update to the latest exim version again.

Sometimes the problem will come back, sometimes it won't.

What I do each time when mail from php forms is getting queued I just go back to the old version (/scripts/newexim)

The only problem with that is the next time you run upcp and there is a newer version of exim available your older version will get upgraded to the new version but you can stop that by doing this;

cd /usr/sbin
chattr +i sendmail

That way if you have rolled back to an older version of Exim the newer one will not install over it.

[howard]

check to see weather you got any of the following in your exim.conf

deliver_load_max
deliver_queue_load_max
queue_only_load

e.g. egrep '(deliver_load_max|deliver_queue_load_max|queue_only_load)' /etc/exim.conf
if they try commenting them out then kill -HUP eximpid (as root or restart exim if you prefer)

[fredkk]

I have two servers and I am having the same trouble, when I ran /scripts/newexim it deliveryed the mail right away and then went right back to the same problem. When you run a mail trouble check from the WHM you get mail router error,. I have tried everything that I can think of and still the mail will not go through sometimes for hours and sometimes it never goes through. And it does not bounce either, any suggestions? I am lost at this point

[Silverado]

Originally posted by howard
check to see weather you got any of the following in your exim.conf

deliver_load_max
deliver_queue_load_max
queue_only_load

Howard, could you explain a little more on what effect this does or doesn't have? And what you have set yours to? And, did it help the matter any?
Thank you.

[fredkk]

This is what I just got when I tried to send the queue manually
Single queue run
LOG: 0 MAIN
Start queue run: pid=10557
delivering message 198AK4-0002aB-00 (queue run pid 10557 fd 5)
LOG: 5 MAIN
== fredkk@pay-email.com T=virtual_userdelivery defer (-43): Retry time not yet reached
LOG: 0 MAIN
End queue run: pid=10557
Complete

It did not send a dang thing it is still sitting on the server

[howard]

queue_only_load will cause exim to autoplace messages on the queue if the load avg on the machine is above the specifed value

deliver_load_max will cause exim to not do any message deliveries if the load avg is above the value specfied if it is in the middle of a queue run then it will check to see if the deliver_queue_load_max is sey if the load is above the value specifed then the run will be aborted

deliver_queue_load_max will help exim to decide weather to abort a queue run with regard to the above

Heres the offical explantion frm the exim docs

deliver_load_max Type: fixed-point Default: unset

When this option is set, no message deliveries are ever done if the system
load average is greater than its value, except for deliveries forced with
the -M option. If "deliver_queue_load_max" is not set and the load gets
this high during a queue run, the run is abandoned. There are some
operating systems for which Exim cannot determine the load average (see
chapter 1); for these this option has no effect.

deliver_queue_load_max Type: fixed-point Default: unset

If this option is set, its value is used to determine whether to abandon a
queue run, instead of the value of "deliver_load_max".

queue_only_load Type: fixed-point Default: unset

If the system load average is higher than this value, all incoming
messages are queued, and no automatic deliveries are started. If this
happens during local or remote SMTP input, all subsequent messages on the
same connection are queued. Deliveries will subsequently be performed by
queue running processes, unless the load is higher than
"deliver_load_max". There are some operating systems for which Exim cannot
determine the load average (see chapter 1); for these this option has no
effect. See also "smtp_accept_queue" and "smtp_load_reserve".

(i can paste the two mentioned if people want them)

the exim+viruscan package sets the above options to the following

deliver_load_max = 3
deliver_queue_load_max = 5
queue_only_load = 4

the rpm (e.g. exim-3.36-xxx_cpanel_stmpcontrol_antivirus.i386.rpm) exim.conf only sets deliver_queue_load_max to the following

deliver_queue_load_max = 3

You can comment these out if people wish then exim won't bother about the load stuff, or set the defaults higher

[Silverado]

Thanks Howard.... LOL. I was just looking at it when I got your new post. I should have known that... brainlock I think.
Anyway... have you tried commenting them out? This seems like a very viable solution to me...... a little risky.. but maybe worth it.

Shell is open now.... just waiting to see if you've tried it.

This is all that is under that heading.
# primary_hostname =
deliver_queue_load_max = 5
sender_verify = true
headers_sender_verify = true

I already set it to 5 a couple of weeks ago.... and it helped a little... just not sure if I should throw it up to 10 or 20 because I thought that was only used for when you "force delivery".

Another Add in edit.... I just set it to 20... restarted exim and it had no effect. I am about 100% sure this is only to set the "forced delivery" load.