On Thu, Feb 16, 2017 at 03:53:40PM -0800, Quanah Gibson-Mount wrote:
It appears to be crashing while writing the change to the accesslog database. It's odd that the value for the attribute is NULL. Do we know for sure what the client doing the write op to the server is sending?
The code is in perl, and looks like this:
$entry->replace(eduPersonAffiliation => @eduPersonAffiliation);
In this case, the array @eduPersonAffiliation is empty, effectively deleting the attribute. I'm not 100% sure what this generates on the wire, I'd have to debug it. I can say it's the same code that's been running for a decade or so with no issues.
Yeah, so this is the operation that actually failed... It'd be interesting to know if it succeeded in the primary DB, but failed when writing to the accesslog DB
I already reran that operation to fix the expiration, but the next time it crashes I'll take a look at the primary and secondaries first to see if they're out of sync.
Hm, so I guess my question would be is it doing the op like this:
Hmm, the expiration code when removing an expiration looks like:
$entry->delete('cppEduPersonExpiration');
So it should be a delete on the wire for removing the attribute. You think it crashed on the expiration operating, even though the backtrace shows the segfault having the eduPersonAffiliation accesslog reqStart id?
dn: ... changetype: modify replace: csupomonaEduPersonExpiration csupomonaEduPersonExpiration:
Or is it doing it like this:
dn: ... changetype: modify delete: csupomonaEduPersonExpiration
Because the NULL value seems to imply the former.