Bug 2224937
| Summary: | Sub suffix causes "id2entry - Could not open id2entry err 0" error when the Directory Server starts | ||
|---|---|---|---|
| Product: | Red Hat Directory Server | Reporter: | Muneaki Sugaya <msugaya> |
| Component: | 389-ds-base | Assignee: | LDAP Maintainers <idm-ds-dev-bugs> |
| Status: | CLOSED MIGRATED | QA Contact: | LDAP QA Team <idm-ds-qe-bugs> |
| Severity: | medium | Docs Contact: | Evgenia Martynyuk <emartyny> |
| Priority: | medium | ||
| Version: | 12.2 | CC: | idm-ds-dev-bugs, musoni, progier, ryamamot, tbordaz |
| Target Milestone: | DS12.5 | Keywords: | Triaged |
| Target Release: | dirsrv-12.5 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | sync-to-jira | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-06-26 13:49:28 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This BZ has been automatically migrated to Red Hat Issue Tracker https://issues.redhat.com/browse/DIRSRV-53. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |
The message is also displayed when using latest version (i.e: upstream main branch). It is indeed a minor regression of a recent change. (Issue 5598 - In 2.x, SRCH throughput drops by 10% because of handling of referral (#5604)) The root cause is that during backend initialization, a subtree search is now performed on the backend to determine if the subtree contains smart referrals or not. But when starting the parent backend, the subsuffix backend is not yet started and the search fails. The impact is quite mild: If the db contains smart referrals, there is no impacts. In the other case, the optimization that prevent the performance drop is disabled until next occurrence of the internal search (which by default happens 5 minutes later) In other words: There may be a 10% performance drop for the 5 first minutes after the startup.