[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd dying ...



I'm running multiple versions all on solaris 8.

On 5/5/05, Samuel Tran <stran@amnh.org> wrote:
> On Wed, 2005-05-04 at 23:25, matthew sporleder wrote:
> > I have strange crashes as well, but under much heavier load and a
> > different setup.  ;)
> > Is it possible that your indexes are messed up, or something along those lines?
> > What's the behaviour of the crash?  Do you get core files, or does it
> > just shutdown?
> >
> > Did you try truss/ktrace/strace-ing the search and/or server during
> > these hangs to see what was happening?  Are there some db-specific
> > monitorings you could try?
> >
> > On 5/4/05, Samuel Tran <stran@amnh.org> wrote:
> > > Hi all,
> > >
> > > I run several OpenLDAP server 2.2.23 + Berkeley 4.2.52 (patched) on Debian
> > > Linux Woody. I have more than 2,000 entries in the directory. I have a LVS
> > > load balancer in front of the slaves. Every slave processes about 50
> > > req/sec.
> > >
> > > Once in a while slapd would die. When I restart it everything looks fine
> > > until I do a ldapsearch of the whole directory and find out that the
> > > output of the ldapsearch stops at a specific entry. When I try to stop
> > > slapd, it wouldn't kill the processes. I have to manually kill each one of
> > > them. In order to fix the problem I have to run a db_recover, then restart
> > > slapd.
> > >
> > > This problem occured on the master and on the slaves.
> > >
> > > I am not sure what is going on.
> > >
> > > Would an upgrade to OpenLDAP 2.2.26 fix the problem?
> > > Has anyone experienced the same problem?
> > >
> > > I would appreciate any input.
> > >
> > > Thanks in advance.
> > > Sam
> > >
> 
> Matthew,
> 
> I am not sure if the indexes are messed up or not.
> There was no core file when the last crash occured. The slapd processes just shut down.
> Next time the same problem occurs I'll do an strace.
> 
> I am considering upgrading to OL 2.2.26.
> What version are you running?
> 
> Thanks for you help.
> 
> Sam
> 
> 
> 


-- 
_Matt