rozen remote_smtp defer (-1) 0x000b only with webmails.

O

ozgurerdogan

Verified User
Joined
Apr 20, 2008
Messages
343
All mail traffic are fine no frozen mails in qeueu. But when sending mail from webmail, I get frozen mail in queue but mail in fact DELIVERS fine.

I tried every possibile fix but no luck.

rozen remote_smtp defer (-1) 0x000b
 
I am having a similar issue for incoming mail for a single user. It just started last week after some updates. Here the message I get:
R=lookuphost T=remote_smtp defer (-1): smtp transport process returned non-zero status 0x000b: terminated by signal 11
*** Frozen
This user has a alias that forwards to an external email account. I can't figure out why his emails are getting frozen in the queue and it is not happening for any other user. Any suggestions?
 
I had to roll back server to a prev. backup. Spent lots of hour but was not lucky to fix it.
 
shaggy said:
I am having a similar issue for incoming mail for a single user. It just started last week after some updates. Here the message I get:
R=lookuphost T=remote_smtp defer (-1): smtp transport process returned non-zero status 0x000b: terminated by signal 11
*** Frozen
This user has a alias that forwards to an external email account. I can't figure out why his emails are getting frozen in the queue and it is not happening for any other user. Any suggestions?
Click to expand...

I have the same problems as you. I believe it started just after I upgraded from CentOS 6.6 to 6.7. I have tryed to recompile exim, but it did not help. I believe we should see more reports about this from users that have upgraded to CentOS 6.7

However please try to tick the mail in mail queue that is frozen, then click "Thaw", then click "Retry". Every time I do that, it works and deliver fine.
 
Ditto,
That's when it started happening for me too. Right after the upgrade to CentOS 6.7. I have recompiled Exim, spamassasin, php, apache, etc.. Like you said it works when you thaw the messages from the queue. I guess we can only wait to see if there is a fix soon.
 
Hi,

I had this issue with some custom routers in exim (sending to exchange at my clients on a different port).
Mails delivered fine, but stayed in the queue as frozen.

My CB2 options.conf file:
Code: 
#Mail Settings
exim=yes
eximconf=yes
eximconf_release=4.3
blockcracking=yes
easy_spam_fighter=yes
spamassassin=yes
dovecot=yes
dovecot_conf=yes
pigeonhole=yes

after setting eximconf_release=4.2 and running ./build eximconf my problem was gone.
Reverting to 4.3 and again running ./build eximconf the issue did not reappear.

maybe this helps any of you.

Stijn
 
I am also getting this error in my Exim logs:

Code: 
smtp transport process returned non-zero status 0x000b: terminated by signal 11

Must be a bug in the new CentOS 6.7 update...
 
Hey guys, I'm quite desperate for a solution for this problem. Any ideas?
 
@czotos
after updating the OS did you recompile the exim binaries? This would be highly recommended for all services as you've just swapped out the bulk of it's linked libraries, so it may need the recompile to learn how to use the new ones, eg:
Code: 
./build exim

@Kiekeboe100
This might imply the same thing, try a recompile of the exim binaries. Changing the exim.conf version would likely just alter what features it's using, but the fix would be to resolve the broken feature: recompile exim.

John
 
For me it did not help to recompile exim. For now I am just doing "thaw" and "retry" on the frozen messages in mail queue. But hopefully there will be a fix for this in the future.
 
Hmm... if a thaw/retry works, then it almost seems related to this old guide:
http://help.directadmin.com/item.php?id=114

which refers to the file descriptor limit issue.

If the "live" process, like smtp or php mail()->exim are already at or over the FD limit, then it might fail..
Then it goes into the spool to be retried later... and the "later" exim process is not a child of "apache", so the FD limit might not apply.

Check:
/etc/init.d/exim

and right after the #!/bin/sh line, try adding:
Code: 
ulimit -HSn 32768
also check your shell's current limit:
Code: 
ulimit -n
if it's showing 1024 and you restart exim, then exim's new FD limit might be 1024.
So adding the high value right in the exim boot script overrides whatever limit it's being given and tells the system that it needs more.

Anyway, that's just a guess, so see if that makes any difference for you.

John
 
Thank you for the suggestion. However I already have a high ulimit on all my servers:

Code: 
[root@server~]# ulimit -n
65535
[root@server~]#

Please note that the problem with frozen emails only seem to happen when a email have the letter "D" right before the email address in the "Recipient(s)" column in mail queue. Also note that I have this problem on several servers, and it only started to happen after I upgraded from CentOS 6.6 to 6.7.
 
Last edited:
Hi John and others

I have tried all the solutions provided above, including recompiling Exim from source and making all the limit changes - but I am still having the same issue.

I am desperate for a solution that works. Any more ideas folks?

Thanks.
 
czotos said:
Hi John and others

I have tried all the solutions provided above, including recompiling Exim from source and making all the limit changes - but I am still having the same issue.

I am desperate for a solution that works. Any more ideas folks?

Thanks.
Click to expand...

Same here. I only have one user/domain that is having this problem. Mail delivery to all other users/domains works fine. R=lookuphost T=remote_smtp defer (-1): smtp transport process returned non-zero status 0x000b: terminated by signal 11
*** Frozen
 
Hmm.. the exim binaries need to be debugged for the segfault. To force the delivery of a message, the -M option is used, eg:
Code: 
exim -M [I]MESSAGEID[/I]
and hopefully, that will trigger a segfault so we can use gdb to debug it further.

For that, you'd use:
Code: 
gdb /usr/sbin/exim
and once in gdb, run:
Code: 
run -M [I]MESSAGEID[/I]
bt full
which would hopefully give us a function call or code point, so we can possibly make a guess as to the area causing the problem...

The one suspicion I have would be SSL/TLS... based on the id=114 guide... but disabling TLS is less of an option these days due to the fact that a lot of external servers are going to insist on using it.

One other thing to try would be an older version of exim.. to see if it's a code bug that was recently introduced. Eg, if you're running 4.86, try 4.85.
help.directadmin.com/item.php?id=565&in1=exim&in2=4.85&in3=

John
 
This is what I get when I run gdb:

Code: 
(gdb) run -M 1ZTz3l-0001xV-1n
Starting program: /usr/sbin/exim -M 1ZTz3l-0001xV-1n
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffc1137000
[Thread debugging using libthread_db enabled]
Detaching after fork from child process 29270.

Program exited normally.
Missing separate debuginfos, use: debuginfo-install da_exim-4.76-1.x86_64
(gdb) bt full
No stack.

I tired to do a install of the debug info via yum but get this:

Code: 
Could not find debuginfo for main pkg: da_exim-4.76-1.x86_64

I am running Exim 4.86. I can try to revert back to 4.85 and see if that helps.
 
Last edited:
@shaggy and @DirectAdmin Support, The problem started after upgrading from CentOS 6.6 to 6.7, it has nothing to do with exim 4.86 og 4.85, it will not help to revert to 4.85
 
I am not sure this problem is specifically due to Centos 6.6 to 6.7 upgrade. I did the upgrade to 6.7 some weeks ago and this problem just started this monday. At least, that has been our case.
Adding the ulimit -HSn 32768 line didn't work for us either.
Any other sugestions?
 
It might be a bug in exim 4.86. It might be this bug?: https://bugs.exim.org/show_bug.cgi?id=1671

Please look at "Comment 14" and "Comment 15" in that url above.

Comment 14 links to this commit/patch: http://git.exim.org/exim.git/commitdiff/dadff1d47e54962b0fdf98e8ce5cef42b6cb7fb5

Comment 15 links to the changelog description for above commit/pathc: http://git.exim.org/exim.git/commitdiff/f1b81d811582d37370363ba0a7ea3bc2422a5e66

@DirectAdmin Support: Can you look into this? I am not sure if I understand it correctly, but I think this commit/patch will fix the bug we are experiencing. Please try to add the commit/patch from "Comment 14" in the bug report to custombuild. Thanks.
 
You must log in or register to reply here.
Back
Top