[Date Prev][Date Next]
Re: (ITS#4375) MOD operations not being logged
--On Monday, February 06, 2006 8:12 PM +0000 email@example.com wrote:
> firstname.lastname@example.org wrote:
>> --On Friday, February 03, 2006 10:44 AM -0800 Howard Chu <email@example.com>
>>> firstname.lastname@example.org wrote:
>>>> Full_Name: Quanah Gibson-Mount
>>>> Version: 2.3.18
>>>> OS: Solaris 8
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (188.8.131.52)
>>>> In looking at an error occurring on my master, I found that the MOD
>>>> operation causing the error is not being logged at loglevel 256 like it
>>>> should be.
>>> It's working in test004. You'll have to provide more info on how to
>>> reproduce the problem.
>> It only happens when a single valued attribute is given multiple values
>> on the MOD, causing it to fail. All other MOD ops are logged
>> correctly. I'm working on setting up a reproducible scenario.
> The Statslog message you're looking for is only logged after a number of
> validity checks have passed. If the checks fail the operation is aborted
> before getting to the Statslog. This is by design, most of the
> operations will abort on invalid input and not log the offending
Then why is it logging *HALF* of the operation. That is what is broken
One further datapoint. It only happens on MODifications made to the tree
that does not have the uniqueness overlay on it. Still working on the
configuration to duplicate this.
I'd think the discarding of the first half of the MOD error is a serious
error, as it leaves the LDAP administrator in the dark as to what DN the
operation is failing on.. Just that it is failing.
Principal Software Developer
ITS/Shared Application Services
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html