[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: RE: Sporadic SLURPD replication problems
Jasen,
I forgot to tell you that the underlying bdb databases may not be compatible between 32 and 64 bit slapd's. At least when I tried to start 64 bit slapd on databases generated with 32 bit slapd, slapd segfaults. I am using LDBM though. I had to use slapcat(32 bit version)and slapadd (64 bit version) before I could use the 64 bit slapd. Also make sure that no BerkeleyDB 32 bit environment is left when you start 64 bit slapd.
Regards,
Erik
>
> Van: "Jasen R. Baker" <jbaker@infinityinternet.com>
> Aan: <edg72@home.nl>
> Datum: do 31 jul 03, 9:59
> Onderwerp: RE: RE: Sporadic SLURPD replication problems
>
> Hi Erik, thanks for all the help on this. I'm using the gcc compiler 2.3. I was able to get it to compile with BerkeleyDB.4.1 in 64bit mode as well, but now I'm getting an odd error on my test install. I don't have a database up yet, but I would think slapd would at least start so I could import my current one.
>
> [root@db1:/usr/local/ldap64/etc/openldap] /usr/local/ldap64/libexec/slapd -f /usr/local/ldap64/etc/openldap/slapd.conf -d 128
> bdb_initialize: Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)
> bdb_db_init: Initializing BDB database
> bdb(o=pai): mmap: Resource temporarily unavailable
> bdb_db_open: dbenv_open failed: Resource temporarily unavailable (11)
> backend_startup: bi_db_open(0) failed! (11)
> bdb(o=pai): txn_checkpoint interface requires an environment configured for the transaction subsystem
> bdb_db_destroy: txn_checkpoint failed: Invalid argument (22)
> slapd stopped.
> connections_destroy: nothing to destroy
>
> -----Original Message-----
> From: edg72@home.nl [mailto:edg72@home.nl]
> Sent: Thu 7/31/2003 12:49 AM
> To: Jasen R. Baker
> Cc: openldap-software@OpenLDAP.org
> Subject: 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
> >
> >
>
>
>
>