From: Ond=F8ej Kuzn=EDk Sent: Monday, March 27, 2017 8:10 AM =20 I've had a look whether I could reproduce the issue somehow and there =

is

a potential crasher if the accesslog entry contained "reqmod: eduPersonAffiliation:+". Can you confirm whether you have entries like this in your logdb?

There aren't currently any entries like that in the log, although the = last crash was a week or two ago. I will check again right after the next = crash. However, here is one of the log entries that appeared to correlate with = what was being processed in the backtrace of one of the crashes:

dn: reqStart=3D20170214120013.000001Z,cn=3Daccesslog

objectClass: auditModify

structuralObjectClass: auditModify

reqStart: 20170214120013.000001Z

reqEnd: 20170214120013.000002Z

reqType: modify

reqSession: 37859

reqAuthzID: cn=3Didmgmt,ou=3Duser,ou=3Dservice,dc=3Dcsupomona,dc=3Dedu

reqDN: uid=3Dvntruong,ou=3Duser,dc=3Dcsupomona,dc=3Dedu

reqResult: 0

reqMod: eduPersonAffiliation:=3D

reqMod: eduPersonPrimaryAffiliation:=3D

reqMod: csupomonaEduPersonAffiliation:=3D

reqMod: entryCSN:=3D 20170214120013.628665Z#000000#000#000000

reqMod: modifiersName:=3D = cn=3Didmgmt,ou=3Duser,ou=3Dservice,dc=3Dcsupomona,dc=3Dedu

reqMod: modifyTimestamp:=3D 20170214120013Z

reqEntryUUID: bd5ba51c-7a1b-4bdb-8bf3-fe90552f5909

entryCSN: 20170214120013.628665Z#000000#000#000000

entryUUID: 4737c48c-e46e-45a4-ba4b-2eb61540b27b

creatorsName: cn=3Daccesslog

createTimestamp: 20170214120013Z

modifiersName: cn=3Daccesslog

modifyTimestamp: 20170214120013Z

And it does not appear to have that signature.

Thanks.