(ITS#8146) Slapd with mdb consumes 100% CPU if deref aliases is requested
by andrew.findlay＠skills-1st.co.uk
Full_Name: Andrew Findlay
Version: 2.4.40
OS: Linux: OpenSuSE 13.2
URL: ftp://ftp.openldap.org/incoming/openldap-mdb-spin-bug.tgz
Submission from: (NULL) (2001:8b0:8d0:f7e1:61a6:169e:b4ba:9954)
Some client programs (such as Apache Directory Studio) request alias
dereferencing by default. This puts slapd with mdb into a spin where it consumes
100% of a CPU. Other threads continue to work and new connections are accepted.
Timeouts do not terminate the spin. Disconnecting the client does not terminate
the spin.
To reproduce: start slapd and issue a search of the form:
ldapsearch -a search -x -b dc=example,dc=org objectclass=person
I have placed a tarball on the FTP server containing:
slapd.conf
sample data in LDIF
gdb output showing thread trace after breaking in
script of client commands
The build options were:
CFLAGS=-g
export CFLAGS
./configure --prefix=/meme/andrew/test/openldap-2.4.40 \
--enable-spasswd \
--enable-crypt \
--enable-slapi \
--enable-overlays \
--enable-hdb=no \
--enable-bdb=no \
--enable-ldap \
--enable-rewrite \
--enable-meta \
--enable-null \
--enable-monitor \
--enable-relay \
--enable-sock \
--with-cyrus-sasl \
--with-tls
For those that need it, the workaround with Apache Directory Studio is to
disable alias dereferencing in the Browser Options tab for the connection.
Andrew
6 years, 8 months
Re: (ITS#8145) The olcThreadQueues config element is not documented
by elecharny＠gmail.com
Le 15/05/15 19:14, Howard Chu a écrit :
> Emmanuel Lécharny wrote:
>> Le 15/05/15 13:40, Howard Chu a écrit :
>>> elecharny(a)apache.org wrote:
>>>> Full_Name: Emmanuel L.charny
>>>> Version: 2.4.40
>>>> OS:
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (83.202.0.248)
>>>>
>>>>
>>>> The olcThreadQueues AttributeType is part of the olcGlobal
>>>> OvjectClass since
>>>> 2.4.36, where it's has been added.
>>>> A man slapd-config provides no information on this parameter.
>>>
>>> You're mistaken. The olcThreadQueues feature has not been included in
>>> any official 2.4 release, it is a 2.5 feature.
>>>
>> Sadly, I can't comment on an ITS. So here it is :
>>
>> "It may not be official, but it's present in the code base since 2.4.36,
>> it's also present as a MAY attribute in the olcGlobal ObjectClass.
>
> No. You misunderstand - it is *NOT* present in the 2.4 source tree. It
> has *never* been present in the 2.4 source tree.
>
It's present in HEAD, which I suppose is now the 2.5 branch :
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/...
The web browser is kind of confusing... And, no, it's not present in tag
2.4.40.
The ITS can be closed, sorry for the noise.
6 years, 8 months
Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com
--On Friday, May 15, 2015 7:45 PM +0000 quanah(a)zimbra.com wrote:
> --On Friday, May 15, 2015 8:39 PM +0100 Howard Chu <hyc(a)symas.com> wrote:
>
>> quanah(a)zimbra.com wrote:
>>> This is caused by modify ops:
>>>
>>> [zimbra@ldap02-dc01 xx]$ grep \(20\) /var/log/zimbra.log
>>> May 15 08:35:46 ldap02-dc01 slapd[18167]: syncrepl_message_to_op:
>>> rid=201 be_modify uid=xxx,ou=people,dc=xxx,dc=com (20)
>>
>> Multiple TYPE_OR_VALUE_EXISTS errors indicate you're sending a lot of
>> mods that were already performed. Sounds more like a serverID or URL
>> misconfig here if there are actually only 2 servers talking.
>
> ServerID's are unique (2 & 3). There is no URL portion to the config, as
> we're not replicating cn=config. In 6 days, the servers have gotten
> totally out of sync with one another, and REFRESH mode isn't fixing it
> either.
Note that the drift is occurring on an attribute that is multi-valued:
zimbraPasswordLockoutFailureTime
The values stored in the attribute are only granular down to the second, so
it's not uncommon for multiple writes of the same value (add/mod/delete) to
occur for this attribute.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
6 years, 8 months
Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com
--On Friday, May 15, 2015 8:39 PM +0100 Howard Chu <hyc(a)symas.com> wrote:
> quanah(a)zimbra.com wrote:
>> This is caused by modify ops:
>>
>> [zimbra@ldap02-dc01 xx]$ grep \(20\) /var/log/zimbra.log
>> May 15 08:35:46 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
>> be_modify uid=xxx,ou=people,dc=xxx,dc=com (20)
>
> Multiple TYPE_OR_VALUE_EXISTS errors indicate you're sending a lot of
> mods that were already performed. Sounds more like a serverID or URL
> misconfig here if there are actually only 2 servers talking.
ServerID's are unique (2 & 3). There is no URL portion to the config, as
we're not replicating cn=config. In 6 days, the servers have gotten
totally out of sync with one another, and REFRESH mode isn't fixing it
either.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
6 years, 8 months
Re: (ITS#8125) MMR throws away valid changes causing drift
by hyc＠symas.com
quanah(a)zimbra.com wrote:
> This is caused by modify ops:
>
> [zimbra@ldap02-dc01 xx]$ grep \(20\) /var/log/zimbra.log
> May 15 08:35:46 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
> be_modify uid=xxx,ou=people,dc=xxx,dc=com (20)
Multiple TYPE_OR_VALUE_EXISTS errors indicate you're sending a lot of mods
that were already performed. Sounds more like a serverID or URL misconfig here
if there are actually only 2 servers talking.
> May 15 08:47:44 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
> be_modify uid=xxx,ou=people,dc=yyy,dc=co,dc=za (20)
> May 15 08:56:03 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
> be_modify uid=xxx,ou=people,dc=zzz,dc=co,dc=za (20)
> May 15 09:31:12 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
> be_modify uid=xxx,ou=people,dc=www,dc=co,dc=za (20)
> May 15 10:46:58 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
> be_modify uid=xxx,ou=people,dc=ppp,dc=co,dc=za (20)
> May 15 13:44:11 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
> be_modify uid=xxx,ou=people,dc=rrr,dc=co,dc=za (20)
> May 15 14:54:49 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
> be_modify uid=xxx,ou=people,dc=zzz,dc=com (20)
> May 15 17:23:11 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
> be_modify uid=xxx,ou=people,dc=zzz,dc=com (20)
>
> So overall, there seems to be significant problems with RE24 in relation to
> replication at this time.
>
> Clocks are tightly in sync.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Platform Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 8 months
Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com
--On Friday, May 15, 2015 7:25 PM +0000 quanah(a)zimbra.com wrote:
> Clocks are tightly in sync.
Seeing tons of "greater than snapshot errors". 108 so far today on one
host, 144 on the other.
Example of one:
May 15 17:33:19 ldap01-dc01 slapd[31479]: Entry
uid=xxxx,ou=people,dc=yyyy,dc=co,dc=za CSN
20150515153317.592677Z#000000#002#000000 greater than snapshot
20150515153317.320608Z#000000#002#000000
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
6 years, 8 months
Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com
--On Monday, May 11, 2015 7:32 PM +0000 quanah(a)zimbra.com wrote:
> --On Friday, May 08, 2015 7:56 PM +0000 quanah(a)zimbra.com wrote:
>
>>
>>
>> --On May 4, 2015 at 8:00:45 PM +0000 openldap-its(a)OpenLDAP.org wrote:
>>
>>
>> In addition to the missing entries, multiple differences exist for
>> existing entries as well. At this point, it seems that replication with
>> 2.4.41 is entirely unsafe.
>
> The existing entry drift seems to be related to the locked up replication
> that occured because of a bug in openssl. So the real issue is just the
> entries that weren't created, which is a current known limitation of
> syncrepl refresh that needs fixing.
Unfortunately, I'm now seeing this at a second customer site with 2-node
MMR, where it is running current RE24 (2.4.41).
In this case:
ldap01 and ldap02 were stopped
openldap was upgraded from 2.4.39 to 2.4.41
ldap01's db was slapcat'd
ldap02's db was erased
ldap02's db was recreated from ldap01's slapcat
Now they are having drift, and constant refresh troubles:
[zimbra@ldap01-dc01 ~]$ grep REFRESH /var/log/zimbra.log
May 15 08:56:02 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515065528.000299Z,cn=accesslog), switching to
REFRESH
May 15 08:58:07 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201
LDAP_RES_INTERMEDIATE - REFRESH_DELETE
May 15 09:57:18 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515075718.000081Z,cn=accesslog), switching to
REFRESH
May 15 10:46:57 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515084653.000032Z,cn=accesslog), switching to
REFRESH
May 15 12:43:18 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515104318.000049Z,cn=accesslog), switching to
REFRESH
May 15 16:32:19 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515143211.000250Z,cn=accesslog), switching to
REFRESH
May 15 16:36:41 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515143556.000046Z,cn=accesslog), switching to
REFRESH
May 15 17:23:10 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515152310.000002Z,cn=accesslog), switching to
REFRESH
[zimbra@ldap02-dc01 xx]$ grep FRESH /var/log/zimbra.log
May 15 08:35:46 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515063539.000009Z,cn=accesslog), switching to
REFRESH
May 15 08:47:44 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515064733.000043Z,cn=accesslog), switching to
REFRESH
May 15 08:56:03 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515065528.000234Z,cn=accesslog), switching to
REFRESH
May 15 08:57:24 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201
LDAP_RES_INTERMEDIATE - REFRESH_DELETE
May 15 09:31:12 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515073112.000086Z,cn=accesslog), switching to
REFRESH
May 15 10:46:58 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515084653.000003Z,cn=accesslog), switching to
REFRESH
May 15 13:44:11 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515114405.000313Z,cn=accesslog), switching to
REFRESH
May 15 14:54:49 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515125448.000002Z,cn=accesslog), switching to
REFRESH
May 15 17:23:11 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync
lost sync on (reqStart=20150515152311.000035Z,cn=accesslog), switching to
REFRESH
This is caused by modify ops:
[zimbra@ldap02-dc01 xx]$ grep \(20\) /var/log/zimbra.log
May 15 08:35:46 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
be_modify uid=xxx,ou=people,dc=xxx,dc=com (20)
May 15 08:47:44 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
be_modify uid=xxx,ou=people,dc=yyy,dc=co,dc=za (20)
May 15 08:56:03 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
be_modify uid=xxx,ou=people,dc=zzz,dc=co,dc=za (20)
May 15 09:31:12 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
be_modify uid=xxx,ou=people,dc=www,dc=co,dc=za (20)
May 15 10:46:58 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
be_modify uid=xxx,ou=people,dc=ppp,dc=co,dc=za (20)
May 15 13:44:11 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
be_modify uid=xxx,ou=people,dc=rrr,dc=co,dc=za (20)
May 15 14:54:49 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
be_modify uid=xxx,ou=people,dc=zzz,dc=com (20)
May 15 17:23:11 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201
be_modify uid=xxx,ou=people,dc=zzz,dc=com (20)
So overall, there seems to be significant problems with RE24 in relation to
replication at this time.
Clocks are tightly in sync.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
6 years, 8 months
Re: (ITS#8145) The olcThreadQueues config element is not documented
by quanah＠zimbra.com
--On Friday, May 15, 2015 12:50 PM +0000 elecharny(a)gmail.com wrote:
> You migth object that the reference is what's in the man page, but then,
> how possibly can we detect missing parts in the documentation?"
You're either using a Symas or Zimbra openldap build to test against, both
of which backport 2.5 features not generally available in stock OpenLDAP
2.4.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
6 years, 8 months
Re: (ITS#8145) The olcThreadQueues config element is not documented
by hyc＠symas.com
Emmanuel Lécharny wrote:
> Le 15/05/15 13:40, Howard Chu a écrit :
>> elecharny(a)apache.org wrote:
>>> Full_Name: Emmanuel L.charny
>>> Version: 2.4.40
>>> OS:
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (83.202.0.248)
>>>
>>>
>>> The olcThreadQueues AttributeType is part of the olcGlobal
>>> OvjectClass since
>>> 2.4.36, where it's has been added.
>>> A man slapd-config provides no information on this parameter.
>>
>> You're mistaken. The olcThreadQueues feature has not been included in
>> any official 2.4 release, it is a 2.5 feature.
>>
> Sadly, I can't comment on an ITS. So here it is :
>
> "It may not be official, but it's present in the code base since 2.4.36,
> it's also present as a MAY attribute in the olcGlobal ObjectClass.
No. You misunderstand - it is *NOT* present in the 2.4 source tree. It has
*never* been present in the 2.4 source tree.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 8 months
Re: (ITS#8145) The olcThreadQueues config element is not documented
by elecharny＠gmail.com
Le 15/05/15 13:40, Howard Chu a écrit :
> elecharny(a)apache.org wrote:
>> Full_Name: Emmanuel L.charny
>> Version: 2.4.40
>> OS:
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (83.202.0.248)
>>
>>
>> The olcThreadQueues AttributeType is part of the olcGlobal
>> OvjectClass since
>> 2.4.36, where it's has been added.
>> A man slapd-config provides no information on this parameter.
>
> You're mistaken. The olcThreadQueues feature has not been included in
> any official 2.4 release, it is a 2.5 feature.
>
Sadly, I can't comment on an ITS. So here it is :
"It may not be official, but it's present in the code base since 2.4.36,
it's also present as a MAY attribute in the olcGlobal ObjectClass.
There is no way for me to know that it's a 2.5 feature, if it's in 2.4
branch, and if it's not documented as so. This is not really convenient,
as I'm basing the OpenLDAP configuration editor on the content of the
existing ObjectClasses.
You migth object that the reference is what's in the man page, but then,
how possibly can we detect missing parts in the documentation?"
6 years, 8 months