Signalled to death by 13 - CONTINUED

[Igor Brezac]

On Tue, 11 Jan 2005, Nikola Milutinovic wrote:

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

Have you tried to run without idled?  Do you really need it?

>
>>> 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?

You will see "connection reset by pear".  Cyrus handles this correctly, at 
least it does for me.

-- 
Igor
---
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