hi,
i came up with this subject some noons before. the symptom is that
several messages just get stuck on the queue, and when there's a
high-debug, strace'd run on them, all it shows is
writing data block fd=6, size=6181, timeout=300
while strace is:
read(3, "This is a multi-part message in "..., 8192) = 5424
read(3, "", 8192) = 0
write(2, "writing data block fd=6 size=618"..., 46) = 46
alarm(300) = 0
write(6, "Received: from [192.168.1.7] (he"..., 6181) = 6181
alarm(0) = 300
rt_sigaction(SIGALRM, {SIG_IGN}, {0x8071898, [], 0x4000000}, 8) = 0
select(7, [6], NULL, NULL, {600, 0}
and stalls here. earlier, i only had this behaviour on a linux box
(kernel 2.2.17-18-19, glibc 2.1.3, with the affected nic being an
interface of a g.703 wic). now, today it also happened on another
linux box (kernel 2.2.20, glibc 2.1.3, over an rtl8029 ethernet nic).
i got a suggestion it might be a libc off-by-one (whatever that means
:)) bug, so i compiled exim statically linked to glibc 2.2.4 (and all
the other libraries), the effect remained the same.
then i got kindof angry, and transferred the stuck queue over to my
workstation (also linux, kernel 2.4.17-rc1, glibc 2.2.4, nic rtl8139),
did a run on them, and all four messages went out in a snap.
this is where i am now. anyone using linux ever seen such a behaviour
? right now it looks to me it might be a kernel issue, however i can't
say that for sure, as it never happens with anything else than exim
(i think i will drop in another mta temporarily next time it happens,
so i can confirm or deny that), and frankly i somehow can't believe
noone has noticed that before :)
anyone, maybe ? any suggestions or even wild guesses are welcome.
a short question: can i turn off the usage of esmtp ? a friend said he
saw such an option around the smtp transport sometime, however we
couldn't find it. hm, and as another suspicion: can i turn pipelining
off ? (on the client side, without affecting the server).
tia,
--
[-]
