Re: (ITS#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hyc＠symas.com
Marc Patermann wrote:
> Howard,
>
> Howard Chu schrieb (01.11.2011 18:39 Uhr):
>
>> Also, this script just performs sync searches, what do you use to
>> generate the writes?
> you mean the write which kills the server?
> It just one simple mod of an object which I made in Apache Directory Studio.
I'm unable to reproduce this crash. I have your slapd.conf and test data, I
have run 80-some instances of your script as you've described. While the
initial sync search is running I perform a modify of the base entry of the
subordinate database. Everything continues to run. I've also waited for all of
the initial refresh traffic to finish first, and then perform the modify, and
still no crash.
To be more clear - do you perform your modify while the sync searches are
still refreshing, or after all of the refreshes have completed?
Do you run the clients on the same host as slapd, or on a remote machine?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com
hyc(a)symas.com wrote:
> Michael Ströder wrote:
>> Howard Chu wrote:
>>> What git commit ID?
>>
>> As said in former times: Before reporting an ITS I *always* do git pull
>> checking whether there was something committed after the tested build. If
>> there was a new commit I always retest.
>
> Please just answer the questions. Bear in mind that there is a propagation
> delay between the writable git-master and the public mirror.
fe1659fc5b01530401174cef3f381ce56918476f
Ciao, Michael.
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by hyc＠symas.com
Michael Ströder wrote:
> Howard Chu wrote:
>> What git commit ID?
>
> As said in former times: Before reporting an ITS I *always* do git pull
> checking whether there was something committed after the tested build. If
> there was a new commit I always retest.
Please just answer the questions. Bear in mind that there is a propagation
delay between the writable git-master and the public mirror.
I always have good reasons for asking for the information that I ask for.
Second-guessing me is not going to get problems solved faster.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 10 months
Re: (ITS#7085) mutex lockup issue
by hayashis＠indiana.edu
--0015174c117a5169be04b1e058e5
Content-Type: text/plain; charset=ISO-8859-1
Quanah,
We have compiled OpenLDAP 2.4.26 with BDB 5.2.36. The OpenLDAP locked up 4
hours into our testing in similar manner to what I have reported earlier. I
believe this issue still occurs on the latest version.
However, when I used gdb, I didn't notice the mutex locked threads like I
did with OpenLDAP 2.4.22.
Following is from locked 2.4.26 slapd server.
(gdb) info thread
14 Thread 0x418dd940 (LWP 13814) 0x00000037aa4d48a8 in epoll_wait ()
from /lib64/libc.so.6
13 Thread 0x420de940 (LWP 13815) 0x00000037aac0aee9 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
12 Thread 0x428df940 (LWP 13816) 0x00000037aac0aee9 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
11 Thread 0x430e0940 (LWP 13843) 0x00000037aac0aee9 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
10 Thread 0x438e1940 (LWP 13855) 0x00000037aac0aee9 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
9 Thread 0x440e2940 (LWP 13856) 0x00000037aac0aee9 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
8 Thread 0x448e3940 (LWP 13857) 0x00000037aac0aee9 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
7 Thread 0x450e4940 (LWP 13858) 0x00000037aac0aee9 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
6 Thread 0x458e5940 (LWP 13859) 0x00000037aac0aee9 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
5 Thread 0x460e6940 (LWP 13860) 0x00000037aac0aee9 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
4 Thread 0x468e7940 (LWP 2007) 0x00000037aac0aee9 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
3 Thread 0x470e8940 (LWP 2008) 0x00000037aa4cd722 in select () from
/lib64/libc.so.6
2 Thread 0x478e9940 (LWP 2009) 0x00000037aac0aee9 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
* 1 Thread 0x2ac6ccfdc930 (LWP 13805) 0x00000037aac07b35 in pthread_join
() from /lib64/libpthread.so.0
(gdb) thread 3
[Switching to thread 3 (Thread 0x470e8940 (LWP 2008))]#0
0x00000037aa4cd722 in select () from /lib64/libc.so.6
(gdb) bt
#0 0x00000037aa4cd722 in select () from /lib64/libc.so.6
#1 0x000000000054ece5 in ?? ()
#2 0x000000000054aa15 in ?? ()
#3 0x0000000000557637 in ?? ()
#4 0x0000000000557c11 in ?? ()
#5 0x00000000004b2d93 in ?? ()
#6 0x00000000004e9d7c in ?? ()
#7 0x00000037aac0673d in start_thread () from /lib64/libpthread.so.0
#8 0x00000037aa4d44bd in clone () from /lib64/libc.so.6
It looks like it's waiting on select() on thread 3 which never get fired
when I access it using ldapsearch command.
I ran strace on ldapsearch (on a client machine) and following is what I
see at the end of the log..
$ strace ldapsearch -h 129.79.14.152 -p 2180 -l 3 -x -b
mds-vo-name=WT2,o=grid
"(&(objectClass=GlueLocation)(GlueLocationName=TIMESTAMP))"
....
write(1, "\n", 1
) = 1
write(3, "0l\2\1\2cg\4\26mds-vo-name=WT2,o=grid\n"..., 110) = 110
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1
Not sure if this strace is useful or not.. but after this, ldapsearch never
returned.
Thanks,
Soichi
On Wed, Nov 9, 2011 at 1:13 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote:
> --On Wednesday, November 09, 2011 2:01 PM +0000 hayashis(a)indiana.eduwrote:
>
> Full_Name: Soichi Hayashi
>> Version: 2.4.22
>>
>
> OpenLDAP 2.4.22 is quite old, and had various known issues. Please use a
> current release (2.4.26). This report will not be investigated unless you
> can reproduce it with a current release of OpenLDAP. You also fail to note
> what BDB release you are using, and whether or not it has all the relevant
> patches applied to it. If you have a broken policy of only using vendor
> provided packages, then you will need to send a bug report to RedHat, as it
> is their job to maintain their vendor packages.
>
>
> Thanks!
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
--0015174c117a5169be04b1e058e5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Quanah,</div><div><br></div><div>We have compiled OpenLDAP 2.4.26 with=
BDB 5.2.36. The OpenLDAP locked up 4 hours into our testing in similar man=
ner to what I have reported earlier. I believe this issue still occurs on t=
he latest version.</div>
<div><br></div><div>However, when I used gdb, I didn't notice the mutex=
locked threads like I did with OpenLDAP 2.4.22.</div><div><br></div><div>F=
ollowing is from locked 2.4.26 slapd server.</div><div><br></div><div>(gdb)=
info thread</div>
<div>=A0 14 Thread 0x418dd940 (LWP 13814) =A00x00000037aa4d48a8 in epoll_wa=
it () from /lib64/libc.so.6</div><div>=A0 13 Thread 0x420de940 (LWP 13815) =
=A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libp=
thread.so.0</div>
<div>=A0 12 Thread 0x428df940 (LWP 13816) =A00x00000037aac0aee9 in pthread_=
cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 11 Thre=
ad 0x430e0940 (LWP 13843) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC=
_2.3.2 () from /lib64/libpthread.so.0</div>
<div>=A0 10 Thread 0x438e1940 (LWP 13855) =A00x00000037aac0aee9 in pthread_=
cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 9 Threa=
d 0x440e2940 (LWP 13856) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_=
2.3.2 () from /lib64/libpthread.so.0</div>
<div>=A0 8 Thread 0x448e3940 (LWP 13857) =A00x00000037aac0aee9 in pthread_c=
ond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 7 Thread=
0x450e4940 (LWP 13858) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2=
.3.2 () from /lib64/libpthread.so.0</div>
<div>=A0 6 Thread 0x458e5940 (LWP 13859) =A00x00000037aac0aee9 in pthread_c=
ond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 5 Thread=
0x460e6940 (LWP 13860) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2=
.3.2 () from /lib64/libpthread.so.0</div>
<div>=A0 4 Thread 0x468e7940 (LWP 2007) =A00x00000037aac0aee9 in pthread_co=
nd_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 3 Thread =
0x470e8940 (LWP 2008) =A00x00000037aa4cd722 in select () from /lib64/libc.s=
o.6</div>
<div>=A0 2 Thread 0x478e9940 (LWP 2009) =A00x00000037aac0aee9 in pthread_co=
nd_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>* 1 Thread 0x=
2ac6ccfdc930 (LWP 13805) =A00x00000037aac07b35 in pthread_join () from /lib=
64/libpthread.so.0</div>
<div>(gdb) thread 3</div><div>[Switching to thread 3 (Thread 0x470e8940 (LW=
P 2008))]#0 =A00x00000037aa4cd722 in select () from /lib64/libc.so.6</div><=
div>(gdb) bt</div><div>#0 =A00x00000037aa4cd722 in select () from /lib64/li=
bc.so.6</div>
<div>#1 =A00x000000000054ece5 in ?? ()</div><div>#2 =A00x000000000054aa15 i=
n ?? ()</div><div>#3 =A00x0000000000557637 in ?? ()</div><div>#4 =A00x00000=
00000557c11 in ?? ()</div><div>#5 =A00x00000000004b2d93 in ?? ()</div><div>=
#6 =A00x00000000004e9d7c in ?? ()</div>
<div>#7 =A00x00000037aac0673d in start_thread () from /lib64/libpthread.so.=
0</div><div>#8 =A00x00000037aa4d44bd in clone () from /lib64/libc.so.6</div=
><div><br></div><div>It looks like it's waiting on select() on thread 3=
which never get fired when I access it using ldapsearch command.=A0</div>
<div><br></div><div>I ran strace on ldapsearch (on a client machine) and fo=
llowing is what I see at the end of the log..</div><div><br></div><div>$ st=
race ldapsearch -h 129.79.14.152 -p 2180 -l 3 -x -b mds-vo-name=3DWT2,o=3Dg=
rid "(&(objectClass=3DGlueLocation)(GlueLocationName=3DTIMESTAMP))=
"</div>
<div><br></div><div>....</div><div>write(1, "\n", 1</div><div>) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 1</div><div>write(3, "=
0l\2\1\2cg\4\26mds-vo-name=3DWT2,o=3Dgrid\n"..., 110) =3D 110</div><di=
v>poll([{fd=3D3, events=3DPOLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1</div>
<div><br></div><div>Not sure if this strace is useful or not.. but after th=
is, ldapsearch never returned.</div><div><br></div><div>Thanks,</div><div>S=
oichi</div><div><br></div><br><div class=3D"gmail_quote">On Wed, Nov 9, 201=
1 at 1:13 PM, Quanah Gibson-Mount <span dir=3D"ltr"><<a href=3D"mailto:q=
uanah(a)zimbra.com">quanah(a)zimbra.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">--On Wednesday, November 09, 2011 2:01 PM +=
0000 <a href=3D"mailto:hayashis@indiana.edu" target=3D"_blank">hayashis@ind=
iana.edu</a> wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Full_Name: Soichi Hayashi<br>
Version: 2.4.22<br>
</blockquote>
<br>
OpenLDAP 2.4.22 is quite old, and had various known issues. =A0Please use a=
current release (2.4.26). =A0This report will not be investigated unless y=
ou can reproduce it with a current release of OpenLDAP. =A0You also fail to=
note what BDB release you are using, and whether or not it has all the rel=
evant patches applied to it. =A0If you have a broken policy of only using v=
endor provided packages, then you will need to send a bug report to RedHat,=
as it is their job to maintain their vendor packages.<br>
<br>
<br>
Thanks!<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
--Quanah<br>
<br>
--<br>
<br>
Quanah Gibson-Mount<br>
Sr. Member of Technical Staff<br>
Zimbra, Inc<br>
A Division of VMware, Inc.<br>
--------------------<br>
Zimbra :: =A0the leader in open source messaging and collaboration<br>
</font></span></blockquote></div><br>
--0015174c117a5169be04b1e058e5--
11 years, 10 months
(ITS#7091) Limit ppolicy_forward_updates
by michael＠stroeder.com
Full_Name: Michael Ströder
Version: not relevant
OS: not relevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.163.25.215)
This is a feature request:
It should be possible to limit effect of ppolicy_forward_updates to certain
events like. Maybe just a list of attributes which should be forwarded to a
provider.
Rationale: To reduce the load on the provide one might want to only forward
lockouts to the provider and not each login failure.
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com
Howard Chu wrote:
> What git commit ID?
As said in former times: Before reporting an ITS I *always* do git pull
checking whether there was something committed after the tested build. If
there was a new commit I always retest.
Ciao, Michael.
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com
hyc(a)symas.com wrote:
>> slapcat with back-mdb mixes entry data in the LDIF output. The entry affected
>> had a DN of another entry while retrieving the same entry via LDAP worked
>> correctly. I observed this for one entry of several hundred entries.
>>
>> I currently can't provide test data because this was my private address book
>> data. But it was reproducable with slapadd-ed data from an older clean backup
>> LDIF file. The last correct backup file I have slapcating with back-mdb is of
>> 2011-11-12. I'm building RE24 almost daily from git. Maybe something bad
>> happened at that time.
>>
>> Will try to reproduce with other data but be warned to keep an eye on that.
>
> What platform, what version, 32 or 64 bit? What git commit ID?
openSUSE Linux 11.4 x86_64
> If you revert
> the code to an older commit, does it produce the same result?
I know that such a report is not sufficient for you to start fixing it. But
sometimes it's not possible to report it more precisely. As said I will try to
reproduce with non-private data. It was too late to do more testing yesterday.
> I've slapcat'd a 5 million entry back-hdb database and loaded it into
> back-mdb. Then slapcat'd that result; it is exactly identical to the original.
> Using both RE24 pulled a couple minutes ago, and git master built November
> 1st. There have been no functional changes to the code in a while, purely
> cosmetic changes.
Maybe it's dependent on the sort of data? The errornous entry contains
attribute jpegPhoto of size 7317 bytes.
Ciao, Michael.
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by hyc＠symas.com
michael(a)stroeder.com wrote:
> Full_Name: Michael Ströder
> Version: RE24 pulled from git
> OS:
> URL:
> Submission from: (NULL) (84.163.26.40)
>
>
> slapcat with back-mdb mixes entry data in the LDIF output. The entry affected
> had a DN of another entry while retrieving the same entry via LDAP worked
> correctly. I observed this for one entry of several hundred entries.
>
> I currently can't provide test data because this was my private address book
> data. But it was reproducable with slapadd-ed data from an older clean backup
> LDIF file. The last correct backup file I have slapcating with back-mdb is of
> 2011-11-12. I'm building RE24 almost daily from git. Maybe something bad
> happened at that time.
>
> Will try to reproduce with other data but be warned to keep an eye on that.
What platform, what version, 32 or 64 bit? What git commit ID? If you revert
the code to an older commit, does it produce the same result?
I've slapcat'd a 5 million entry back-hdb database and loaded it into
back-mdb. Then slapcat'd that result; it is exactly identical to the original.
Using both RE24 pulled a couple minutes ago, and git master built November
1st. There have been no functional changes to the code in a while, purely
cosmetic changes.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 10 months
(ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com
Full_Name: Michael Ströder
Version: RE24 pulled from git
OS:
URL:
Submission from: (NULL) (84.163.26.40)
slapcat with back-mdb mixes entry data in the LDIF output. The entry affected
had a DN of another entry while retrieving the same entry via LDAP worked
correctly. I observed this for one entry of several hundred entries.
I currently can't provide test data because this was my private address book
data. But it was reproducable with slapadd-ed data from an older clean backup
LDIF file. The last correct backup file I have slapcating with back-mdb is of
2011-11-12. I'm building RE24 almost daily from git. Maybe something bad
happened at that time.
Will try to reproduce with other data but be warned to keep an eye on that.
11 years, 10 months
Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by michael＠stroeder.com
noel(a)debian.org wrote:
> IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to DN's
> which don't have a userPassword attribute and cannot get one.
Hmm, this is somewhat debatable. I'm not sure. But I also don't see any harm
in the current behaviour. It's surely the client configuration which needs to
be fixed.
Ciao, Michael.
11 years, 10 months