openldap-bugs

openldap-bugs@openldap.org

20960 discussions

(ITS#8443) segfault in lmdb following mdb_env_set_mapsize
by gdochev＠yahoo.com 13 Jun '16

13 Jun '16

Full_Name: George Dochev Version: OS: Windows/OSX/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:582:4500:e134:1d59:965c:aecc:5697) I updated from 0.9.15 to 0.9.18 and started getting intermittent segfaults in one of my unit tests. In my test when I issue mdb_txn_commit and get back MDB_MAP_FULL I abort the transaction, expand the database through a call to mdb_env_set_mapsize and attempt a retry. In the retry I issue mdb_txn_begin again which is where I crash when it calls mdb_txn_renew0(MDB_txn *txn) with txn pointing to garbage. Some additional info which may or may not be relevant: The db size is 1MB aligned and there are no active transactions prior to the call to mdb_env_set_mapsize other than the one that I aborted as a result of the MDB_MAP_FULL. The environment was initially opened with MDB_NOSYNC | MDB_WRITEMAP | MDB_NOMETASYNC | MDB_NOTLS. The crash is intermittent but reproducible in all my configurations. Regards, George

1 0

(ITS#8442) Uninitialized diagnosticMessage in back-meta
by h.b.furuseth＠usit.uio.no 12 Jun '16

12 Jun '16

Full_Name: Hallvard B Furuseth Version: 2.4.41 and later OS: URL: Submission from: (NULL) (81.191.45.31) Submitted by: hallvard meta_back_search() does a goto past const char *save_text = rs->sr_text; which is later "restored" to rs->sr_text. Fixing.

1 0

(ITS#8441) MDB is missing in teh list of possible config for proxy-cache in the admin guide
by elecharny＠apache.org 10 Jun '16

10 Jun '16

Full_Name: Emmanuel L.charny Version: 2.4.44 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.35.197.172) The current Administrative Guide says : "The <DB> parameter specifies which underlying database is to be used to hold cached entries. It should be set to bdb or hdb" (12.9.2.1) 'mdb' should at least be listed here.

1 0

Re: (ITS#8437) openldap-2.4.44 slapd.conf: back-sql database parameters, only first character
by piero.astolfi＠gmx.com 10 Jun '16

10 Jun '16

Switching from iodbc to unixodbc solved my issue.

1 0

Re: (ITS#8432) Never ending operation modifications with 3+ MMR nodes
by hyc＠symas.com 10 Jun '16

10 Jun '16

quanah(a)zimbra.com wrote: > --On Thursday, June 09, 2016 1:19 AM +0100 Howard Chu <hyc(a)symas.com> wrote: > >> quanah(a)openldap.org wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.44 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.52.177) >>> >>> >>> In MMR node, when there is > 2 nodes, operations can get sent out >>> endlessly. >>> >>> For example, we see this modification occur at 20160603194926.427963Z >> >> You seem to have a large clock sync problem. Summary: after fixing the clock skew, the problem was still present. Analyzing debug logs with sync+stats+packets, we see that the offending mods were propagated by syncprov without a CSN in the sync cookie. Since the cookie contained no CSN, the existing check for "CSN too old, ignoring" was not taking place, so the mods were not being filtered out as they should be. syncprov sends mods out without a CSN in the cookie when the mod's CSN is older than the newest contextCSN. In this particular case, between the time that the provider processed the original mod, and the time it was queued up to be sent to the relevant consumers, this server's own consumers had received newer updates from other providers. So, the mod was older than the current contextCSN and was sent without a cookie CSN. (The usual case for syncprov's behavior is when queued mods get sent out of order; since transmission order is not guaranteed to be the same as write/commit order this is a normal occurrence.) It's possible that regular syncrepl+mmr needs a corresponding fix. I haven't looked at that yet. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8440) syncrepl improvements for delta-sync mmr
by quanah＠openldap.org 09 Jun '16

09 Jun '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) Syncprov currently skips contextCSN updates to the main DB, but not the accesslog DB in delta-syncrepl configurations. Consumers correctly ignore this traffic with "CSN too old" messages, but the syncprov code to ignore the updates in the main db should be extended to cover the accesslog DB to cut out this unnecessary traffic.

1 0

Re: (ITS#8433) slapd deadlocks on shutdown in 3+ MMR configuration with active writes
by quanah＠openldap.org 09 Jun '16

09 Jun '16

--On Wednesday, June 08, 2016 11:39 PM +0000 hyc(a)symas.com wrote: > Thread 3 is inside OpenSSL, it thinks there are 433 bytes to read on this > socket and it's waiting for them to arrive. There's not much we can do in > slapd about this. Going back through my notes on when we hit this before with customers, the following are the steps necessary to trigger these deadlocks: a) Must have 2+ replication agreements per node. This will not occur in 2 MMR node environments b) starttls is used in all the replication agreements c) There needs to be fairly consistent write traffic After some point of time, slapd will then deadlock on shutdown. Or, if allowed to run long enough, it will grind completely to a halt (2-3 weeks, depending on traffic). This started after we upgraded to openssl 1.0.1j. It is continuing to occur with openssl 1.0.2h (just to ntoe). --Quanah -- Quanah Gibson-Mount Release and QA Engineer <http://www.openldap.org>

1 0

Re: (ITS#8439) returned unspecified error while trying to start ldap server
by quanah＠zimbra.com 09 Jun '16

09 Jun '16

--On Thursday, June 09, 2016 3:33 PM +0000 sudha243p(a)gmail.com wrote: > Could you please let us know what went wrong in this scenario ? The ITS system is for filing bug reports, not usage questions. Your logs clearly show your database is corrupt: Jun 9 15:24:28 SLS001 slapd[3505]: bdb_db_open: "ou=slsusers,o=ericssonOAM" Jun 9 15:24:28 SLS001 slapd[3505]: bdb_db_open: database "ou=slsusers,o=ericssonOAM": alock package is unstable. Jun 9 15:24:28 SLS001 slapd[3505]: backend_startup_one (type=bdb, suffix="ou=slsusers,o=ericssonOAM"): bi_db_open failed! (-1) Jun 9 15:24:28 SLS001 slapd[3505]: slapd shutdown: initiated This ITS will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Manager, Systems Team Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8439) returned unspecified error while trying to start ldap server
by sudha243p＠gmail.com 09 Jun '16

09 Jun '16

Full_Name: Sudhakar Pittala Version: openldap 2.8 OS: SUSE11.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.176.1.87) Hi, We are using a OPEN SUSE 11.4 LINUX OS machine. Initially ldap process was running fine. Recently we have restarted this machine and after restart we have found that ldap service was not running. So I have tried to start/restart ldap server using Yast and command line but couldn't succeed. Output from Yast: /etc/init.d/ldap start returned 1 (unspecified error): Output from command line: SLS001:/etc/init.d # ./ldap restart redirecting to systemctl redirecting to systemctl Shutting down ldap-server done redirecting to systemctl Starting ldap-server failed File /var/log/localmessages shows below entries. Jun 9 15:24:28 SLS001 slapd[3502]: 1.2.36.79672281.1.13.3 (rdnMatch): Jun 9 15:24:28 SLS001 slapd[3502]: 2.5.13.1 (distinguishedNameMatch): Jun 9 15:24:28 SLS001 slapd[3502]: matchingRuleUse: ( 2.5.13.1 NAME 'distinguishedNameMatch' APPLIES ( creatorsName $ modifiersName $ subschemaSubentry $ entryDN $ namingContexts $ aliasedObjectName $ dynamicSubtrees $ distinguishedName $ seeAlso $ olcDefaultSearchBase $ olcRootDN $ olcSchemaDN $ olcSuffix $ olcUpdateDN $ olcDbACLAuthcDn $ olcDbIDAssertAuthcDn $ olcRelay $ pwdPolicySubentry $ olcPPolicyDefault $ member $ owner $ roleOccupant $ manager $ documentAuthor $ secretary $ associatedName $ dITRedirect $ suseDefaultBase $ suseDefaultTemplate $ suseSecondaryGroup ) ) Jun 9 15:24:28 SLS001 slapd[3502]: 2.5.13.0 (objectIdentifierMatch): Jun 9 15:24:28 SLS001 slapd[3502]: matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) ) Jun 9 15:24:28 SLS001 slapd[3505]: slapd startup: initiated. Jun 9 15:24:28 SLS001 slapd[3505]: backend_startup_one: starting "cn=config" Jun 9 15:24:28 SLS001 slapd[3505]: config_back_db_open Jun 9 15:24:28 SLS001 slapd[3505]: config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn=config" Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn=schema" Jun 9 15:24:28 SLS001 slapd[3505]: >>> dnNormalize: <cn={0}core> Jun 9 15:24:28 SLS001 slapd[3505]: <<< dnNormalize: <cn={0}core> Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn={0}core" Jun 9 15:24:28 SLS001 slapd[3505]: >>> dnNormalize: <cn={1}cosine> Jun 9 15:24:28 SLS001 slapd[3505]: <<< dnNormalize: <cn={1}cosine> Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn={1}cosine" Jun 9 15:24:28 SLS001 slapd[3505]: >>> dnNormalize: <cn={2}inetorgperson> Jun 9 15:24:28 SLS001 slapd[3505]: <<< dnNormalize: <cn={2}inetorgperson> Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn={2}inetorgperson" Jun 9 15:24:28 SLS001 slapd[3505]: >>> dnNormalize: <cn={3}rfc2307bis> Jun 9 15:24:28 SLS001 slapd[3505]: <<< dnNormalize: <cn={3}rfc2307bis> Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn={3}rfc2307bis" Jun 9 15:24:28 SLS001 slapd[3505]: >>> dnNormalize: <cn={4}yast> Jun 9 15:24:28 SLS001 slapd[3505]: <<< dnNormalize: <cn={4}yast> Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "cn={4}yast" Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "olcDatabase={-1}frontend"D%D Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "olcDatabase={0}config" Jun 9 15:24:28 SLS001 slapd[3505]: config_build_entry: "olcDatabase={1}bdb" Jun 9 15:24:28 SLS001 slapd[3505]: backend_startup_one: starting "ou=slsusers,o=ericssonOAM"D%D Jun 9 15:24:28 SLS001 slapd[3505]: bdb_db_open: "ou=slsusers,o=ericssonOAM" Jun 9 15:24:28 SLS001 slapd[3505]: bdb_db_open: database "ou=slsusers,o=ericssonOAM": alock package is unstable. Jun 9 15:24:28 SLS001 slapd[3505]: backend_startup_one (type=bdb, suffix="ou=slsusers,o=ericssonOAM"): bi_db_open failed! (-1) Jun 9 15:24:28 SLS001 slapd[3505]: slapd shutdown: initiated Jun 9 15:24:28 SLS001 slapd[3505]: ====> bdb_cache_release_all Jun 9 15:24:28 SLS001 slapd[3505]: bdb_db_close: database "ou=slsusers,o=ericssonOAM": alock_close failed Jun 9 15:24:28 SLS001 slapd[3505]: slapd destroy: freeing system resources. Jun 9 15:24:28 SLS001 slapd[3505]: slapd stopped. Jun 9 15:24:28 SLS001 slapd[3505]: daemon: SLPDereg(service:ldap://SLS001.site) failed with -20, cookie = 0 Jun 9 15:24:28 SLS001 slapd[3505]: daemon: SLPDereg(service:ldaps://SLS001.site) failed with -20, cookie = 0 Could you please let us know what went wrong in this scenario ? BR, Sudhakar

1 0

Re: (ITS#8432) Never ending operation modifications with 3+ MMR nodes
by quanah＠zimbra.com 09 Jun '16

09 Jun '16

--On Thursday, June 09, 2016 1:19 AM +0100 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)openldap.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.44 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.52.177) >> >> >> In MMR node, when there is > 2 nodes, operations can get sent out >> endlessly. >> >> For example, we see this modification occur at 20160603194926.427963Z > > You seem to have a large clock sync problem. >> >> Jun 3 14:49:22 ldap01 slapd[14014]: syncrepl_message_to_op: rid=100 >> be_modify cn=edge02e.zimbra.com,cn=servers,cn=zimbra (0) >> Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_sendresp: to=002, >> cookie=rid=100,sid=003 >> Jun 3 14:49:22 ldap01 slapd[14014]: slap_queue_csn: queueing 0x121c8680 >> 20160603194926.417898Z#000000#001#000000 >> Jun 3 14:49:22 ldap01 slapd[14014]: slap_graduate_commit_csn: removing >> 0x9403600 20160527111854.508810Z#000000#004#000000 > > How did a CSN from 20160527 get queued on 20160603? Because it had been going around non-stop since 5/27 (5/27 is when I did the modification). --Quanah -- Quanah Gibson-Mount Platform Architect Manager, Systems Team Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs