Signalled to death by 13 - CONTINUED

[Igor Brezac]

On Wed, 5 Jan 2005, Nikola Milutinovic wrote:

> Derrick J Brashear wrote:
>
>> On Wed, 29 Dec 2004, Nikola Milutinovic wrote:
>> 
>>> I've turned off SPA (defaulting to NTLM), but the "problem" persists. It 
>>> looks like Outlook Express is closing the connection irregularely, there 
>>> is that line in the log:
>> 
>> []
>> 
>>> What troubles me is that the connection is closed almost instantly as the 
>>> user logs in. My connection via Mozilla usually ends with "idle for too 
>>> long" and normal exit of  imapd.
>> 
>> 
>> attach with a syscall tracer (i don't know if tru64 has an 
>> strace/truss/ktrace equivalent) and see what it's doing.
>
>
> Couldn't just attach - I would have to pinpoint the process before it dies 
> and it dies quickly. What I did was I ran entire Cyrus IMAP under a trace.
>
> I located one such process that dies. I'm not going to display the entire 
> trace, that would be too much. I'll just describe what's being done.
>
> 1. normal fork from the master and "execve()"
> 2. load dynamic libraries via "mmap()": sasl2, db-4.2, ssl, crypto, c
> 3. read "imapd.conf"
> 4. initialize DBs in /var/opt/Cyrus-IMAP4-2.2.10/config/db
> 5. load SASL plugins: plain, sasldb, cram-md5, digest-md5, gssapiv2, 
> anonymous, login, ntlm, otp, sql.
> 6. open mailboxes.db and other local things
> 7. reverse DNS resolve the client (IP - Hostname)
> 8. writes to a PID file and dies
>
> This is the last few entries in the trace:
>
> [28598]: getsockname (0, 0x11fffeb68, 0x11fffead8=128) = 0 [ , <2/INET, 143, 
> 192.168.61.11>, 16 ]
> [28598]: obreak (0x14006e000) = 0
> [28598]: getpid () = 28598
> [28598]: open ("/var/opt/Cyrus-IMAP4-2.2.10/config/proc/28598", 
> O_RDWR|O_CREAT|O_TRUNC, 666) = 10
> [28598]: lseek (10, 0, SEEK_SET) = 0
> [28598]: fstat (10, 0x11fffe120) = 0 [ , <2657.414753.94343 -rw------- 1 
> cyrus mail 0 1104908996,1104908996,1104908996> ]
> [28598]: ioctl (10, 0x40067408<Out,TIOCGETP,6>, 11fffe0f8) = -1, Errno 25 
> (Not a typewriter)
> [28598]: write (10, 0x40064808, 35) = 35
> + 79 2e 6f 63 2e 76 65 2e 31 30 32 30 6f 66 6e 69 <00000000> info0201.ev.co.y
> + 30 31 2e 31 36 2e 38 36 31 2e 32 39 31 5b 20 75 <00000010> u [192.168.61.10
> +                                        0a 5d 39 <00000020> 9].
>
> After this there is nothing and the master reports the child died with 
> SIGPIPE.
>

This is not saying much.  Can you attach a debugger (gdb) to the imapd 
process or you should be able to analyze core.  We may be able to get a 
better idea of what is going on from the debugger backtrace.

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