Re: [389-users] Fedora-DS 1.1 showing NSMMReplicationPlugin msgs, becomes unresponsive and dies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Wolf Siedler wrote:
> Thanks for the fast reply, Rich!
>
>   
>> 1.1?  rpm -qi 389-ds-base
>> 32-bit or 64-bit?
>>     
>
> It's fedora-ds-base-1.1.3-2.fc6, 32-bit.
> rpm -qi gives:
> Name        : fedora-ds-base               Relocations: (not relocatable)
> Version     : 1.1.3                             Vendor: (none)
> Release     : 2.fc6                         Build Date: Thu 25 Sep 2008
> 09:58:45 AM HKT
> Install Date: Mon 02 Feb 2009 05:41:56 PM HKT      Build Host: localhost
> Group       : System Environment/Daemons    Source RPM:
> fedora-ds-base-1.1.3-2.fc6.src.rpm
> Size        : 4749479                          License: GPLv2 with
> exceptions
> Signature   : DSA/SHA1, Thu 25 Sep 2008 10:15:27 AM HKT, Key ID
> 0db66119a7b02652
> URL         : http://directory.fedoraproject.org/
> Summary     : Fedora Directory Server (base)
>
> Finally, after several hours and retries, I had success with
> /usr/lib/dirsrv/slapd-admin01/start-slapd -d 1.
> slapd started again, listens, but still displays the "Bad paramter to an
> ldap routine" error.
>   
So, the directory server does not start unless you use -d 1?  That's 
really odd - -d 1 just turns on trace level logging.  Running with -d 1 
will seriously impair performance.
>   
>> Looks like you have some bogus ldap operation that it is attempting
>> to
>> replay.
>>
>> Use cl-dump to dump your changelog - look for a bogus operation.
>>     
>
> Did so. But unfortunately I can't find any operation which looks unusual.
>   
ok
>   
>> I suppose you could use db2ldif to dump your database, then ldif2db
>> to
>> reinit.  Then you'll have to reinit all of your consumers.
>>     
>
> As said, I have slapd running again.
> Would you advise to re-initialize all consumers? Is there a chance that
> this might stop the replaying?
>   
First you have to remove the bad operation from your master database.  
You can do that by using db2ldif then ldif2db.  Then you can reinit your 
consumers from the newly initialized master.
>   
>> I've never seen this happen before.  If you can find a bogus
>> operation
>> in your changelog, we might be able to work backwards through the
>> access
>> log to find the source.
>>     
>
> As said, unfortunately I didn't find anything suspicious upon first
> reading. I will check again tomorrow and let you know.
>
> Finally, let me say that I am well aware that 389-DS has moved on and
> that an upgrade would be advisable.
>   
It's just going to be difficult to support this version of fedora ds.  
It is possible that you are encountering a bug that has been fixed in 
389, but this problem does not look familiar, so I cannot say for sure.
> It is just that current workload is very high, this is our only LDAP
> master and I am seriously concerned that an upgrade might fail at the
> worst possible time.
>
> Again, thanks for the fast advice!
>
> Regards,
> Wolf
> --
> 389 users mailing list
> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>   

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux