Re: (ITS#5835) master slapd dying on lost writes

[quanah@zimbra.com]

--On Monday, December 01, 2008 9:51 PM +0000 quanah@zimbra.com wrote:

> --On Friday, November 28, 2008 7:40 PM +0000 quanah@zimbra.com wrote:
>
>>
>>
>> --On November 28, 2008 11:35:45 AM -0800 Quanah Gibson-Mount
>> <quanah@zimbra.com> wrote:
>
> Latest backtrace, with the patch from HEAD about idletimeout, we get:

As a side note, here's a working teardown:

Dec  2 17:45:05 ldap slapd[29835]:
Dec  2 17:45:05 ldap slapd[29835]: connection_closing: readying conn=52 
sd=22 for close
Dec  2 17:45:05 ldap slapd[29835]: connection_close: deferring conn=52 sd=-1
Dec  2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 
tvp=zero
Dec  2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 
tvp=zero
Dec  2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor
Dec  2 17:45:05 ldap slapd[29835]: daemon: activity on:
Dec  2 17:45:05 ldap slapd[29835]:
Dec  2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 
tvp=zero
Dec  2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 
tvp=zero
Dec  2 17:45:05 ldap slapd[29835]: connection_resched: attempting closing 
conn=52 sd=22
Dec  2 17:45:05 ldap slapd[29835]: daemon: removing 22
Dec  2 17:45:05 ldap slapd[29835]: conn=52 fd=22 closed (idletimeout)
Dec  2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor
Dec  2 17:45:05 ldap slapd[29835]: daemon: activity on:
Dec  2 17:45:05 ldap slapd[29835]:
Dec  2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 busy
Dec  2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 
tvp=zero
Dec  2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor
Dec  2 17:45:05 ldap slapd[29835]: daemon: activity on:
Dec  2 17:45:05 ldap slapd[29835]:
Dec  2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 
tvp=zero
Dec  2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 
tvp=zero
Dec  2 17:45:05 ldap slapd[29835]: daemon: listen=7, new connection on 22
Dec  2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor
Dec  2 17:45:05 ldap slapd[29835]: daemon: activity on:
Dec  2 17:45:05 ldap slapd[29835]:  22r
Dec  2 17:45:05 ldap slapd[29835]:
Dec  2 17:45:05 ldap slapd[29835]: daemon: read active on 22
Dec  2 17:45:05 ldap slapd[29835]: daemon: added 22r (active) listener=(nil)
Dec  2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 
tvp=zero
Dec  2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 
tvp=zero
Dec  2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor
Dec  2 17:45:05 ldap slapd[29835]: daemon: activity on:
Dec  2 17:45:05 ldap slapd[29835]:
Dec  2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 
tvp=zero
Dec  2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 
tvp=zero
Dec  2 17:45:05 ldap slapd[29835]: conn=63 fd=22 ACCEPT from 
IP=192.168.61.36:49196 (IP=192.168.58.179:389)
Dec  2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor
Dec  2 17:45:05 ldap slapd[29835]: daemon: activity on:


As you can see, there's a break between the teardown and accept in this 
case, as compared to the scneario where it asserts.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration