Hi all,
While I still have no idea about the casue, following error are noted in slapd.log repeatedl and seems related to accesslog operations. Fyi.
Thanks again. /ST Wong
------------------------------------ Consumer ----------------------------------------------
Dec 19 00:08:20 nss3 slapd[32000]: daemon: activity on 1 descriptor Dec 19 00:08:20 nss3 slapd[32000]: daemon: activity on: Dec 19 00:08:20 nss3 slapd[32000]: 20r Dec 19 00:08:20 nss3 slapd[32000]: Dec 19 00:08:20 nss3 slapd[32000]: daemon: read active on 20 Dec 19 00:08:20 nss3 slapd[32000]: daemon: epoll: listen=7 active_threads=0 tvp=zero Dec 19 00:08:20 nss3 slapd[32000]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 19 00:08:20 nss3 slapd[32000]: connection_read(20): input error=-2 id=1183, closing. Dec 19 00:08:20 nss3 slapd[32000]: connection_closing: readying conn=1183 sd=20 for close Dec 19 00:08:20 nss3 slapd[32000]: connection_close: deferring conn=1183 sd=20
Dec 17 14:38:53 nss3 slapd[25471]: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" Dec 17 14:38:53 nss3 slapd[25471]: daemon: activity on 1 descriptor Dec 17 14:38:53 nss3 slapd[25471]: daemon: activity on: Dec 17 14:38:53 nss3 slapd[25471]: Dec 17 14:38:53 nss3 slapd[25471]: daemon: epoll: listen=7 active_threads=0 tvp=zero Dec 17 14:38:53 nss3 slapd[25471]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 17 14:38:53 nss3 slapd[25471]: daemon: activity on 1 descriptor Dec 17 14:38:53 nss3 slapd[25471]: daemon: activity on: Dec 17 14:38:53 nss3 slapd[25471]: 44w Dec 17 14:38:53 nss3 slapd[25471]: Dec 17 14:38:53 nss3 slapd[25471]: daemon: write active on 44 Dec 17 14:38:53 nss3 slapd[25471]: daemon: epoll: listen=7 active_threads=0 tvp=zero Dec 17 14:38:53 nss3 slapd[25471]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 17 14:38:53 nss3 slapd[25471]: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" ------------------------------------ Provider ----------------------------------------------
Dec 19 00:31:07 festival slapd[4001]: => bdb_search Dec 19 00:31:07 festival slapd[4001]: bdb_dn2entry("cn=accesslog") Dec 19 00:31:07 festival slapd[4001]: => access_allowed: search access to "cn=accesslog" "entry" requested Dec 19 00:31:07 festival slapd[4001]: <= root access granted Dec 19 00:31:07 festival slapd[4001]: => access_allowed: search access granted by manage(=mwrscxd) Dec 19 00:31:07 festival slapd[4001]: search_candidates: base="cn=accesslog" (0x00000001) scope=1 Dec 19 00:31:07 festival slapd[4001]: => bdb_dn2idl("cn=accesslog") Dec 19 00:31:08 festival slapd[4001]: <= bdb_dn2idl: id=45552 first=2 last=45553 Dec 19 00:31:08 festival slapd[4001]: => bdb_equality_candidates (objectClass) Dec 19 00:31:08 festival slapd[4001]: => key_read Dec 19 00:31:08 festival slapd[4001]: <= bdb_index_read: failed (-30988) Dec 19 00:31:08 festival slapd[4001]: <= bdb_equality_candidates: id=0, first=0, last=0 Dec 19 00:31:08 festival slapd[4001]: => bdb_inequality_candidates (reqStart) Dec 19 00:31:08 festival slapd[4001]: => key_read Dec 19 00:31:08 festival slapd[4001]: <= bdb_index_read 1 candidates Dec 19 00:31:08 festival slapd[4001]: => key_read Dec 19 00:31:08 festival slapd[4001]: <= bdb_index_read 9 candidates Dec 19 00:31:08 festival slapd[4001]: => key_read [~4000 lines of "bdb_index_read <n> candidates, key_read" lines skipped] Dec 19 00:31:10 festival slapd[4001]: <= bdb_index_read 13 candidates Dec 19 00:31:10 festival slapd[4001]: => key_read Dec 19 00:31:10 festival slapd[4001]: <= bdb_index_read 10 candidates Dec 19 00:31:10 festival slapd[4001]: => key_read Dec 19 00:31:10 festival slapd[4001]: <= bdb_index_read: failed (-30988) Dec 19 00:31:10 festival slapd[4001]: <= bdb_inequality_candidates: id=28247, first=2, last=28248
------------------------------------ End ----------------------------------------------
________________________________
From: ST Wong (ITSC) Sent: 12/12/2009 [Sat] 22:26 To: Quanah Gibson-Mount; openldap-software@openldap.org Subject: RE: delta sync repl out of sync
Hi,
When I run that query, I got content of acess log, including those can't be updated to the consumer. The entry contains:
# 20091212000001.000002Z, accesslog dn: reqStart=20091212000001.000002Z,cn=accesslog objectClass: auditModify reqStart: 20091212000001.000002Z reqEnd: 20091212000001.000003Z reqType: modify reqSession: 165 reqAuthzID: cn=Manager,dc=my,dc=domain reqDN: uid=1234567,dc=my,dc=domain reqResult: 0 reqMod: visible:= yes reqMod: modifiersName:= cn=root,dc=my,dc=domain reqMod: modifyTimestamp:= 20091212000000Z reqMod: entryCSN:= 20091212000001.260843Z#000000#001#000000
Is there anything wrong with the entry?
Thanks a lot. /ST Wong
________________________________
--On Wednesday, December 09, 2009 11:58 PM +0800 "ST Wong (ITSC)" ST@itsc.cuhk.edu.hk wrote:
Oops, the space/line feed as caused by the "<-----" I typed in the posting. Original configuration file looks like this:
[snipped] logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog [snipped]
BTW, just note that all 'pending' changes can be synchronized to consumer by restarting slapd.
And what happens if you run that query against the master as the syncrepl DN?
I.e.,
ldapsearch -x -D "<syncrepl dn>" -W <syncrepl passwd> -b "cn=accesslog -H ldap://<master> "(&(objectClass=auditWriteObject)(reqResult=0))"
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration