Your message dated Mon, 12 May 2014 19:54:53 -0700
with message-id <[email protected]>
and subject line appears fixed in squeeze and later
has caused the Debian Bug report #568711,
regarding slapd: replication : consumer crashes due to assertion failure when
replication starts the first time
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
568711: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568711
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: slapd
Version: 2.4.11-1+lenny1
Severity: important
Hi everyone,
When using ldap with syncrepl and a particular configuration, a consumer
crashes the first time the replication starts on an "empty" database, with
accesslog and logold enabled on the consumer server.
Here are relevant part of the provider's configuration :
------
serverID 000
database hdb
# The base of your directory in database #1
suffix "dc=domain,dc=com"
# Where the database file are physically stored for database #1
directory "/var/lib/ldap/domain"
na
# Log configuration
overlay accesslog
logdb "cn=accesslog"
logops writes
logold (objectclass=*)
logpurge 4+00:00 1+00:00
# Replication
overlay syncprov
syncprov-checkpoint 100 10
------
And relevant part of the consumer's configuration :
--------
database hdb
# The base of your directory in database #1
suffix "dc=domain,dc=com"
# Where the database file are physically stored for database #1
directory "/var/lib/ldap/domain"
syncrepl rid=000
provider=ldaps://ldap-master.xxxx/
type=refreshAndPersist
retry="5 5 300 +"
searchbase="ou=xxxxx,dc=domain,dc=com"
attrs="*,+"
bindmethod=simple
binddn="cn=xxxxxxx,dc=nautile,dc=nc"
credentials=xxxxxxxxxx
# Log configuration
overlay accesslog
logdb "cn=accesslog"
logops writes
logold (objectclass=*)
logpurge 4+00:00 1+00:00
---------
At the beggining, a slapcat on the consumer gives :
dn: dc=domain,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: domain
dc: domain
structuralObjectClass: organization
dn: ou=xxxx,dc=domain,dc=com
objectClass: organizationalUnit
objectClass: top
ou: xxxx
With the above configurations and the consumer initialized with this LDIF,
slapd (on the consumer) crashes :
# gdb --args /usr/sbin/slapd -g openldap -u openldap -d sync
[...]
slapd: /tmp/buildd/openldap-2.4.11/servers/slapd/schema_check.c:88:
entry_schema_check: Assertion `a->a_vals[0].bv_val != ((void *)0)' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xa284bb90 (LWP 8270)]
0xb7c00556 in raise () from /lib/libc.so.6
(gdb) bt
#0 0xb7c00556 in raise () from /lib/libc.so.6
#1 0xb7c01d78 in abort () from /lib/libc.so.6
#2 0xb7bf9590 in __assert_fail () from /lib/libc.so.6
#3 0x080ac2ec in entry_schema_check (op=0xa284a040, e=0x8c7a15c, oldattrs=0x0,
manage=0, add=1, text=0xa284a12c,
textbuf=0xa2849e58 "x\236\204�\005\227��@\234�\b\224�÷2", textlen=256) at
/tmp/buildd/openldap-2.4.11/servers/slapd/schema_check.c:88
#4 0xb782d253 in hdb_add (op=0xa284a040, rs=0xa284a118) at add.c:97
#5 0xb781c96d in accesslog_response (op=0xa284ada0, rs=0xa284a898) at
/tmp/buildd/openldap-2.4.11/servers/slapd/overlays/accesslog.c:1650
#6 0x080db50f in over_back_response (op=0xa284ada0, rs=0xa284a898) at
/tmp/buildd/openldap-2.4.11/servers/slapd/backover.c:235
#7 0x08086596 in slap_response_play (op=0xa284ada0, rs=0xa284a898) at
/tmp/buildd/openldap-2.4.11/servers/slapd/result.c:307
#8 0x08089448 in send_ldap_response (op=0xa284ada0, rs=0x6) at
/tmp/buildd/openldap-2.4.11/servers/slapd/result.c:381
#9 0x0808a266 in slap_send_ldap_result (op=0xa284ada0, rs=0xa284a898) at
/tmp/buildd/openldap-2.4.11/servers/slapd/result.c:642
#10 0xb7831f76 in hdb_modify (op=0xa284ada0, rs=0xa284a898) at modify.c:697
#11 0x080db73c in overlay_op_walk (op=0xa284ada0, rs=0xa284a898,
which=op_modify, oi=0x8bdddd8, on=0x8c20e20)
at /tmp/buildd/openldap-2.4.11/servers/slapd/backover.c:646
#12 0x080dc205 in over_op_func (op=0xa284ada0, rs=0xa284a898, which=op_modify)
at /tmp/buildd/openldap-2.4.11/servers/slapd/backover.c:698
#13 0x080d0df2 in syncrepl_updateCookie (si=0x8c208d8, op=0xa284ada0,
pdn=<value optimized out>, syncCookie=0xa284ac50)
at /tmp/buildd/openldap-2.4.11/servers/slapd/syncrepl.c:2803
#14 0x080d7092 in do_syncrep2 (op=0xa284ada0, si=0x8c208d8) at
/tmp/buildd/openldap-2.4.11/servers/slapd/syncrepl.c:1119
#15 0x080d88a2 in do_syncrepl (ctx=0xa284b248, arg=0x8c20c78) at
/tmp/buildd/openldap-2.4.11/servers/slapd/syncrepl.c:1293
#16 0x0807703b in connection_read_thread (ctx=0xa284b248, argv=0x15) at
/tmp/buildd/openldap-2.4.11/servers/slapd/connection.c:1213
#17 0xb7f9afb8 in ?? () from /usr/lib/libldap_r-2.4.so.2
#18 0xa284b248 in ?? ()
#19 0x00000015 in ?? ()
#20 0x00000000 in ?? ()
(gdb) frame 3
#3 0x080ac2ec in entry_schema_check (op=0xa284a040, e=0x8c7a15c, oldattrs=0x0,
manage=0, add=1, text=0xa284a12c,
textbuf=0xa2849e58 "x\236\204�\005\227��@\234�\b\224�÷2", textlen=256) at
/tmp/buildd/openldap-2.4.11/servers/slapd/schema_check.c:88
88 assert( a->a_vals[0].bv_val != NULL );
(gdb) p a->a_desc->ad_cname->bv_val
$1 = 0x8c19368 "reqOld"
(gdb) p a->a_desc->ad_type->sat_cname->bv_val
$2 = 0x8c19368 "reqOld"
I think that slapd crashes because it doesn't find an "old value" for the
accesslog.
As a workaround, if the line "logold (objectclass=*)" is commented on the
consumer, slapd runs fine the first time. Then, when the first synchronisation
is finished, this line can be uncommented, and everything runs fine (even when
objects are created on the provider, and replicated on the consumer).
I'd be happy to provide more informations on this if needed.
Cheers.
-- System Information:
Debian Release: 5.0.4
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-xen-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages slapd depends on:
ii adduser 3.110 add and remove users and groups
ii coreutils 6.10-6 The GNU core utilities
ii debconf [debconf- 1.5.24 Debian configuration management sy
ii libc6 2.7-18lenny2 GNU C Library: Shared libraries
ii libdb4.2 4.2.52+dfsg-5 Berkeley v4.2 Database Libraries [
ii libgnutls26 2.4.2-6+lenny2 the GNU TLS library - runtime libr
ii libldap-2.4-2 2.4.11-1+lenny1 OpenLDAP libraries
ii libltdl3 1.5.26-4+lenny1 A system independent dlopen wrappe
ii libperl5.10 5.10.0-19lenny2 Shared Perl library
ii libsasl2-2 2.1.22.dfsg1-23+lenny1 Cyrus SASL - authentication abstra
ii libslp1 1.2.1-7.5 OpenSLP libraries
ii libwrap0 7.6.q-16 Wietse Venema's TCP wrappers libra
ii perl [libmime-bas 5.10.0-19lenny2 Larry Wall's Practical Extraction
ii psmisc 22.6-1 Utilities that use the proc filesy
ii unixodbc 2.2.11-16 ODBC tools libraries
Versions of packages slapd recommends:
ii libsasl2-modules 2.1.22.dfsg1-23+lenny1 Cyrus SASL - pluggable authenticat
Versions of packages slapd suggests:
ii ldap-utils 2.4.11-1+lenny1 OpenLDAP utilities
-- debconf information:
slapd/allow_ldap_v2: false
slapd/tlsciphersuite:
slapd/password_mismatch:
slapd/invalid_config: true
slapd/upgrade_slapcat_failure:
slapd/slurpd_obsolete:
slapd/no_configuration: false
slapd/move_old_database: true
slapd/suffix_change: false
slapd/dump_database_destdir: /var/backups/slapd-VERSION
slapd/purge_database: false
slapd/backend: HDB
slapd/dump_database: when needed
--- End Message ---
--- Begin Message ---
Hi Adrien,
On 10/04/14 08:01 PM, Ryan Tandy wrote:
I can't reproduce this bug, neither with slapd 2.4.31 from wheezy nor
with 2.4.39 from sid. I was careful to include the logold line that
you said caused your crash.
I've now been all the way back to lenny, and using the configuration you
provided, I was able to reproduce the crash in that release. The same
config doesn't crash in squeeze or later, so I think we can call this
bug fixed.
thanks,
Ryan
--- End Message ---
