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.
