Re: slapd goes <DEFUNCT> after random time (ITS#248)

[BoschetM@IPFW.EDU]

Michael,

I had a similar problem over the weekend under HP/UX.  It turned out that
I was low on disk space on /var.  My user maintaince program would start
running, do about 2500 modify/add operations and slapd would exit.  I
increased the size of the volume and it works fine.

Michael Boschet, Jr.
Network Systems Programmer
Indiana Purdue Fort Wayne
boschetm@ipfw.edu
(219) 481-5747

At 12:11 AM 8/11/99 +0000, Michael_Dwyer@TrainingLinks.com wrote:
>"Kurt D. Zeilenga" wrote:
> > Under UNIX semantics, a process is considered defunct if it has exited
> > and has a parent which has not waited for it.  This is often referred
> > >For that matter, I can't even figure out what "DEFUNCT" means!
> > man ps
>
>Grrrr...  I thought it reported them as "Zombie".  Silly me. I assure
>you I am not that much of an idiot. :)  I /know/ some tool calls them
>zombies...
>
> > You should look at the server log files for hints to why it shutdown.
> > Usually the entries associated with the last connection are enough.
>
>slapd[30042]: conn=80 fd=7 connection from huey.hidden.com
>(10.0.0.100) accepted.
>slapd[1984]: conn=80 op=0 BIND dn="" method=128
>slapd[1984]: conn=80 op=0 RESULT err=0 tag=97 nentries=0
>slapd[1985]: conn=80 op=1 SRCH base="O=HIDDEN" scope=2
>filter="(|(cn=KRE*)(mail=KRE*)(sn=KRE*))"
>
>slapd[30042]: conn=81 fd=12 connection from cogsworth.hidden.com
>(10.0.0.107) accepted.
>slapd[1986]: conn=81 op=0 BIND dn="" method=128
>slapd[1986]: conn=81 op=0 RESULT err=0 tag=97 nentries=0
>slapd[1987]: conn=81 op=1 SRCH base="O=HIDDEN" scope=2
>filter="(|(cn=CHOE*)(mail=CHOE*)(sn=CHOE*))"
>
><hang>  (I wasn't here during this hang, so I can't tell you /which/
>process went defunct. Sorry.  I'll have that for you next time this
>happens. This was an access via Netscape Messenger.)  I fear not much
>help, here.  I can turn up the logging and try again.
>
> > If it's aborting due to a memory fault or such, I recommend configurating
> > your environment so that slapd can dump core.  If you do have a core
> > dump, a traceback would be useful (in conjunction with the log)
> > in diagnosing the problem.
>
>It isn't aborting.  It is allowed to dump core, but doesn't appear to
>be dumping one. It just silently dies...
>
> > >My current working theory is that my problems are somehow connected to SYN
> > >COOKIES.
> > I think you are on a wild goose chase.  Your problem is much
> > more likely something quite simple.
>
>I like simple.  However, this one appears to be /too/ simple.  It is
>NOT leaving core files, it is NOT leaving death messages in the logs,
>and it does NOT recover.
>
>I will turn up logging...

Michael Boschet, Jr.
Network Systems Programmer
Indiana Purdue Fort Wayne
boschetm@ipfw.edu
(219) 481-5747