Hi Rich, 2011/3/25 Rich Megginson <rmeggins@xxxxxxxxxx>: > The 389 Project team is pleased to announce the release of > 389-ds-base-1.2.8 Release Candidate 2. This release has fixes for bugs > found in 1.2.8 testing and bugs from earlier releases. i've made a rapid test compiling from today's sources (1.2.8.rc3 or rc4 i think). I haven't seen any immediately obvious bugs. It is also much more stable than 1.2.7.5. However i've noticed that the order of operations in logs is not always correct : [30/Mar/2011:14:17:03 +0200] conn=13 fd=128 slot=128 connection from 127.0.0.1 to 127.0.0.1 [30/Mar/2011:14:17:03 +0200] conn=13 op=0 BIND dn="" method=128 version=3 [30/Mar/2011:14:17:03 +0200] conn=13 op=1 SRCH base="dc=id,dc=polytechnique,dc=edu" scope=2 filter="(&(|(objectClass=X-Misc)(objectClass=X-Object))(!(X-UniqueId=*)))" attrs="nsUniqueId" [30/Mar/2011:14:17:03 +0200] conn=13 op=1 RESULT err=0 tag=101 nentries=0 etime=0.117000 notes=U [30/Mar/2011:14:17:03 +0200] conn=13 op=2 UNBIND [30/Mar/2011:14:17:03 +0200] conn=13 op=2 fd=128 closed - U1 [30/Mar/2011:14:17:03 +0200] conn=13 op=0 RESULT err=0 tag=97 nentries=0 etime=0.021000 dn="" (the result of op=0 is after op=2) or [30/Mar/2011:14:20:19 +0200] conn=19 fd=128 slot=128 connection from local to /Local/dirsrv/var/run/slapd-dmz.socket [30/Mar/2011:14:20:19 +0200] conn=19 AUTOBIND dn="cn=X LDAP Root" [30/Mar/2011:14:20:19 +0200] conn=19 op=0 BIND dn="cn=X LDAP Root" method=sasl version=3 mech=EXTERNAL [30/Mar/2011:14:20:19 +0200] conn=19 op=1 SRCH base="dc=id,dc=polytechnique,dc=edu" scope=2 filter="(&(|(objectClass=X-Misc)(objectClass=X-Object))(!(X-UniqueId=*)))" attrs="nsUniqueId" [30/Mar/2011:14:20:19 +0200] conn=19 op=2 UNBIND [30/Mar/2011:14:20:19 +0200] conn=19 op=2 fd=128 closed - U1 [30/Mar/2011:14:20:19 +0200] conn=19 op=0 RESULT err=0 tag=97 nentries=0 etime=0.012000 dn="cn=X LDAP Root" [30/Mar/2011:14:20:19 +0200] conn=19 op=1 RESULT err=0 tag=101 nentries=0 etime=0.108000 notes=U (the result of op=0 and op=1 is after op=2) It is not something new, i've tested on 1.2.6.1 (our production environment) and this behavior it is also present. I observe it much more often when the log buffering is off. Don't know if it's a bug or it's because of several threads writing in parallel and it's an expected phenomenon... @+ -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
