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...
attachment 0001-Ticket-292-logconv.pl-reporting-unindexed-search-wit.patch
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
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=834075
Added initial screened field value.
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.2.11.a1
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.