(ITS#6846) Deadlock in back-meta
by jorge.perez.burgos＠ericsson.com
Full_Name: Jorge Perez Burgos
Version: 2.4.15
OS: SLES 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.235.15.243)
There is a deadlock in back-meta code, the problem is that this thread get the
lock two times, the first is the one that show the trace, but previous in the
method meta_back_retry it has already the lock.
(gdb) bt
#0 0x00002b6e1a0706a8 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0
#1 0x00002b6e1a06c9fb in _L_mutex_lock_92 () from /lib64/libpthread.so.0
#2 0x00002b6e1a06c455 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00000000004eb715 in meta_back_bind_op_result (op=0x2aab35d80020,
rs=0x6eb6ad20, mc=0x2aab35e58be0,
candidate=4, msgid=1, sendok=<value optimized out>) at bind.c:388
#4 0x00000000004eba9f in meta_back_proxy_authz_bind (mc=0x2aab35e58be0,
candidate=4, op=0x2aab35d80020,
rs=0x6eb6ad20, sendok=LDAP_BACK_SENDERR) at bind.c:1534
#5 0x00000000004ebc21 in meta_back_single_dobind (op=0x2aab35d80020,
rs=0x6eb6ad20, mcp=0x6eb6a750, candidate=4,
sendok=LDAP_BACK_SENDERR, nretries=276864893, dolock=0) at bind.c:600
#6 0x00000000004f3c4f in meta_back_retry (op=0x2aab35d80020, rs=0x6eb6ad20,
mcp=0x6eb6a750, candidate=4,
sendok=LDAP_BACK_SENDERR) at conn.c:721
#7 0x00000000004e9ffc in meta_back_add (op=0x2aab35d80020, rs=0x6eb6ad20) at
add.c:184
#8 0x000000000044c196 in fe_op_add (op=0x2aab35d80020, rs=0x6eb6ad20) at
add.c:334
#9 0x00000000004a4832 in overlay_op_walk (op=0x2aab35d80020, rs=0x6eb6ad20,
which=op_add, oi=0x905850, on=0x0)
at backover.c:669
#10 0x00000000004a4db5 in over_op_func (op=0x2aab35d80020, rs=0x6eb6ad20,
which=op_add) at backover.c:721
#11 0x000000000044ca02 in do_add (op=0x2aab35d80020, rs=0x6eb6ad20) at
add.c:194
#12 0x0000000000445bab in connection_operation (ctx=0x6eb6ae70, arg_v=<value
optimized out>) at connection.c:1115
#13 0x0000000000446087 in connection_read_thread (ctx=0x6eb6ae70, argv=<value
optimized out>) at connection.c:1241
#14 0x000000000052398a in ldap_int_thread_pool_wrapper (xpool=0x788e70) at
tpool.c:663
#15 0x00002b6e1a06a193 in start_thread () from /lib64/libpthread.so.0
#16 0x00002b6e19814dfd in clone () from /lib64/libc.so.6
12 years, 3 months
(ITS#6845) sortvals oddities - with more information
by aweits＠rit.edu
Full_Name: Andrew Elble
Version: 2.4.24 / CVS Head
OS: Solaris / MacOS
URL:
Submission from: (NULL) (129.21.6.207)
We are using sortvals on both member and memberUid. We have been
seeing duplicate member/memberUid attributes on some objects that have
been modified (as well as a lack of sorting on those attributes). It
seemed that there was a correlation between modifies to objects that
experienced deadlocks and the objects that had duplicate
member/memberUid attributes on them. We put the seqmod overlay in
place - and this reduced the number of occurrences of the issue but
did not eliminate them.
Upon further investigation, I discovered that it was possible to
bypass the sorting behavior if the object was not created with an
instance of the attribute with sorting enabled as a part of it.
It would seem that attr_merge() (in attr.c) should have something like this:
if ( *a == NULL ) {
*a = attr_alloc( desc );
if (desc->ad_type->sat_flags & SLAP_AT_SORTED_VAL) {
(*a)->a_flags |= SLAP_ATTR_SORTED_VALS;
}
} else {
Further pursuing the issue, I started to focus on the index deletion
code that was changed as a part of ITS#5183. Specifically, the
portion of code within bdb_modify_internal() (in back-bdb/modify.c)
that is commented:
/* Move deleted values to end of array */
This code modifies save_attrs, which is actually apparently a pointer
to memory that resides within the cache. If a deadlock occurs, these
changes are not reverted, thereby corrupting the entry in the cache. I
replaced this code with the pre-ITS#5183 code and I am no longer able
to 'break' the object and insert duplicate member/memberUids.
I also found it surprising that the call to bdb_idl_cache_del() in
bdb_idl_delete_key() in back-bdb/idl.c occurred prior to any calls to
the database?
I can answer any questions about the specifics of the environment
in which where we are seeing this - it is a somewhat difficult problem to
reproduce outside of our production environment. I'm not terribly
familiar with the code - I'm looking to see if I have collected enough
data here to open an ITS to have this fixed. (or if I'm just way off base)
Thanks,
Andy
12 years, 3 months
(ITS#6844) AIX 6.1 | 7.1 not supported in "configure"
by joshua.taylor＠ubs.com
Full_Name: Joshua Taylor
Version: 2.4.24
OS: AIX 6.1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (193.134.254.26)
the configure script has no support for aix6* or aix7*, resulting in assuming no
shared libraries are supported. Simply going in after each reference to "aix5*"
and adding, " | aix6* | aix7* " enables shared library support.
Also, support for IA64 on aix is no more. I'm not even sure there was ever a
version that *actually* ran on IA64 cpus.
12 years, 3 months
Re: (ITS#6841) slapd segfault error 7
by quanah＠zimbra.com
--On Tuesday, February 22, 2011 10:54 AM +0000 tecnica(a)florasul.pt wrote:
> This is the output from strace -o slapd
strace is useless. Please have a core file generated, with debugging
symbols, and send the full backtrace.
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
12 years, 3 months
2.4.23 / Debian 6.0 i386: segfault at 811db38 ip 080c1e80 sp b2cf4b80 error 7 in slapd
by David Touzeau
Dear
We have an problem using
$OpenLDAP: slapd 2.4.23 (Nov 22 2010 23:39:34)
$#012#011@biber:/build/buildd-openldap_2.4.23-7-i386-mi96UQ/openldap-2.4.23/debian/build/servers/slapd
The same issue has been be replicated on 2.4.24
When we analyze the debug logs, the crash is performed each time we see
this line :
is_entry_objectclass("", "2.16.840.1.113730.3.2.6") no objectClass
attribute
How can we prevent this crash or fix it ?
here it is a piece of logs that detect the crash.
Feb 22 14:50:21 pm02 slapd[12126]: >>> dnPrettyNormal:
<cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com>
Feb 22 14:50:21 pm02 slapd[12126]: <<< dnPrettyNormal:
<cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com>,
<cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com>
Feb 22 14:50:21 pm02 slapd[12126]:
bdb_dn2entry("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com")
Feb 22 14:50:21 pm02 slapd[12126]: =>
hdb_dn2id("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com")
Feb 22 14:50:21 pm02 slapd[12126]: <= hdb_dn2id: get failed:
DB_NOTFOUND: No matching key/data pair found (-30988)
Feb 22 14:50:21 pm02 slapd[12126]: oc_check_required entry
(cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com), objectClass
"ArticaHostName"
Feb 22 14:50:21 pm02 slapd[12126]: oc_check_allowed type "objectClass"
Feb 22 14:50:21 pm02 slapd[12126]: oc_check_allowed type "cn"
Feb 22 14:50:21 pm02 slapd[12126]: oc_check_allowed type
"structuralObjectClass"
Feb 22 14:50:21 pm02 slapd[12126]:
bdb_dn2entry("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com")
Feb 22 14:50:21 pm02 slapd[12126]: =>
hdb_dn2id("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com")
Feb 22 14:50:21 pm02 slapd[12126]: <= hdb_dn2id: get failed:
DB_NOTFOUND: No matching key/data pair found (-30988)
Feb 22 14:50:21 pm02 slapd[12126]: is_entry_objectclass("",
"2.16.840.1.113730.3.2.6") no objectClass attribute
Feb 22 14:50:21 pm02 kernel: [13697.801217] slapd[13777]: segfault at
811db38 ip 080c1e80 sp b2cf4b80 error 7 in slapd[8048000+11b000]
best regards
12 years, 3 months
(ITS#6843) Can't slapadd cn=config LDIF with global chaining overlay
by rhafer＠suse.de
Full_Name: Ralf Haferkamp
Version: HEAD
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (89.166.251.8)
slapadd-ing the following LDIF (a stripped down slapcat output) fails:
-------------------------
dn: cn=config
objectClass: olcGlobal
cn: config
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcChainDatabase
objectClass: olcLDAPConfig
olcDatabase: {0}ldap
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
---------------------------------------
The error message is:
slapadd: could not add entry dn="olcDatabase={0}config,cn=config" (line=20):
Already exists
The problem is the olcChainDatabase Entry. As it appears before the
config-database entry config_tool_entry_put() will autocreate an
olcDatabase={0}config,cn=config and after that choke up when trying to add the
olcDatabase={0}config,cn=config that appears later in the LDIF file.
I have a fix for this mostly ready. (Just skipping autocreation of the
config-Database if child-entries of the frontendDatabase are added)
12 years, 3 months
Re: (ITS#6815) Feature Request: Accesslog filter
by andrew.findlay＠skills-1st.co.uk
On Wed, Feb 23, 2011 at 02:02:17PM +0000, hyc(a)symas.com wrote:
> > A URI-based restriction specification could include/exclude based on
> > suffix, filter and listed attributes with a unified syntax.
>
> Yes... But what does the filter *mean* in
> a modify op? filter on the target entry before it was modified, or after?
Hmm - I was thinking of matching on the *modified
attributes* (just their presence, not taking account of
value). However, I can see that pre- and post-conditions
might matter so:
logrecord <operations> prefilter|changefilter|postfilter <LDAP URL>
logignore <operations> prefilter|changefilter|postfilter <LDAP URL>
...
> a search op? match the search request's filter, or filter on the search base?
Both if present. Again, I might restrict the filter to
matching on the presence of attributes in the filter rather
than their actual value.
> a compare op?
Whatever works for search should be very close.
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
12 years, 3 months
Re: (ITS#6815) Feature Request: Accesslog filter
by andrew.findlay＠skills-1st.co.uk
On Wed, Feb 23, 2011 at 05:25:28AM -0800, Howard Chu wrote:
> >Extending this idea slightly, would it be possible to have
> >exclusions based on changes to specific attributes? The
> >particular case I have in mind is where accesslog is used to
> >keep a permanent audit log of changes, and ppolicy is also
> >in use, resulting in one audit entry for every login
> >failure. I have one site where a large proportion of the auditlog
> >entries are login failures...
>
> Perhaps in that case, it would be simpler just to set ppolicy's mods
> to be internal-only and bypass the accesslog overlay. (Currently it
> does this already, if the server is a single-master replica.)
There are all sorts of problems to do with ppolicy and replication...
Bypassing accesslog is an interesting idea, but I can see that people
who use n-failure-lockout might want the lockout events to be
auditable.
I wonder if there might be some benefit to giving such control on a
per-operation basis. Then ppolicy might be configurable to have some
automatic ops logged and others not. It could also be the start of a
way to make ppolicy actions rather more global across a replication
group (e.g. by putting in the ability to queue some ops for replication
back to a master server).
> So far you're talking about two different enhancements - the
> original poster is trying to exclude a set of searches, and you're
> talking about excluding modify ops. I'm not seeing any way yet to
> generalize from here such that all operation types are addressed
> meaningfully, and I don't want to introduce multiple special cases
> to the config language.
Rather than
logbase <operations> <baseDN>
how about
logfilter <operations> <LDAP URL>
where the whole clause may be repeated as many times as needed?
The LDAP URL can then specify a search base, a filter, and a list of
attributes of interest.
Extending this to support both inclusion and exclusion clauses might be
harder, as you would then need some way to give them an order of
precedence. The case I mentioned before would need a rule of the form
'dont log this op if the only change concerns the atttribute
pwdFailureTime'. Perhaps a simple list of rules:
logrecord <operations> <LDAP URL>
logignore <operations> <LDAP URL>
... and if anything is left at the end of the list then it gets logged.
The filters would determine whether a log entry would be made at all,
and the attribute lists would determine the content.
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
12 years, 3 months
Re: (ITS#6833) LDAP hangs on Solaris
by tombolala＠gmx.de
Hi!
Thanx for your reply. We have been able to reproduce the problem on a
test system and found out that setting "idletimeout" seems to fix this issue for us. Note that we enabled gentlehup!
We have now the new configuration on our production environment and everything seems stable. We are not able to change solaris versions.
If there are still problems we will upgrade the openldap version.
On another system we have the same ldap configuration (gentlehup and no idletimeout set) and do not experience any problem.
Best regards,
Thomas
-------- Original-Nachricht --------
> Datum: Wed, 23 Feb 2011 02:26:01 GMT
> Von: hyc(a)symas.com
> An: openldap-its(a)openldap.org
> Betreff: Re: (ITS#6833) LDAP hangs on Solaris
> tombolala(a)gmx.de wrote:
> > Hi Quanah!
> >
> > sorry for the wrong release, I meant 2.4.22 of course.
>
> I recall we also experienced hangs with Solaris 10 during the testing
> leading
> up to the 2.4.24 release. Yet with identical code, no such hangs were
> reported
> on Solaris 9 or Solaris 11. I suspect there's a bug in the implementation
> of
> select() on Solaris 10, causing it to fail to report the connection close
> events.
>
> Some discussion of this problem occurred in this email thread
>
> http://www.openldap.org/lists/openldap-devel/201101/msg00033.html
>
> Try 2.4.24, and try a different Solaris release. Aside from that, we have
> no
> answers for you.
>
> > /Thomas
> >
> > -------- Original-Nachricht --------
> >> Datum: Wed, 16 Feb 2011 16:34:39 GMT
> >> Von: quanah(a)zimbra.com
> >> An: openldap-its(a)openldap.org
> >> Betreff: Re: (ITS#6833) LDAP hangs on Solaris
> >
> >> --On Wednesday, February 16, 2011 11:37 AM +0000 tombolala(a)gmx.de
> wrote:
> >>
> >>> Full_Name: Thomas Bopp
> >>> Version: 4.2.22
> >>
> >>> I really need a solution for this problem.
> >>
> >> I suggest you list an actual OpenLDAP release. It's near impossible to
> >> help you without that.
> >>
> >> --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
> >>
> >>
> >
>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
>
--
Schon gehört? GMX hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://www.gmx.net/de/go/toolbar
12 years, 3 months
Re: (ITS#6815) Feature Request: Accesslog filter
by hyc＠symas.com
masarati(a)aero.polimi.it wrote:
> hyc(a)symas.com wrote:
>> Andrew Findlay wrote:
>>> On Wed, Feb 23, 2011 at 08:58:33AM +0000, hyc(a)symas.com wrote:
>>>
>>>> Possibly we can extend the directive to handle exclusion as well as inclusion,
>>>> to simplify this case.
>>> Extending this idea slightly, would it be possible to have
>>> exclusions based on changes to specific attributes? The
>>> particular case I have in mind is where accesslog is used to
>>> keep a permanent audit log of changes, and ppolicy is also
>>> in use, resulting in one audit entry for every login
>>> failure. I have one site where a large proportion of the auditlog
>>> entries are login failures...
>>
>> Perhaps in that case, it would be simpler just to set ppolicy's mods to be
>> internal-only and bypass the accesslog overlay. (Currently it does this
>> already, if the server is a single-master replica.)
>>
>> So far you're talking about two different enhancements - the original poster
>> is trying to exclude a set of searches, and you're talking about excluding
>> modify ops. I'm not seeing any way yet to generalize from here such that all
>> operation types are addressed meaningfully, and I don't want to introduce
>> multiple special cases to the config language.
>
> A URI-based restriction specification could include/exclude based on
> suffix, filter and listed attributes with a unified syntax.
Yes... But what does the filter *mean* in
a modify op? filter on the target entry before it was modified, or after?
a search op? match the search request's filter, or filter on the search base?
a compare op?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 3 months
