Re: [exim] Issue with Larger email deliveries and TLS

Pàgina inicial
Delete this message
Reply to this message
Autor: Andrew McCombe
Data:  
A: exim-users, Andrew McCombe
Assumpte: Re: [exim] Issue with Larger email deliveries and TLS
Hi Phil

Many thanks for your reply.

I've looked at it again and top doesn't show anything that looks out of the
ordinary. The exim process shows 0.0 cpu usage and between 0.1 and 0.2
memory usage.

I have run strace on the process Id that the google mail was coming in on
which I have pasted below (at least, the last few lines - it is a large
mail). However, I'll admin I don't really understand the contents of the
trace. There is a 'Bad file descriptor' line before the log file is opened.

I'm a bit reluctant to compile Exim from scratch as the current set-up is
running Ubuntu 9.04 LTS and is on a third party server. However I will do
this at a last resort.

Stack Trace:

write(4, "xfgxWNA6QWaZG7SX+u4cpcS/zccKr/N/"..., 4096) = 4096
alarm(1800)                             = 0
recvfrom(6, "\27\3\1\5\210", 5, 0, NULL, NULL) = 5
recvfrom(6,
"\10$\213\33\0364\320k\237Z\342BG\3471\344\223\216\265\7\265\254\317q\322\225r|mlP&"...,
1415, 0, NULL, NULL) = 1070
recvfrom(6,
"\252\375\246\226\336\24\377z\240]\263\231\247\366\202\375\223\221\"j\177\237Tc\274{\243[\"Y\r\343"...,
345, 0, NULL, NULL) = 345
recvfrom(6, "i", 1, MSG_PEEK, NULL, NULL) = 1
getrusage(RUSAGE_SELF, {ru_utime={0, 390000}, ru_stime={0, 170000}, ...}) =
0
times({tms_utime=39, tms_stime=17, tms_cutime=0, tms_cstime=0}) = 4511971543
getrusage(RUSAGE_SELF, {ru_utime={0, 390000}, ru_stime={0, 170000}, ...}) =
0
times({tms_utime=39, tms_stime=17, tms_cutime=0, tms_cstime=0}) = 4511971543
recvfrom(6, "i", 1, 0, NULL, NULL)      = 1
alarm(0)                                = 1800
alarm(1800)                             = 0
recvfrom(6, "\27\3\1\5\210", 5, 0, NULL, NULL) = 5
recvfrom(6,
"_\204$\364\310x1\352\"\306\336\334h\256#\341~WECJ\315\346\205\221n\361\374\364\32\371R"...,
1415, 0, NULL, NULL) = 1017
recvfrom(6, "(\335TH\306L\36\217t\264\373\376A\222vz.@D\215\215?\237L\224\f\232\372\220\310\362M"...,
398, 0, NULL, NULL) = 398
recvfrom(6, "\236", 1, MSG_PEEK, NULL, NULL) = 1
getrusage(RUSAGE_SELF, {ru_utime={0, 390000}, ru_stime={0, 170000}, ...}) =
0
times({tms_utime=39, tms_stime=17, tms_cutime=0, tms_cstime=0}) = 4511971584
getrusage(RUSAGE_SELF, {ru_utime={0, 390000}, ru_stime={0, 170000}, ...}) =
0
times({tms_utime=39, tms_stime=17, tms_cutime=0, tms_cstime=0}) = 4511971584
recvfrom(6, "\236", 1, 0, NULL, NULL)   = 1
alarm(0)                                = 1800
alarm(1800)                             = 0
recvfrom(6, "\27\3\1\5\210", 5, 0, NULL, NULL) = 5
recvfrom(6,
"\221\365em\360\254\375\250\3747\2566\264\263#K\210o\327\271\31r\6kLp\264\312\22(\266\327"...,
1415, 0, NULL, NULL) = 964
recvfrom(6, "", 451, 0, NULL, NULL)     = 0
alarm(0)                                = 1800
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
close(4294967295)                       = -1 EBADF (Bad file descriptor)
open("/var/log/exim4/mainlog", O_WRONLY|O_APPEND) = 7
fcntl(7, F_GETFD)                       = 0
fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
fstat(7, {st_mode=S_IFREG|0640, st_size=355206, ...}) = 0
write(7, "2011-02-05 15:00:10 1PljNt-0007U"..., 163) = 163
unlink("/var/spool/exim4/input//1PljNt-0007UH-40-D") = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
close(7)                                = 0
open("/var/log/exim4/mainlog", O_WRONLY|O_APPEND) = 7
fcntl(7, F_GETFD)                       = 0
fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
fstat(7, {st_mode=S_IFREG|0640, st_size=355369, ...}) = 0
write(7, "2011-02-05 15:00:10 SMTP connect"..., 117) = 117
write(4, "v36H5T+B/9T+jTHG5QufW8P2XyIAalH4"..., 3586) = 3586
close(4)                                = 0
munmap(0x7fc8a0998000, 4096)            = 0
rt_sigaction(SIGTERM, {SIG_DFL, [TERM], SA_RESTORER|SA_RESTART,
0x7fc89defeaf0}, {0x7fc8a09ffd40, [TERM], SA_RESTORER|SA_RESTART,
0x7fc89defeaf0}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL, [INT], SA_RESTORER|SA_RESTART,
0x7fc89defeaf0}, {0x7fc8a09ffd40, [INT], SA_RESTORER|SA_RESTART,
0x7fc89defeaf0}, 8) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 390000}, ru_stime={0, 180000}, ...}) =
0
times({tms_utime=39, tms_stime=18, tms_cutime=0, tms_cstime=0}) = 4511971584
getrusage(RUSAGE_SELF, {ru_utime={0, 390000}, ru_stime={0, 180000}, ...}) =
0
times({tms_utime=39, tms_stime=18, tms_cutime=0, tms_cstime=0}) = 4511971584
sendto(5,
"\27\3\1\0.``\206E3K\360\203\0?\277\337\26V\37\273\372Y\221\364F\347\324\37YB\367"...,
51, 0, NULL, 0) = 51
exit_group(0)                           = ?
Process 28785 detached




Regards
Andrew McCombe



On 5 February 2011 05:15, Phil Pennock <exim-users@???> wrote:

> On 2011-02-04 at 18:36 +0000, Andrew McCombe wrote:
> > 2011-02-04 18:01:48 1PlPk7-0000pk-P5 TLS error on connection from (
> > mail-yw0-f54.google.com) [209.85.213.54] (recv): Resource temporarily
> > unavailable, try again.
>
> The error message comes from the TLS provider, either OpenSSL or GnuTLS.
> Running { exim -bV } will tell you which.
>
> > This issue is not unique to Gmail as I am seeing the same in the log file
> > for other hosts but I can reproduce it using gmail.
> >
> > Hopefully someone can point me in the the right direction.
>
> Use top, watch what happens to the Exim processes while receiving the
> mail?
>
> My first hunch is that there's a memory leak and, while processing a
> large mail, you run out of allocatable memory.
>
> If you can rebuild the package with Exim linked against "the other" SSL
> library, to see if it's constrained to just one, that would help.
>
> -Phil
>