[389-users] dirsrv does not start anymore

Vasil Mikhalenya bazilek at gmail.com
Wed Mar 7 07:59:54 UTC 2012


Last entry in yum.log about 389-ds is
Sep 19 16:29:05 Updated: 389-ds-base-1.2.9.9-1.el5.x86_64

I suppose this version crashed. I upgraded to 1.2.10.2 when dirsrv has
already stopped work.


On Tue, Mar 6, 2012 at 8:09 PM, Rich Megginson <rmeggins at redhat.com> wrote:
> On 03/06/2012 09:58 AM, Vasil Mikhalenya wrote:
>>
>> Import of ldif file solved the problem.
>>
>> /usr/lib64/dirsrv/slapd-ldap1/ldif2db -n userRoot -E -i /tmp/output.ldif
>
> Yeah, I was going to suggest that.  Looks like you had some orphan entries
> in your database.
>
> What version of 389-ds-base did you upgrade from before 1.2.10.2?
>
>>
>> Now dirsrv works. I think some entries was lost during export from
>> damaged db files.
>>
>> I want dirsrv be more verbose in case of damaged backend db. Verbosity
>> would save much time for user.
>>
>> And you also better do backups. My backup cronjob was commented out
>> for unknown reason :(
>>
>> On Tue, Mar 6, 2012 at 6:50 PM, Vasil Mikhalenya<bazilek at gmail.com>
>>  wrote:
>>>
>>> More info:
>>>
>>> [root at ldap1 db]# /usr/lib64/dirsrv/slapd-ldap1/db2ldif -n userRoot -E
>>> -a /tmp/output.ldif -s "dc=my,dc=domain" -s "o=userRoot"
>>> Exported ldif file: /tmp/output.ldif
>>> ldiffile: /tmp/output.ldif
>>> [06/Mar/2012:18:44:03 +0300] ldif2dbm - _get_and_add_parent_rdns:
>>> Failed to position cursor at ID 881
>>> [06/Mar/2012:18:44:03 +0300] - ldbm2ldif: Skip ID 881
>>> [06/Mar/2012:18:44:03 +0300] ldif2dbm - _get_and_add_parent_rdns:
>>> Failed to position cursor at ID 881
>>> [06/Mar/2012:18:44:03 +0300] - ldbm2ldif: Skip ID 881
>>> [06/Mar/2012:18:44:03 +0300] ldif2dbm - _get_and_add_parent_rdns:
>>> Failed to position cursor at ID 881
>>> [06/Mar/2012:18:44:03 +0300] - ldbm2ldif: Skip ID 881
>>> [06/Mar/2012:18:44:03 +0300] ldif2dbm - _get_and_add_parent_rdns:
>>> Failed to position cursor at ID 881
>>> [06/Mar/2012:18:44:03 +0300] - ldbm2ldif: Skip ID 881
>>> [06/Mar/2012:18:44:03 +0300] ldif2dbm - _get_and_add_parent_rdns:
>>> Failed to position cursor at ID 881
>>> [06/Mar/2012:18:44:03 +0300] - ldbm2ldif: Skip ID 881
>>> [06/Mar/2012:18:44:03 +0300] ldif2dbm - _get_and_add_parent_rdns:
>>> Failed to position cursor at ID 881
>>> [06/Mar/2012:18:44:03 +0300] - ldbm2ldif: Skip ID 887
>>> [06/Mar/2012:18:44:03 +0300] ldif2dbm - _get_and_add_parent_rdns:
>>> Failed to position cursor at ID 881
>>> [06/Mar/2012:18:44:03 +0300] - ldbm2ldif: Skip ID 887
>>> [06/Mar/2012:18:44:03 +0300] ldif2dbm - _get_and_add_parent_rdns:
>>> Failed to position cursor at ID 881
>>> [06/Mar/2012:18:44:03 +0300] - ldbm2ldif: Skip ID 888
>>> [06/Mar/2012:18:44:03 +0300] ldif2dbm - _get_and_add_parent_rdns:
>>> Failed to position cursor at ID 881
>>> [06/Mar/2012:18:44:03 +0300] - ldbm2ldif: Skip ID 888
>>> [06/Mar/2012:18:44:03 +0300] ldif2dbm - _get_and_add_parent_rdns:
>>> Failed to position cursor at ID 881
>>> [06/Mar/2012:18:44:03 +0300] - ldbm2ldif: Skip ID 889
>>> [06/Mar/2012:18:44:03 +0300] ldif2dbm - _get_and_add_parent_rdns:
>>> Failed to position cursor at ID 881
>>> [06/Mar/2012:18:44:03 +0300] - ldbm2ldif: Skip ID 888
>>> [06/Mar/2012:18:44:03 +0300] - export userRoot: Processed 738 entries
>>> (100%).
>>> [06/Mar/2012:18:44:03 +0300] - All database threads now stopped
>>>
>>> Is database corrupted? What should I do to recover dirsrv?
>>>
>>> On Tue, Mar 6, 2012 at 6:11 PM, Vasil Mikhalenya<bazilek at gmail.com>
>>>  wrote:
>>>>
>>>> attached
>>>>
>>>> On Tue, Mar 6, 2012 at 5:18 PM, Rich Megginson<rmeggins at redhat.com>
>>>>  wrote:
>>>>>
>>>>> On 03/05/2012 06:36 PM, Vasil Mikhalenya wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I can not solve the following issue. I can not start my master
>>>>>> anymore.
>>>>>>
>>>>>> /var/log/dirsrv/slapd-ldap1/errors:
>>>>>> [05/Mar/2012:19:43:06 +0300] - 389-Directory/1.2.10.2 B2012.054.1543
>>>>>> starting up
>>>>>> [05/Mar/2012:19:43:06 +0300] - Detected Disorderly Shutdown last time
>>>>>> Directory Server was running, recovering database.
>>>>>> [05/Mar/2012:19:43:06 +0300] - slapi_add_internal: add_values for type
>>>>>> uniqueMember failed (rc: 20)
>>>>>> [05/Mar/2012:19:43:07 +0300] - slapi_add_internal: add_values for type
>>>>>> uniqueMember failed (rc: 20)
>>>>>> [05/Mar/2012:19:43:07 +0300] - slapd started.  Listening on All
>>>>>> Interfaces port 389 for LDAP requests
>>>>>> [05/Mar/2012:19:43:07 +0300] - Listening on All Interfaces port 636
>>>>>> for LDAPS requests
>>>>>
>>>>>
>>>>> It says it started - is it crashing?  If so, we will need a stack trace
>>>>> to
>>>>> attempt to solve this issue
>>>>> http://port389.org/wiki/FAQ#Debugging_Crashes
>>>>>
>>>>>
>>>>>> [05/Mar/2012:19:43:07 +0300] slapi_ldap_bind - Error: could not send
>>>>>> bind request for id [uid=sync,cn=config] mech [SIMPLE]: error 91
>>>>>> (Can't connect to the LDAP server) -5961 (TCP connection reset by
>>>>>> peer.) 115 (Operation now in progress)
>>>>>> [05/Mar/2012:19:43:07 +0300] NSMMReplicationPlugin -
>>>>>> agmt="cn=eu2-ldap" (eu2-ldap:636): Replication bind with SIMPLE auth
>>>>>> failed: LDAP error 91 (Can't connect to the LDAP server) ((null))
>>>>>> [05/Mar/2012:19:43:07 +0300] slapi_ldap_bind - Error: could not send
>>>>>> bind request for id [uid=sync,cn=config] mech [SIMPLE]: error 91
>>>>>> (Can't connect to the LDAP server) -5961 (TCP connection reset by
>>>>>> peer.) 115 (Operation now in progress)
>>>>>> [05/Mar/2012:19:43:07 +0300] NSMMReplicationPlugin -
>>>>>> agmt="cn=us1-ldap" (us1-ldap:636): Replication bind with SIMPLE auth
>>>>>> failed: LDAP error 91 (Can't connect to the LDAP server) ((null))
>>>>>> [05/Mar/2012:19:43:07 +0300] - slapi_add_internal: add_values for type
>>>>>> uniqueMember failed (rc: 20)
>>>>>>
>>>>>> CentOS release 5.7 (Final)
>>>>>>
>>>>>> Name       : 389-ds
>>>>>> Arch       : noarch
>>>>>> Version    : 1.2.1
>>>>>> Release    : 1.el5
>>>>>>
>>>>>>
>>>>>> Google says nothing.
>>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Vasil Mikhalenya
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Vasil Mikhalenya
>>
>>
>>
>



-- 
Best regards,
Vasil Mikhalenya



More information about the 389-users mailing list