On Mon, Jan 28, 2019 at 10:04 AM Ludwig <lkrispen@xxxxxxxxxx> wrote: > > > > On 01/24/2019 10:34 PM, William Brown wrote: > > > >> On 25 Jan 2019, at 10:08, Mark Reynolds <mreynolds@xxxxxxxxxx> wrote: > >> > >> > >> On 1/24/19 3:35 PM, Mihai Carabas wrote: > >>> On Thu, Jan 24, 2019 at 10:17 PM Mark Reynolds <mreynolds@xxxxxxxxxx> wrote: > >>>> On 1/24/19 1:54 PM, Mihai Carabas wrote: > >>>> > >>>> Hello, > >>>> > >>>> [root@ldap ~]# dsctl slapd-ldap db2ldif --replication cursdb cursdb.ldif > >>>> > >>>> cursdb.ldif doesn't seem to contain any replication related info. What > >>>> should contain related to replication? > >>>> > >>>> You should at least see an entry with "dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff", if you don't see this entry in the LDIF then it might not be working (sigh). You can then use the legacy tool: > >>>> > >>> Is there. All is ok. > >>> > >>> After exporting LDIF and importing again, the search still is buggy. > >>> > >> Yeah this is looking like a known bug that we will be working on soon… > > Looking at the entryid and indexes, everything seems correct, so this does seem like a bug. Have we got an issue id Mark? > I think it is: https://pagure.io/389-ds-base/issue/50103, the fix is not > yet ready I am a little confused. I have read the issue: is this issue about my ldapsearch problem or about the reindex problem? > > you can repair it by explicitely reindexing the entryrdn index. ..... -t > entryrdn Why on entryrdn will work? When you say entryrdn in my case, you are refering at what rdn? Thank you and sorry for the dumb questions, Mihai > > > >> Question, would you be willing to try a "special logging" build to see we can figure out why the reindex task is hanging? The stacktraces did not show anything helpful, so we need to see which entry is causing the issue and the easiest way, besides walking you through using gdb (which I would be willing to do), would be to provide a special build that logs extra info to the errors log. I know that is a lot to ask, so no worries if you aren't comfortable with it. > >> > >> Thanks, > >> Mark > >> _______________________________________________ > >> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > >> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx > >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx > > — > > Sincerely, > > > > William Brown > > Software Engineer, 389 Directory Server > > SUSE Labs > > _______________________________________________ > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
