- openldap-bugs - openldap.org

(ITS#8873) slapd-meta/ldap - Remove deprecated options
by quanah＠openldap.org 06 Jul '18

06 Jul '18

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) For OpenLDAP 2.5, we should remove the deprecated configuration options for back-ldap/meta/asyncmeta that have been marked as deprecated for multiple release series. Man pages should be updated accordingly as well. acl-authcDN acl-passwd idassert-authcDN idassert-passwd idassert-mode idassert-method port server suffixmassage map rewrite*

1 0

Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 04 Jul '18

04 Jul '18

On 06/20/2018 01:25 PM, Michael Ströder wrote: > This patch is meant to enhance user experience in case a client software > is used to maintain data directly via LDAP. This is a real-world issue. > > Find the patch against master here: > https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-u… > > Also cleanly applies to RE24 and therefore > could be easily added to upcoming release 2.4.47. ;-) Any chance to see this in 2.4.47? It simply works and the patch was also reviewed by another C programmer. Ciao, Michael.

1 0

Re: (ITS#8872) configure.in has long been deprecated
by hyc＠symas.com 30 Jun '18

30 Jun '18

fturco(a)fastmail.fm wrote: > Full_Name: Francesco Turco > Version: 2.4.45 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:b07:2eb:c9ed:21c:c0ff:fead:3d70) > > > The Portage package manager reports the following warning message when building > net-nds/openldap-2.4.45 on Gentoo Linux: > > * This package has a configure.in file which has long been deprecated. Please > * update it to use configure.ac instead as newer versions of autotools will > die > * when it finds this file. See https://bugs.gentoo.org/426262 for details. > > Original bug report: https://bugs.gentoo.org/607686 Not a priority. The version of autoconf we use has been frozen for a long time and isn't going to change any time soon. End-users aren't expected to run the autotools themselves anyway, only the OpenLDAP Release Engineer does that. And changing filenames out of the blue is not viewed fondly by people trolling commit histories. Closing this ITS. -- -- 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#8872) configure.in has long been deprecated
by fturco＠fastmail.fm 30 Jun '18

30 Jun '18

Full_Name: Francesco Turco Version: 2.4.45 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:b07:2eb:c9ed:21c:c0ff:fead:3d70) The Portage package manager reports the following warning message when building net-nds/openldap-2.4.45 on Gentoo Linux: * This package has a configure.in file which has long been deprecated. Please * update it to use configure.ac instead as newer versions of autotools will die * when it finds this file. See https://bugs.gentoo.org/426262 for details. Original bug report: https://bugs.gentoo.org/607686

1 0

(ITS#8871) mutex issue with cancel operation
by hsuenju_ko＠stratus.com 26 Jun '18

26 Jun '18

Full_Name: HsuenJu Ko Version: 2.4.46 OS: VOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.97.42.5) A multi-threaded test case using C API experiences a hang involving cancel operation. One thread which performs cancel operation hangs waiting for a mutex(ld_conn_mutex) in ldap_send_initial_request while the other thread is performing ldap_result loop waiting for the result of search operation. The same mutex is held by wait4msg() across the ldap_int_select() call. It appears that before the ITS#6672 is installed, the ld_conn_mutex is unlocked before the ldap_int_select() and after the ITS#6672 the unlock is moved after ldap_int_select() which causes the thread performing the cancel to hang until ldap_result returns. By holding this mutex across select(), then all other threads needing the mutex are frozen until this select completes.

1 0

Re: (ITS#8667) slapcat not honoring '-g' option
by ondra＠mistotebe.net 25 Jun '18

25 Jun '18

On Mon, Jun 05, 2017 at 03:11:06PM +0000, gnoe(a)symas.com wrote: > Slapcat is not honoring the '-g' option. The output includes entries from glued > subordinates when it shouldn't. The attached test script > (gregory-noe-170605.tar) sets up the following DIT with inetOrgPerson entries in > each OU: > > dn: dc=example,dc=com > |- ou=NonSub00,dc=example,dc=com > |- ou=NonSub01,dc=example,dc=com > |- ou=NonSub02,dc=example,dc=com > > glued sub: ou=Accounting,dc=example,dc=com > glued sub: ou=Administrative,dc=example,dc=com > glued sub: ou=Janitorial,dc=example,dc=com > > Then the script runs 'slapcat -g -b dc=example,dc=com | grep ^dn'. The result > contains entries from all three glued subordinates. Hi Gregory, the branch linked below has a patch to this that results in the test script you provided produce output that's expected, let me know if it fixes your issue: https://github.com/mistotebe/openldap/tree/its8667 Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8870) SASL_NOCANON changing default to ON
by alexandr.nedvedicky＠oracle.com 25 Jun '18

25 Jun '18

On Fri, Jun 22, 2018 at 06:17:15PM -0700, Quanah Gibson-Mount wrote: > --On Saturday, June 23, 2018 1:56 AM +0000 quanah(a)symas.com wrote: > > >--On Friday, June 22, 2018 9:01 PM +0000 alexandr.nedvedicky(a)oracle.com > >wrote: > > > >>Full_Name: Alexandr Nedvedicky > >>Version: 2.46 > >>OS: Solaris 11.3 > >>URL: ftp://ftp.openldap.org/incoming/ > >>Submission from: (NULL) (141.143.193.76) > >> > >> > >>Disclaimer: I understand I'm asking for change, which might be disruptive > >>for many OpenLDAP users. > > > >Hi, > > > >This has already been covered extensively in > ><http://www.openldap.org/its/index.cgi/?findid=5812>. If you prefer to > >have it turned off > > Turned on, even. ;) > thank you for the link. will change global ldap.conf we ship. regards sasha

1 0

Re: (ITS#8870) SASL_NOCANON changing default to ON
by quanah＠symas.com 23 Jun '18

23 Jun '18

--On Saturday, June 23, 2018 1:56 AM +0000 quanah(a)symas.com wrote: > --On Friday, June 22, 2018 9:01 PM +0000 alexandr.nedvedicky(a)oracle.com > wrote: > >> Full_Name: Alexandr Nedvedicky >> Version: 2.46 >> OS: Solaris 11.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (141.143.193.76) >> >> >> Disclaimer: I understand I'm asking for change, which might be disruptive >> for many OpenLDAP users. > > Hi, > > This has already been covered extensively in > <http://www.openldap.org/its/index.cgi/?findid=5812>. If you prefer to > have it turned off Turned on, even. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8870) SASL_NOCANON changing default to ON
by quanah＠symas.com 23 Jun '18

23 Jun '18

--On Friday, June 22, 2018 9:01 PM +0000 alexandr.nedvedicky(a)oracle.com wrote: > Full_Name: Alexandr Nedvedicky > Version: 2.46 > OS: Solaris 11.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.143.193.76) > > > Disclaimer: I understand I'm asking for change, which might be disruptive > for many OpenLDAP users. Hi, This has already been covered extensively in <http://www.openldap.org/its/index.cgi/?findid=5812>. If you prefer to have it turned off for all clients on a system, you can use your global ldap.conf file to do so. The project will not be changing long-standing behavior. But I appreciate your time in filing the ITS. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8870) SASL_NOCANON changing default to ON
by alexandr.nedvedicky＠oracle.com 22 Jun '18

22 Jun '18

Full_Name: Alexandr Nedvedicky Version: 2.46 OS: Solaris 11.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.143.193.76) Disclaimer: I understand I'm asking for change, which might be disruptive for many OpenLDAP users. The issue popped up as a fallout of transition from Mozilla LDAP to OpenLDAP. The mozilla ldap does not canonicalize hostname using DNS by default, while OpenLDAP does the exact opposite. Using DNS to canonicalize hosts to domain name opens potential attack vector via. DNS spoofing. For example samba client opts out from name canonicalization, snippet comes from lib/libsmbns/common/smbns_ads.c: 1539 /* 1540 * smb_ads_open 1541 * 1542 * Open an LDAP connection to a discovered AD server for the specified domain. 1543 * Specify our capability to support LDAP_VERSION3 when binding to the AD 1544 * server. On success, returns an AD handle. Otherwise, returns NULL. 1545 * 1546 * By default, 'encrypt_ldap' property is set to B_TRUE. For debugging 1547 * purposes, it can be set to B_FALSE to disable LDAP encryption. 1548 * 1549 * Pre-condition: 1550 * A Kerberos TGT ticket must be found in ccache in order to acquire a LDAP 1551 * service ticket. 1552 * 1553 * Parameters: 1554 * domain - fully-qualified domain name 1555 */ 1556 static smb_ads_handle_t * 1557 smb_ads_open(char *domain) 1558 { .... 1590 (void) ldap_unbind(ld); 1591 return (NULL); 1592 } 1593 1594 (void) ldap_set_option(ld, LDAP_OPT_REFERRALS, LDAP_OPT_OFF); 1595 (void) ldap_set_option(ld, LDAP_OPT_X_SASL_NOCANON, LDAP_OPT_ON); 1596 1597 ah->ld = ld; 1598 ah->domain = strdup(domain); 1599 1600 if (ah->domain == NULL) { 1601 smb_ads_close(ah); 1602 smb_ads_free_host(ads_host); 1603 return (NULL); 1604 } 1605 I can't tell how other projects are handling/prefer handling of NOCANON option. The Solaris considers to tight the knob and say 'yes to NOCANON' in order to suppress hostname canonicalization. As I've said I fully understand if you decide not to change the current default as the change might hurt many users. I just rather want to share our experience we got when switching from mozilla ldap to OpenLDAP.

1 0

(ITS#8869) Gentoo QA notice
by fturco＠fastmail.fm 22 Jun '18

22 Jun '18

Full_Name: Francesco Turco Version: 2.4.45 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:b07:2eb:c9ed:21c:c0ff:fead:3d70) My GNU/Linux distribution is Gentoo Linux. When installing net-nds/openldap-2.4.45 the Portage package manager reports the following warning: * QA Notice: Package triggers severe warnings which indicate that it * may exhibit random runtime failures. * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap/open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap_r/thr_posix.c:93:9: warning: implicit declaration of function pthread_setconcurrency; did you mean pthread_setcanceltype? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap_r/thr_posix.c:107:9: warning: implicit declaration of function pthread_getconcurrency; did you mean ldap_pvt_thread_get_concurrency? [-Wimplicit-function-declaration] * open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/servers/slapd/back-ldap/bind.c:722:2: warning: implicit declaration of function slap_client_keepalive; did you mean slap_client_connect? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/servers/slapd/back-meta/conn.c:424:2: warning: implicit declaration of function slap_client_keepalive; did you mean slap_client_connect? [-Wimplicit-function-declaration] * cloak.c:246:4: warning: implicit declaration of function attr_clean; did you mean entry_clean? [-Wimplicit-function-declaration] * Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: http://www.OpenLDAP.org/

1 0

Re: (ITS#8573) ldap* tools should be able to function w/o a conf file
by ondra＠mistotebe.net 22 Jun '18

22 Jun '18

Other tests might need to use the ldaps urls added with ITS#8573, the patch at https://github.com/mistotebe/openldap/tree/its8573-tables makes them available to scripts and $CONFFILTER users. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8772) Build fail: thr_posix.c:329:16: error: only weak aliases are supported on darwin
by ondra＠mistotebe.net 22 Jun '18

22 Jun '18

On Wed, Nov 15, 2017 at 04:59:57PM +0000, minfrin(a)sharp.fm wrote: > Hi all, > > I am seeing a build failure when trying to build openldap master on MacOS > Sierra: Hi Graham, a proposed patch series is available here: https://github.com/mistotebe/openldap/tree/its8772 Does it fix the build issues for you? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#7336) Ldapmodify crashes slapd when updating olcTLSVerifyClient attribute via TLS authentication
by ck＠cksoft.de 22 Jun '18

22 Jun '18

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --214647081-852979057-1529664529=:67666 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi, On Fri, 22 Jun 2018, Ondřej Kuzník wrote: > On Sun, Mar 23, 2014 at 09:32:22AM +0000, ck(a)cksoft.de wrote: >> Hi, >> >> I can confirm that openldap-2.4.39 still has in issue with this. >> >> When connecting via TLS I tried to modify olcTLSVerifyClient from never >> to try with following ldif: >> >> dn: cn=config >> changetype: modify >> replace: olcTLSVerifyClient >> olcTLSVerifyClient: try >> >> this caused slapd to hang indefinetely. >> >> I was able to successfully modify above when connecting without TLS. >> >> I need to complete my current task but will set up a small proof of >> concept later on in my lab. > > Hi Christian, > have you been able to set up a test configuration that reproduces it > with latest OpenLDAP? A cursory test here doesn't seem to do anything of > the sort. this is 4 years old and I had totally forgetten about it. But I just happen to have a developement cluster running with both the affected 2.4.39 and new 2.4.46 nodes. I will try to test over the weekend and will give you feedback. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ --214647081-852979057-1529664529=:67666--

1 0

Re: (ITS#7336) Ldapmodify crashes slapd when updating olcTLSVerifyClient attribute via TLS authentication
by ondra＠mistotebe.net 22 Jun '18

22 Jun '18

On Sun, Mar 23, 2014 at 09:32:22AM +0000, ck(a)cksoft.de wrote: > Hi, > > I can confirm that openldap-2.4.39 still has in issue with this. > > When connecting via TLS I tried to modify olcTLSVerifyClient from never > to try with following ldif: > > dn: cn=config > changetype: modify > replace: olcTLSVerifyClient > olcTLSVerifyClient: try > > this caused slapd to hang indefinetely. > > I was able to successfully modify above when connecting without TLS. > > I need to complete my current task but will set up a small proof of > concept later on in my lab. Hi Christian, have you been able to set up a test configuration that reproduces it with latest OpenLDAP? A cursory test here doesn't seem to do anything of the sort. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#8868) Inefficiency when processing certain search filters
by quanah＠openldap.org 21 Jun '18

21 Jun '18

Full_Name: Quanah Gibson-Mount Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Certain search filters are not processed efficiently in the back-{bhm}db code base. An example is: "(|(&(subscriberid=1)(objectClass=XYZ))(&(subscriberid=2)(objectClass=XYZ)))" In this situation, the contiguous list of possibilities for the objectClass result gets turned into a range, causing each entry to be examined as a match. This significantly increases CPU load and causes a delay in returning the result. Re-arranging the search in the following manner bypasses this issue: (&(objectClass=XYZ)(|(subscriberid=1)(subscriberid=2)))" General timing with back-mdb: .477 seconds for the expensive search .020 seconds for the optimized search For back-bdb, the timing was: .665 seconds for the expensive search .020 seconds for the optimized search

1 0

Re: (ITS#8867) ldap_sasl_bind_s failed error during replication
by michael＠stroeder.com 21 Jun '18

21 Jun '18

The ITS is for reporting bugs only. Please subscribe to the openldap-technical mailing list and post your usage questions there: https://www.openldap.org/lists/mm/listinfo/openldap-technical Ciao, Michael.

1 0

(ITS#8867) ldap_sasl_bind_s failed error during replication
by appana.anil＠gmail.com 21 Jun '18

21 Jun '18

Full_Name: anil kumar appanna Version: 2.4 OS: RHEL URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (143.112.32.4) I configured multi master replication. The configuration went well without any errors, but the data is not replicated from one server to another one. When i looked at the log file, i am getting the below errors slap_client_connect: URI=ldap://***.com DN="cn=config" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=001 rc -1 retrying slap_client_connect: URI=ldap://***.com DN="cn=ldapadm,dc=****,dc=com" ldap_sasl_bind_s failed (-1) appreciate any quick help. I am very new to openldap.

1 0

Re: (ITS#8842) NULL pointer derefence
by ondra＠mistotebe.net 21 Jun '18

21 Jun '18

On Tue, May 01, 2018 at 08:14:50PM +0000, openldap(a)katzen.cc wrote: > 2 small issues: > I'm keeping it brief, let me know if you need more information. > > A malicious LDAP server or mitm attacker can craft a response that causes the > ldap client to crash. Nothing critical, just a simoke DoS. > [...] > The problem here is that retoid can be NULL after ldap_parse_intermediate() is > called. > > Another NULL pointer dereference caused by a bad response: > [...] > The PoC leads to memcpy being called with a NULL pointer as second argument > (ava->la_value.bv_val) in dn2domain() (libraries/libldap/getdn.c): > > AC_MEMCPY( str, ava->la_value.bv_val, ava->la_value.bv_len + 1); Both are fixed in this branch: https://github.com/mistotebe/openldap/tree/its8842 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 20 Jun '18

20 Jun '18

On 06/20/2018 01:41 PM, Michael Ströder wrote: > Ouch! This was not yet complete. I'll come up with a new revision soon. Please review this patch: https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-u… Disclaimer: I'm not a C programmer. Thanks for your patience. Ciao, Michael.

1 0

Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 20 Jun '18

20 Jun '18

On 06/20/2018 01:26 PM, michael(a)stroeder.com wrote: > Find the patch against master here: > https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-u… Ouch! This was not yet complete. I'll come up with a new revision soon. Ciao, Michael.

1 0

Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 20 Jun '18

20 Jun '18

Rationale: This patch is meant to enhance user experience in case a client software is used to maintain data directly via LDAP. This is a real-world issue. Find the patch against master here: https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-u… Also cleanly applies to RE24 and therefore could be easily added to upcoming release 2.4.47. ;-)

1 0

(ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 20 Jun '18

20 Jun '18

Full_Name: Version: OS: URL: Submission from: (NULL) (213.240.182.62) See motivation and disclosure considerations in list archive: https://www.openldap.org/lists/openldap-devel/201711/msg00003.html Patch will follow.

1 0

Re: (ITS#8844) LMDB mdb_env_close is unsafe in forked child
by h.b.furuseth＠usit.uio.no 14 Jun '18

14 Jun '18

On 14/06/2018 21:04, Howard Chu wrote: > Hallvard Breien Furuseth wrote: >> On 14/06/2018 20:34, Howard Chu wrote: >>> If there are any table entries under that PID there's no problem >>> removing them. >> >> The problem is that it's arbitrary. Something is exiting without >> clearing its pid slots, and 0.001% of the time this code will catch it. > > Sure. But I don't think it's worthwhile to make a special case here to > skip this step. To my eyes the getpid() is a special case already, to someone trying to understand the code. Though adding a comment could fix that. See below. >> Better to skip this cleanup, or to always do it - but "always" belongs >> in env_open(). If a new env is seeing its pid in use, then it can >> safely clean it out. Last we talked about that, I liked it and you >> did not:-) > > And I don't see any particular reason to add this step. right >>(...) >> Parent, pid P: >> open env A. >> >> Child, pid Q: >> - open and start using env B with the same path. >> - close env A, while B is still open. >> With the new code, this clears pid Q - i.e. B's pids. >> But lmdb.h already lists that as a "don't do that", >> because it also removes B's lock on the lockfile. >> > Yeah, this is still a "don't do that" though, regardless of this > particular ITS. Right. So in summary, there are two cases when getpid() can be there to clean out, and in neither case does it make sense to clean it out. Other than the sense of avoiding one "if () { init two vars; }". I like that better than a comment about not bothering to, but a comment is OK too.

1 0

Re: (ITS#8844) LMDB mdb_env_close is unsafe in forked child
by hyc＠symas.com 14 Jun '18

14 Jun '18

Hallvard Breien Furuseth wrote: > On 14/06/2018 20:34, Howard Chu wrote: >> Hallvard Breien Furuseth wrote: >>> Wait, what? The child didn't write any pids to the table. If >>> there are pids for it to clear, something is wrong. That can be: >> >> No, there most likely aren't PIDs for it to clear. But most importantly, it >> must not clear using env->me_pid since that is still the parent's PID. >> >>> - The pid is from an older run, and the system reused the pid. If we >>> code for this, it should be to clear such pids during mdb_env_open. >>> It gets very arbitrary to clear them when the user does env_close() >>> in the child and the child happens to have the that reused pid. >> >> No. If the system reused the PID then that means the previous owner of that >> PID is dead already anyway. > > Right... > >> If there are any table entries under that PID there's no problem removing them. > > The problem is that it's arbitrary. Something is exiting without > clearing its pid slots, and 0.001% of the time this code will catch it. Sure. But I don't think it's worthwhile to make a special case here to skip this step. > Better to skip this cleanup, or to always do it - but "always" belongs > in env_open(). If a new env is seeing its pid in use, then it can safely > clean it out. Last we talked about that, I liked it and you > did not:-) And I don't see any particular reason to add this step. >>> - The child opened a new MDB_env with the same path, and closes the >>> parent's env afterwards. Don't Do That, users. But what to do in >>> this situation, if we are to have code for it, is to do nothing with >>> the lockfile. Not close it either, since closing it will lose the >>> lock for the env which was opened in the child. >> >> That's a completely different case. This ITS is specifically about a process >> with an open environment that subsequently forks. > > No, I mean: > > Parent, pid P: > open env A. > > Child, pid Q: > - open and start using env B with the same path. > - close env A, while B is still open. > With the new code, this clears pid Q - i.e. B's pids. > But lmdb.h already lists that as a "don't do that", > because it also removes B's lock on the lockfile. > Yeah, this is still a "don't do that" though, regardless of this particular ITS. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs