[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: RE: Sporadic SLURPD replication problems
Jasen,
As far as I know you have to compile all libraries that OpenLDAP uses in 64 bit mode except for the Solaris system libraries of course. It depends on what you use with OpenLDAP. I only had to compile BerkeleyDB in 64 bit mode next to OpenLDAP. Here is my output of ldd for slapd
wsbdess1-root> ldd /usr/local/openldap/libexec/slapd
libdb-3.3.so => /usr/local/lib/libdb-3.3.so
libresolv.so.2 => /usr/lib/64/libresolv.so.2
libgen.so.1 => /usr/lib/64/libgen.so.1
libnsl.so.1 => /usr/lib/64/libnsl.so.1
libsocket.so.1 => /usr/lib/64/libsocket.so.1
libdl.so.1 => /usr/lib/64/libdl.so.1
librt.so.1 => /usr/lib/64/librt.so.1
libpthread.so.1 => /usr/lib/64/libpthread.so.1
libc.so.1 => /usr/lib/64/libc.so.1
libmp.so.2 => /usr/lib/64/libmp.so.2
libaio.so.1 => /usr/lib/64/libaio.so.1
libthread.so.1 => /usr/lib/64/libthread.so.1
/usr/platform/SUNW,UltraAX-i2/lib/sparcv9/libc_psr.so.1
What compiler do you use to compile OpenLDAP?
I found the loglevel on the system that had that replication problem. So I used the same loglevel in order to reproduce the problem.
The loglevel system of OpenLDAP is based on bit fields. This means you can add individual loglevels. In this case 1024 + 256 + 64 + 16 +8 = 1368
Regards,
Erik
>
> Van: "Jasen R. Baker" <jbaker@infinityinternet.com>
> Aan: <edg72@home.nl>
> Datum: wo 30 jul 03, 23:47
> Onderwerp: RE: Sporadic SLURPD replication problems
>
> Ahh.. I am getting that replog.log.lock error. Thank you very much! How did you know to use log level 1368? In the slapd.conf man file I don't see any such debug level.
>
> Second, when you compiled it as 64bit, I assume you had to compile all the libs OpenLDAP uses as 64 bit as well? That's going to be a pain. =)
>
> Thanks again! I sure hope this fixes it.
>
> Jasen
>
> -----Original Message-----
> From: Erik [mailto:edg72@home.nl]
> Sent: Wednesday, July 30, 2003 12:18 PM
> To: Jasen R. Baker
> Cc: openldap-software@OpenLDAP.org
> Subject: Re: Sporadic SLURPD replication problems
>
>
> loglevel 1368
>
> On Wednesday 30 July 2003 19:53, you wrote:
> > Thanks, I'll try that link. Which level of debugging did you have slapd
> > running into to see the errors about the replog?
> >
> > -----Original Message-----
> > From: Erik [mailto:edg72@home.nl]
> > Sent: Wednesday, July 30, 2003 10:58 AM
> > To: Jasen R. Baker
> > Cc: openldap-software@OpenLDAP.org
> > Subject: Re: Sporadic SLURPD replication problems
> >
> >
> > I compiled OpenLDAP as a 64 bit application instead of 32 bit.
> > I am not sure whether this particular problem occurs in your situation as
> > wel. In my logging I saw many occurences of "could not open replog.log" or
> > "could not open replog.log.lock". When that happens, slapd just continues
> > without writing anything to the replog.
> > The Solaris fopen() problem is not fully related to the amount of fd's set
> > with ulimit. You could use the testprog provided by Sun under the following
> > link to see how your system reacts:
> >
> > http://sunsolve.Sun.COM/pub-cgi/retrieve.pl?doc=ffaqs%2F01406&zone_32=fopen
> >
> > Furthermore you should check your slapd logfiles because in my case the
> > problem was caused by slapd and not by slurpd.
> >
> > Erik
> >
> > On Tuesday 29 July 2003 22:31, Jasen R. Baker wrote:
> > > Sure, I'm running Solaris 9 with Berkley 4.1 db as a backend. I've set
> > > the fd limit on each of the ldap systems via the /etc/system file to 4096
> > > as well.
> > >
> > > How where you able to get around that problem you described below?
> > >
> > > Jasen
> > >
> > > -----Original Message-----
> > > From: Erik [mailto:edg72@home.nl]
> > > Sent: Tuesday, July 29, 2003 12:38 PM
> > > To: Jasen R. Baker
> > > Subject: Re: Sporadic SLURPD replication problems
> > >
> > >
> > > Jasen,
> > >
> > > Please provide some extra information like the OS you are running on, the
> > > backend you are using on etc.
> > > I recently found a problem with Solaris 32 bit whereby the slapd could
> > > not open the replica.log.lock or the replica.log file and thus failed to
> > > replicate. It appeared to be a problem with fopen() on Solaris that can
> > > only handle fd's between 0 and 255 while slapd at that moment had > 300
> > > fd's in use.
> > >
> > > Regards,
> > >
> > > Erik
> > >
> > > On Tuesday 29 July 2003 01:10, Jasen R. Baker wrote:
> > > > Question for those with any answer.
> > > >
> > > > I currently have a master/slave setup running OpenLDAP 2.22
> > > >
> > > > I'm having sporadic replication problems. I set slurpd to debug mode -d
> > > > 65535 to watch all requests as they came in. What I'm finding is if I
> > > > make a change to the master, sometimes I'll see data sent via SLURPD to
> > > > my secondary ldap server and it writes the updat as it should.
> > > >
> > > > Other times I don't see anything in the debug logs and nothing is
> > > > written to the slave LDAP server. The only thing I DO see is the time
> > > > stamp on the /usr/local/ldap/var/replica.log.lock file is updated, but
> > > > the timestamp on the /usr/local/ldap/var/replica.log file is not.
> > > >
> > > > Our ldap server gets a tremendous amount of simultaneous requests, I
> > > > don't know how exactly to measure it, but our slapd process on the
> > > > master server runs conststent at abou 60%+ cpu. I'm not sure if load
> > > > has anything to do with it.
> > > >
> > > > Both ldap servers are in sync when I do these tests and I restart them
> > > > both and remove all of the replog and slurpd.replog files and lock
> > > > files just to be safe and it only takes a couple of requests before it
> > > > fails to replicate to the slave server.
> > > >
> > > >
> > > > Jasen Baker
> > > > jbaker@infinityinternet.com
> > > > Manager - Systems Engineering
> > > > Infinity Internet
>
>