On Mon, Jan 28, 2019 at 10:04 AM Ludwig <lkris...@redhat.com> wrote: > > > > On 01/24/2019 10:34 PM, William Brown wrote: > > > >> On 25 Jan 2019, at 10:08, Mark Reynolds <mreyno...@redhat.com> wrote: > >> > >> > >> On 1/24/19 3:35 PM, Mihai Carabas wrote: > >>> On Thu, Jan 24, 2019 at 10:17 PM Mark Reynolds <mreyno...@redhat.com> > >>> 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@lists.fedoraproject.org > >> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > >> 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@lists.fedoraproject.org > > — > > Sincerely, > > > > William Brown > > Software Engineer, 389 Directory Server > > SUSE Labs > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > > 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@lists.fedoraproject.org > _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
