(ITS#7182) back-ldap monitoring improvements
by ondrej.kuznik＠acision.com
Full_Name: Ondrej Kuznik
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120228-back-ldap-monitori...
Submission from: (NULL) (62.168.56.1)
I have prepared some patches to back-ldap (and one to back-monitor) that expose
operation and connection monitoring information from a running back-ldap
database and I would like to see this or similar functionality included in the
OpenLDAP codebase.
The url above contains a patchset against HEAD for review.
The following things are yet to be resolved:
- there is no monitoring of completed operations yet, only operations initiated
against the remote database(s).
- the binds performed by the ldap_back_default_rebind function are not counted
- slapo-chain has not been tested yet
- test suite integration: back-ldap looks excluded from the test suite
- better connection handling (connections should have stable identifiers)
The obligatory license clause follows:
The attached file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following
patch(es) were developed by Acision. Acision has not assigned rights
and/or interest in this work to any party. I, Ondrej Kuznik am
authorized by Acision, my employer, to release this work under the
following terms.
The attached modifications to OpenLDAP Software are subject to the
following notice:
Copyright 2012 Acision
Redistribution and use in source and binary forms, with or without
modification, are permitted only as authorized by the OpenLDAP Public
License.
11 years, 3 months
RE: (ITS#7102) slapd segfaults on slapo-dds refresh with syncprov enabled
by Petteri.Stenius＠ubisecure.com
Hello,
I run into this same issue. However the segfault only happens if the dds
overlay is defined before the syncprov overlay in slapd.conf.
Br,
Petteri Stenius
-----Original Message-----
From: openldap-bugs-bounces(a)OpenLDAP.org
[mailto:openldap-bugs-bounces@OpenLDAP.org] On Behalf Of
dieter(a)dkluenter.de
Sent: 30. marraskuuta 2011 12:12
To: openldap-its(a)openldap.org
Subject: (ITS#7102) slapd segfaults on slapo-dds refresh with syncprov
enabled
Full_Name: Dieter Kluenter
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (141.38.5.243)
slapd crashes with segmentation fault on a slapo-dds refresh operation,
if
syncprov is enabled and configured
(gdb) bt
#0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530,
maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59
#1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at syncprov.c:1793
#2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at result.c:505
#3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at result.c:580
#4 0x000000000045e292 in slap_send_ldap_extended (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at result.c:915
#5 0x000000000048aedb in fe_extended (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at
extended.c:237
#6 0x000000000048ab57 in do_extended (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at
extended.c:177
#7 0x0000000000446a15 in connection_operation (ctx=0x7f01e6a34b60,
arg_v=0x7f01d8013530) at connection.c:1138
#8 0x0000000000446fb3 in connection_read_thread (ctx=0x7f01e6a34b60,
argv=0x10)
at connection.c:1274
#9 0x00007f01f5929fc0 in ldap_int_thread_pool_wrapper (xpool=0x91d540)
at
tpool.c:685
#10 0x00007f01f48f0a3f in start_thread (arg=0x7f01e6a35700) at
pthread_create.c:297
#11 0x00007f01f3c1166d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#12 0x0000000000000000 in ?? ()
(gdb) frame 0
#0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530,
maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59
59 LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list,
ce_csn_link ) {
(gdb) frame 1
#1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at syncprov.c:1793
1793 slap_get_commit_csn( op, &maxcsn, &foundit );
(gdb) frame 2
#2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at result.c:505
505 rc = op->o_callback->sc_response( op, rs
);
(gdb) frame 3
#3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530,
rs=0x7f01e6a34a30) at result.c:580
580 rc = slap_response_play( op, rs );
(gdb)
-Dieter
11 years, 3 months
Re: (ITS#7181) off by 2 error in --ldif-wrap
by hyc＠symas.com
Hallvard B Furuseth wrote:
> On Sat, 25 Feb 2012 00:19:11 GMT, hyc(a)symas.com wrote:
>> h.b.furuseth(a)usit.uio.no wrote:
>>> The client option --ldif-wrap=N outputs lines of N+2 columns.
>>> E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output.
>>
>> Not a bug. See libldap/ldif.c:490.
>
> That's old an internal matter, exposed as default wrap width 78
> instead of rfc2849's max 76.
>
> This ITS is about the new --ldif-wrap option. The tools can just
> subtract 2 from the input value and otherwise keep the current code.
But then the tools will be wrong when we fix the library.
> (I do think we should throw away the old bug-compat code and
> fix the default 78 to 76, but not in RE24. And I note the bug-
> compat comment claims it's off by 1 while it's actually 2:)
Sure, I'd like to throw that all out too. But in the meantime, I'd rather not
have the tools' functionality change twice over the same issue. (I.e., fix the
tools now, then fix the libraries later and have to re-fix the tools.)
--
-- 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, 3 months
Re: (ITS#7181) off by 2 error in --ldif-wrap
by h.b.furuseth＠usit.uio.no
On Sat, 25 Feb 2012 00:19:11 GMT, hyc(a)symas.com wrote:
> h.b.furuseth(a)usit.uio.no wrote:
>> The client option --ldif-wrap=N outputs lines of N+2 columns.
>> E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output.
>
> Not a bug. See libldap/ldif.c:490.
That's old an internal matter, exposed as default wrap width 78
instead of rfc2849's max 76.
This ITS is about the new --ldif-wrap option. The tools can just
subtract 2 from the input value and otherwise keep the current code.
(I do think we should throw away the old bug-compat code and
fix the default 78 to 76, but not in RE24. And I note the bug-
compat comment claims it's off by 1 while it's actually 2:)
--
Hallvard
11 years, 3 months
Re: (ITS#7180) libmdb assertion error on slapadd
by quanah＠zimbra.com
--On Thursday, February 23, 2012 5:42 PM +0000 quanah(a)OpenLDAP.org wrote:
>#################### 100.00% eta none elapsed none fast!
> slapadd: ../../../libraries/libmdb/mdb.c:3827: mdb_cursor_get: Assertion
> `mc' failed.
> Aborted
This is specifically triggered the flags used with slapadd:
/opt/zimbra/openldap/sbin/slapadd -q -w -b '' -F
/opt/zimbra/data/ldap/config -cv -l /tmp/ldap.bak
Specifically the "-w" flag is what triggers it. No error occurs without -w.
Thread 1 (Thread 0x7ffff7fef700 (LWP 25466)):
#0 0x00007ffff6372a75 in raise () from /lib/libc.so.6
No symbol table info available.
#1 0x00007ffff63765c0 in abort () from /lib/libc.so.6
No symbol table info available.
#2 0x00007ffff636b941 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#3 0x00007ffff38432d0 in mdb_cursor_get (mc=0x0, key=0x7ffff3a53eb0,
data=0x7ffff3a53ec0, op=MDB_SET) at ../../../libraries/libmdb/mdb.c:3827
rc = 1301783142
exact = 0
__PRETTY_FUNCTION__ = "mdb_cursor_get"
#4 0x00007ffff381c4db in mdb_tool_entry_get_int (be=0x8ff470, id=0,
ep=0x7fffffffe568) at tools.c:323
op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x0,
o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val =
0x0}, o_request = {oq_add = {
rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0,
rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0},
rb_ssf = 0, rb_mech = {bv_len = 0,
bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify =
{rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_increment = 0},
oq_modrdn = {rs_mods = {
rs_modlist = 0x0, rs_no_opattrs = 0 '\000'},
rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn =
{bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0,
rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0,
rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs =
0x0, rs_filter = 0x0, rs_filterstr = {
bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0},
oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val
= 0x0}, rs_flags = 0,
rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid =
{bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old =
{bv_len = 0, bv_val = 0x0}, rs_new = {
bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail =
0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0
'\000', o_is_auth_check = 0 '\000',
o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching =
0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000',
o_no_subordinate_glue = 0 '\000',
o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_authz
= {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len
= 0, bv_val = 0x0}, sai_ndn = {
bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf =
0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0,
o_callback = 0x0, o_ctrls = 0x0, o_csn = {
bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra =
{slh_first = 0x0}, o_next = {stqe_next = 0x0}}
ohdr = {oh_opid = 0, oh_connid = 0, oh_conn = 0x0, oh_msgid = 0,
oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0,
oh_tmpmfuncs = 0x0, oh_counters = 0x0,
oh_log_prefix = '\000' <repeats 255 times>}
e = 0x0
dn = {bv_len = 0, bv_val = 0x0}
ndn = {bv_len = 0, bv_val = 0x0}
rc = 32767
__PRETTY_FUNCTION__ = "mdb_tool_entry_get_int"
#5 0x00007ffff381c72d in mdb_tool_entry_get (be=0x8ff470, id=0) at
tools.c:373
e = 0x0
#6 0x00000000004db69a in slap_tool_update_ctxcsn (progname=0x51a020
"slapadd", sid=18446744073709551615, bvtext=0x7fffffffe6c0) at
slapcommon.c:1004
ctxdn = {bv_len = 0, bv_val = 0x8d1c50 ""}
ctxcsn_id = 0
ctxcsn_e = 0x75ff68
rc = 0
__PRETTY_FUNCTION__ = "slap_tool_update_ctxcsn"
#7 0x00000000004d8ecb in slapadd (argc=10, argv=0x7fffffffea18) at
slapadd.c:472
textbuf = '\000' <repeats 255 times>
textlen = 256
erec = {e = 0x7ebf68, lineno = 2857, nextline = 2857}
bvtext = {bv_len = 256, bv_val = 0x7fffffffe700 ""}
thr = 0
id = 73
ldifrc = 0
rc = 0
stat_buf = {st_dev = 64256, st_ino = 1441881, st_nlink = 1, st_mode
= 33184, st_uid = 1001, st_gid = 1001, __pad0 = 0, st_rdev = 0, st_size =
115070, st_blksize = 4096,
st_blocks = 232, st_atim = {tv_sec = 1330122358, tv_nsec =
391982437}, st_mtim = {tv_sec = 1330122344, tv_nsec = 272000000}, st_ctim =
{tv_sec = 1330122346,
tv_nsec = 832002048}, __unused = {0, 0, 0}}
#8 0x0000000000415910 in main (argc=10, argv=0x7fffffffea18) at main.c:410
i = 0
no_detach = 0
rc = 1
urls = 0x0
username = 0x0
groupname = 0x0
sandbox = 0x0
syslogUser = 160
pid = 0
waitfds = {3817984, 0}
g_argc = 10
g_argv = 0x7fffffffea18
configfile = 0x0
configdir = 0x0
serverName = 0x7fffffffec9d "slapadd"
serverMode = 1
scp = 0x0
scp_entry = 0x0
debug_unknowns = 0x0
syslog_unknowns = 0x0
serverNamePrefix = 0x4f95e8 ""
l = 140737488349422
slapd_pid_file_unlink = 0
slapd_args_file_unlink = 0
firstopt = 1
__PRETTY_FUNCTION__ = "main"
(gdb)
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
11 years, 3 months
(ITS#7181) off by 2 error in --ldif-wrap
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: 2.4.29
OS: Linux x86_64
URL:
Submission from: (NULL) (195.1.106.125)
Submitted by: hallvard
The client option --ldif-wrap=N outputs lines of N+2 columns.
E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output.
11 years, 3 months
Re: (ITS#7177) [PATCH] various manpage fixes
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> On Thu, 23 Feb 2012 20:31:09 GMT, hyc(a)symas.com wrote:
>> It seems unnecessary to document ldif-wrap in all of the commands,
>> since only ldapsearch actually produces LDIF output.
>
> No, controls can also request LDIF output. E.g.
> ldapmodify -e preread -o ldif-wrap=20
> wraps after column... 22?? New ITS coming up.
>
OK, in that case I don't see any reason to tweak that part of the patch.
--
-- 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, 3 months
Re: (ITS#7177) [PATCH] various manpage fixes
by h.b.furuseth＠usit.uio.no
On Thu, 23 Feb 2012 20:31:09 GMT, hyc(a)symas.com wrote:
> It seems unnecessary to document ldif-wrap in all of the commands,
> since only ldapsearch actually produces LDIF output.
No, controls can also request LDIF output. E.g.
ldapmodify -e preread -o ldif-wrap=20
wraps after column... 22?? New ITS coming up.
--
Hallvard
11 years, 3 months
Re: (ITS#7177) [PATCH] various manpage fixes
by jvcelak＠redhat.com
> It seems unnecessary to document ldif-wrap in all of the commands,
> since only
> ldapsearch actually produces LDIF output. The option isn't relevant
> for any of
> the others.
I know. Feel free to modify the changes as you wish. I just wanted
to make the man page consistent across all tools, because the
description of "-o" displayed with "ldaptool --help" is always the
same.
Jan
11 years, 3 months
