Slow delivery

P

Pascal

Verified User
Joined
Jan 2, 2006
Messages
72
Location
Arnhem, The Netherlands
The last time I'm getting questions why the delivery is not as fast as expected. Before the mailqueue was implemented I was looking allready at the queue. What I'm am noticing is that new e-mail is getting freezed first, after that it's hanging on the queue. Manual doing a retry and it is delivered. How come?

Using EXIM 4.63 with OpenSSL 0.9.8d.

Code: 
2006-10-03 19:11:32 Received from [email][email protected][/email] U=apache P=local S=634 T="Subject"
2006-10-03 19:11:32 [email][email protected][/email] R=lookuphost T=remote_smtp defer (-1): smtp transport process returned non-zero status 0x000b: terminated by signal 11
*** Frozen

http://help.directadmin.com/item.php?id=114

Doesn't work...
 
Last edited:
I have the same problem

the only way is to change
/usr/local/directadmin/data/users/domain.com/httpd.conf

and change the -i switch in php admin value to -odq

So the message does not freeze
but delivered after 15 minutes, next quene
 
Code: 
[root@sf01 admin]# cd /lib/
[root@sf01 lib]# ls -l libssl*
-rwxr-xr-x  1 root root 228292 Oct 12  2005 libssl.so.0.9.7f
lrwxrwxrwx  1 root root     11 Mar  1  2006 libssl.so.0.9.8 -> libssl.so.4
lrwxrwxrwx  1 root root     24 Oct  7 13:39 libssl.so.4 -> /usr/lib/libssl.so.0.9.8
lrwxrwxrwx  1 root root     16 Oct  7 13:13 libssl.so.5 -> libssl.so.0.9.7f
[root@sf01 lib]# rm -rf libssl.so.5
[root@sf01 lib]# ln -s /lib/libssl.so.4 /lib/libssl.so.5
[root@sf01 lib]# ls -l libssl*
-rwxr-xr-x  1 root root 228292 Oct 12  2005 libssl.so.0.9.7f
lrwxrwxrwx  1 root root     11 Mar  1  2006 libssl.so.0.9.8 -> libssl.so.4
lrwxrwxrwx  1 root root     24 Oct  7 13:39 libssl.so.4 -> /usr/lib/libssl.so.0.9.8
lrwxrwxrwx  1 root root     16 Oct 13 17:27 libssl.so.5 -> /lib/libssl.so.4

My solution for a day :rolleyes:
 
Last edited:
Have recompiled apache php and exim.
No luck


Pascal said:
Code: 
[root@sf01 admin]# cd /lib/
[root@sf01 lib]# ls -l libssl*
-rwxr-xr-x  1 root root 228292 Oct 12  2005 libssl.so.0.9.7f
lrwxrwxrwx  1 root root     11 Mar  1  2006 libssl.so.0.9.8 -> libssl.so.4
lrwxrwxrwx  1 root root     24 Oct  7 13:39 libssl.so.4 -> /usr/lib/libssl.so.0.9.8
lrwxrwxrwx  1 root root     16 Oct  7 13:13 libssl.so.5 -> libssl.so.0.9.7f
[root@sf01 lib]# rm -rf libssl.so.5
[root@sf01 lib]# ln -s /lib/libssl.so.4 /lib/libssl.so.5
[root@sf01 lib]# ls -l libssl*
-rwxr-xr-x  1 root root 228292 Oct 12  2005 libssl.so.0.9.7f
lrwxrwxrwx  1 root root     11 Mar  1  2006 libssl.so.0.9.8 -> libssl.so.4
lrwxrwxrwx  1 root root     24 Oct  7 13:39 libssl.so.4 -> /usr/lib/libssl.so.0.9.8
lrwxrwxrwx  1 root root     16 Oct 13 17:27 libssl.so.5 -> /lib/libssl.so.4

My solution for a day :rolleyes:
Click to expand...
 
Having the same problem with this on a new server we just setup. emailes being sent need to be re tried. Any solution for this yet?
 
I have the same problem on a Debian server.

It runs Exim 4.63 (.deb from files.directadmin.com), but it has the same errors.

I also tried compiling Exim by hand, but that did not succeed either.

Any suggestions?
 
I got the same problem. I just reinstalled openssl, rebuild everything from custom apache including exim and it solved everything.

I guess this problem is caused by an error in installing openssl, which was the cause of my error. Im not sure of the others.
 
You made a lookuphost : is that what you want ?
Have you a delay set up for no response ?
Do you accept if no reponse ?

Be sure that you have a correct configuration from your host and for exim, don't block request.
 
Xemaps - can you explain your questions in detail or provide exact instructions on how to accomplish your suggestions?
In my case I have recompiled everything several times and updated to the latest versions and it still acts intermittently on php mail and sendmail depending on the destination email address while sending straight to SMTP works fine every time.

I had to add the following line to my crontab -e

9-59/10 * * * * /usr/sbin/exim -qff

and it is churning out whatever has been frozen by a "Signal 11 Segfault error" when trying to send by php mail or sendmail. So that new cronjob entry delivers the frozen mail every 10 minutes but it doesn't solve the actual problem - it is just a work around but it is a very effective one. I really want to solve this frozen email problem for everyone's sake - including mine. I noticed it is happening on all of my servers for any users so it is common across the entire family of servers I have. I have always had clients complaining but never been able to reproduce it consistently except to say that my clients would complain about the same symptoms of intermittent delivery depending on email address.

I tried a php mail script to test things out some more and it gets frozen on some destination domain names and not on others.

here is the php mail test script to create and put into your public_html folder
so that I could test the exim errors... I created a file called mailtest.php with this in it.

<?
echo "testing...<br>\n";
mail("[email protected]","test","test2");
echo "done\n";
?>

and sent to myself by entering http://mytestdomain.com/mailtest.php - then I sent it to several email addresses across the spectrum from private hosted sites to hotmail and gmail. Sometimes they work and sometimes they don't.

Some how the DNS is not resolving fast enough to prevent the Signal 11 seg fault. I have tried that theory off and on for the last few days with no measurable results. Or the segfault could be a memory problem but my servers have 2GB ram and are not even using the swap memory so I don't see that as a problem either.

According to this forum and jlasman's answers - it is a result of the resolv.conf not having a recursive DNS server as its first entry in that file. I have added my data center's recursive DNS server as the first entry in that /etc/resolv.conf file and I have not noticed any difference in the behavior.

Normally I have 127.0.0.1 and my server DNS IPs as the 3 entries in the /etc/resolv.conf file. I also have the /etc/named.conf set to allow recursion for the local IPs so that all requests from the server will work properly but still prevent requests from elsewhere from working. Either set up behaves the same. I have tried it with the recursion restrictions removed in /etc/named.conf and also noticed no difference in dependability.
 
After all of that theory and hours of struggling and help from the DirectAdmin team - finally - it works as it should on the delivery of emails without freezing the emails. I updated openssl to 9.8.d using the "All-in-One" script and then I reinstalled apache 2.059 and and PHP 4.4.6 and Exim 4.66 - and then it worked. I tried it again after the apache/php step and it didn't work . Then I went on to reinstall Exim and then it worked immediately.

So .... I think we can conclusively say that you can definitely fix it with the latest OpenSSL/Apache/PHP/Exim install/upgrade and in that order when using the "All-In-One" script at http://www.directadmin.com/forum/showthread.php?t=12099
 
gerrybakker said:
After all of that theory and hours of struggling and help from the DirectAdmin team - finally - it works as it should on the delivery of emails without freezing the emails. I updated openssl to 9.8.d using the "All-in-One" script and then I reinstalled apache 2.059 and and PHP 4.4.6 and Exim 4.66 - and then it worked. I tried it again after the apache/php step and it didn't work . Then I went on to reinstall Exim and then it worked immediately.

So .... I think we can conclusively say that you can definitely fix it with the latest OpenSSL/Apache/PHP/Exim install/upgrade and in that order when using the "All-In-One" script at http://www.directadmin.com/forum/showthread.php?t=12099
Click to expand...

Actually I updated my server too but without good result.

I first updated to OpenSSL 0.9.8e. After that I recompiled PHP to 5.2.1 and Exim 4.66 again. The e-mail sent with mail() are not FROZEN on the queue but still not sending immediatly :(. I remember I don't need to recompile apache because OpenSSL is dynamicly loaded.

I did see something different on the queue now. When there is an e-mail send the queue says the following:
Code: 
2007-04-13 09:46:07 Received from [email protected] U=apache P=local S=3267 T="TEST"
2007-04-13 09:46:07 SMTP timeout while connected to mx1.domain.com [IP #1] after initial connection: Connection timed out
2007-04-13 09:46:07 SMTP timeout while connected to mx2.domain.com [IP #2] after initial connection: Connection timed out
2007-04-13 09:46:07 SMTP timeout while connected to mx3.domain.com [IP #3] after initial connection: Connection timed out
2007-04-13 09:46:07 SMTP timeout while connected to mx3.domain.com [IP #4] after initial connection: Connection timed out
2007-04-13 09:46:07 [email protected] R=lookuphost T=remote_smtp defer (110): Connection timed out: SMTP timeout while connected to mx3.domain.com [IP #4] after initial connection

So, what to do with the time-outs?

A simple retry on the queue will send the e-mail without a problem :(
 
Last edited:
Pascal, try sending me an email, and check your quotas ...

Then post again letting me know your time zone in +/- format, so I can find your attempt in my logs.

Jeff
 
We've got the same problem here since last thursday. We tried everything suggested on this forum or other websites, but without succes.
So far it seems to be guessing for everyone what the real problem is and how to solve it.

When PHP sends an e-mail to any external address, it will freeze and stay frozen for between 30 minutes til 3 hours. Internal e-mail will get delivered immediately.

The exact error we are receiving is:
2007-12-22 18:19:04 Received from [email protected] U=apache P=local S=1151 T="Subject"
2007-12-22 18:19:05 [email protected] R=lookuphost T=remote_smtp defer (-1): smtp transport process returned non-zero status 0x000b: terminated by signal 11
*** Frozen

Right now it really drives me crazy. Nobody really knows how to solve this, while it's a serious problem!!
 
As an update to this issue (new information has come in), I've updated http://help.directadmin.com/item.php?id=114 with more information about the issue. It appears to be a filedescriptor limit issue with exim (hitting the system limit), so cranking up the FD_SETSIZE value and recompiling exim should do the trick.

John
 
You must log in or register to reply here.
Back
Top