Running tests that use client cert auth results in the following in the errors log: [14/Nov/2013:14:29:50 -0700] Internal search - Unindexed search: source (cn=server,cn=plugins,cn=config) search base="o=airius.com" filter="description=CN=MMR S2 Cert,O=fr" etime=0 nentries=0 notes=U
I think these errors should not be logged by default.
Why not log them to the access log, if logging is enabled for internal ops?
This internal unindexed search logging was added to solve this issue. https://fedorahosted.org/389/ticket/47401 Ticket #47401 - report unindexed internal searches If it is logged in the access log (LDAP_DEBUG_ARGS for the internal search), then it's not logged in the error log.
We could change to skip logging this internal unindexed search by replacing the log mode SLAPI_LOG_FATAL with something specific like this. But is it okay for the ticket 47401? {{{ diff --git a/ldap/servers/slapd/result.c b/ldap/servers/slapd/result.c index ef4179d..2af1082 100644 --- a/ldap/servers/slapd/result.c +++ b/ldap/servers/slapd/result.c @@ -2081,7 +2081,7 @@ log_result( Slapi_PBlock pb, Operation op, int err, ber_tag_t tag, int nentrie } plugin_dn = plugin_get_dn(plugin);
I'd think the current code is useful...
I think the user is going to be upset that this fills their error logs with things that aren't really errors.
I don't think error logging at SLAPI_LOG_BACKLDBM is the right way to do this.
I think the access log is the place to log this. The user can enable internal operations logged to the access log. If internal ops are enabled, then the internal ops that are unindexed will be logged exactly the same way as external ops. Then the customer can just run logconv.pl to get the unindexed search report.
Perhaps this is not sufficient, and we should tell users, somehow, that they have unindexed internal searches, but without filling up their errors log. I don't know - I'd like to hear some suggestions.
Understood. We may want to introduce some new log level for performance related. If you see some bad perf, you enable it and gather info. This case could be a good candidate...?
Replying to [comment:4 nhosoi]:
Yes. So I guess we can just close this ticket as WONTFIX, and instead open a new ticket for better performance reporting.
Metadata Update from @rmeggins: - Issue set to the milestone: N/A
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/931
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: Invalid)
Login to comment on this ticket.