Signalled to death by 13 - CONTINUED
Nikola.Milutinovic at ev.co.yu
Tue Jan 11 01:15:16 EST 2005
Igor Brezac wrote:
> On Mon, 10 Jan 2005, Nikola Milutinovic wrote:
>> Igor Brezac wrote:
>>> Check the imapd.conf man page for debug_command. This may help you.
>> Good advice, but for some other occasion, see below.
>>>> What puzzles me is that this is OE specific. Mozilla works like a
>>>> charm. And this is not 100% OE sessions, I'd say it is some 20-30%.
>>>> So, one time out of three, OE will get itself kicked out, the user
>>>> will not notice anything, since OE will start another and that's it.
>>> Can you look at the traffic between OE and cyrus? You can also turn
>>> telemetry log on and see if cyrus will log some of that stuff for you.
>>> Is it possible this is sasl problem? What mechs do you have enabled?
>> I have all possible mechs enabled.
>> So, I took "ethereal" and started one session from one of the
>> offending machines.
>> The session shows one strange thing, OE starts 2 threads!
>> First, it starts one thread which normally communicates with IMAP
>> server, authenticates and gets to IDLE command. And then nothing.
>> Then about that
> Do you run idled?
>> time, it starts another thread which, again, authenticates and does
>> all normal stuff, like
>> The first thread actually ceases to exist after or about the launch
>> of the other thread. Is the launch of the second thread the cause or
>> the effect of the first one dying is beyond me.
>> I don't think that attaching a debugger would help. What I see in
>> logs is that IMAP reports "connection reset by pear"
>> and I expect to see the same thing with the debugger. What troubles
>> me is that it happens on EACH new connection. Close OE and start it
>> up again, the same thing - two threads, first one dying.
>> Do you still think it would be helpful to use a debugger?
> Yes. You still do not know why the first process (imapd) is dying.
At this point I'm not exactly sure it is dying.
>> Am I wrong in blaming the MS OE?
> It is possible, but imapd should not dump because of a poorly behaving
> mail client.
True, but what should the log look like in case OE or any other client
just decides to cut the TCP connection? I mean, no "LOGOUT", but just
"tcp_stream.close()" in the middle of the session?
I should be able to free one IMAP server soon and direct just one OE at
it for a closer look.
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
More information about the Info-cyrus