Re: creating a memory leak with slapd (ITS#287)

[Kurt@OpenLDAP.org]

At 02:14 AM 9/14/99 GMT, dumar@tamu.edu wrote:
>Full_Name: Aaron C. DuMar
>Version: 1.2.7
>OS: Linux/OpenBSD
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (165.91.67.166)
>
>
>This isn't a problem, just a note about a problem I had moving from a CSO/PH db
>to
>ldap.  I'm hoping that this will help others that see similar behavior.
>
>Some time back, I convinced our guys to move to an LDAP solution for mail
>aliasing, 
>etc. (our little Solaris machine running CSO/PH has seen better days).  Anyways,
>we
>dumped our data (using a perl script) from the PH server into an ldif format. 
>Then
>using the ldif2ldbm binary from OpenLDAP built the db.  Everything seemed fine,
>except after a few days, slapd would eat up all of our memory and the machine
>was
>worthless (that made our email users quite unhappy :).  So, I set up a script to
>
>restart slapd hourly to handle this until I got the problem solved.
>
>Well, I've finally figured out the memory leak problem.  It seems the problem
>was 
>with the database (which I assume came from the transition from CSO/PH to
>LDAP).
>I'm using the ldbm database, and when I export it to ldif format, I see entries
>like
>
>265
>dn: cn=, ou=Department of Physics, o=Texas A&M University, st=TX, c=US
>
>and nothing else (with the exception of the normal well formatted entries).  
>There were about 15 of these things.  No "cn", no other attributes.  Must have 
>been a bug in the db move.

Garbage db entries are commonly resultant of garbage input to
ldif2ldbm(8).  ldif2ldbm(8) is designed to be used with pristine
LDIF, such as produced by ldbmcat(8) (assuming you never run ldif2ldbm).
New entries should only be added using ldapadd(1) (or via ldap_add(3)).