Re: (ITS#4375) MOD operations not being logged

[quanah@stanford.edu]

--On Monday, February 06, 2006 8:12 PM +0000 hyc@symas.com wrote:

> quanah@stanford.edu wrote:
>> --On Friday, February 03, 2006 10:44 AM -0800 Howard Chu <hyc@symas.com>
>> wrote:
>>
>>
>>> quanah@stanford.edu wrote:
>>>
>>>> Full_Name: Quanah Gibson-Mount
>>>> Version: 2.3.18
>>>> OS: Solaris 8
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (171.66.155.86)
>>>>
>>>>
>>>> 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
> operation.

Then why is it logging *HALF* of the operation.  That is what is broken 
here.

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.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html