Signalled to death by 13 - CONTINUED

[Nikola Milutinovic]

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?


Yes.

>> time, it starts another thread which, again, authenticates and does 
>> all normal stuff, like
>>
>> IDLE
>> SELECT
>> FETCH
>> and
>> LOGOUT
>>
>> 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.

Nix.
---
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