#292 logconv.pl reporting unindexed search with different search base than shown in access logs
Closed: wontfix None Opened 9 years ago by nkinder.

https://bugzilla.redhat.com/show_bug.cgi?id=790081 (Red Hat Directory Server)

Description of problem:
logconv.pl's output of unindexed searches showed the search base a a different
search base that what the access logs showed for the search.


Version-Release number of selected component (if applicable):
rhds 8.2, current version

How reproducible:
happens very rarely.  Cust runs logconv.pl daily to look at server performance.
Cust noticed this only because the logconv output was very different on a known
entry

Steps to Reproduce:
1. run logconv.pl
2. check unindexed entries against access logs
3.

Actual results:
incorrect search base

Expected results:
correct search base

Kent, is there an access log I can use to reproduce the problem?

On a side note, there is a limitation on how the script records such data. It uses the conn and op number of the unindexed search. But if you have a restart in the log, the conn and op number might get reused - hence you will could have the wrong values when the output is generated.

To workaround this design/behavior might require a major change to the script. I'd like to confirm this by being able to reproduce it with an access log. So please let me know if you have the access log(s) that generated the problem.

The design of using conn/op numbers to backtrack the result to a operation is widely used through out this script. At first glance, the only option I see, besides a major rewrite, is to have separate "outputs" per restart. I think this might actually be a good feature to have anyway.

Let me know about the log.

Thanks,
Mark

The access log you provided had almost 2000 unindexed searches. I just checked the first 10 and last 10, and they were all correct.

Was there a particular connection I should look at?

Mark

Nevermind, I found it in bugzilla, and I have now reproduced the problem. Continuing investigation...

Mark

Found the problem. We were just grabbing the search base/scope from the last search that was processed. This allows things to get out of synch. Created a new array for storing the conn/op for each base, this way we can guarantee the correct values when generating the report.

[mareynol@localhost src]$ git merge ticket292
Updating 6f8680a..231cd7e
Fast-forward
ldap/admin/src/logconv.pl | 84 ++++++++++++++++++++++++++-------------------
1 files changed, 49 insertions(+), 35 deletions(-)

[mareynol@localhost src]$ git push origin master
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 1.23 KiB, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
6f8680a..231cd7e master -> master

originally targeted for 1.2.11.rc1, but actually in the 1.2.11.a1 release

Added initial screened field value.

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.2.11.a1

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/292

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

8 months ago

Login to comment on this ticket.

Metadata