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

Re: slapd crashes (ldap 2.1.30, db 4.1.25)



> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Pierangelo Masarati wrote:
> |>-----BEGIN PGP SIGNED MESSAGE-----
> |>Hash: SHA1
> |>
> |>Hello.  We just moved our production LDAP server to OpenLDAP, after lots
> |>of good results running in limited tests.
> |>
> |>*Something* is crashing slapd.  I don't know what.  Nothing's logged,
> |>and core isn't dumped.  I will submit an ITS if I can figure out what's
> |>going on.
> |>
> |>Our setup:
> |>~  Red Hat Workstation 3.0 w/ 2 CPUS ( + SMP ) and 2 Gb RAM
> |>
> |>~  o=WFU,c=US
> |>~    is an LDAP backend
> |>~    "suffixmassage" translating to "ou=Users,dc=wfu,dc=edu"
> |
> |
> | did you use --enable-rewrite? i.e. are you using the specific rewrite
> | library or the naive string replace?  This may be one point.  I remember
> | that recently there was a similar issue with 2.2, which apparently
> didn't
> | touch 2.1 but in case... moreover, are you using attribute mapping in
> | back-ldap?  Any other special feature you're using?
> [snip]
>
> We've got a SPEC file that we use to build:
>
> %configure \
> ~         --with-tls \
> ~         --with-cyrus-sasl \
> ~         \
> ~         --enable-crypt \
> ~         \
> ~         --enable-ldap \
> ~         --libexecdir=%{_sbindir} \
> ~         --localstatedir=/%{_var}/run
>
> You told me in
> http://www.openldap.org/lists/openldap-software/200403/msg00700.html
> that I could either go with >2.1.27 or recompile with --enable-rewrite.
> ~  If I should add "--enable-rewrite", I will.

As far as I remember, the issue that caused that problem has been fixed
for both full rewrite and naming context replacement; if you don't mind,
I'd give it a try, just in case.

>
> Here's the o=WFU,c=US section, in case it helps:
>
> # the 'fake' database, for legacy clients
> database        ldap
> suffix          "o=WFU,c=US"
> uri             ldap://localhost
> suffixmassage   o=WFU,c=US      ou=Users,dc=wfu,dc=edu

OK, I don't see any issue.  It would be helpful if you could narrow the
problem down, e.g. by running slapd with full debug (and truncating the
file every now and then by "cat /dev/null >/log/file", for your
filesystem's relief) or by running the built but yet to install version of
slapd under gdb.  You could also run one database on one machine and one
on another (or on the same machine on different ports) to find out what is
actually crashing (or if it's the interaction of the two that causes the
problem).

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497