- openldap-bugs - openldap.org

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 26 Oct '06

26 Oct '06

> I have no idea what t_delete is but it seems to be dying in your malloc > library. Assuming it's not out of memory, you'll probably need some kind of > malloc debugger (like efence) that can detect heap corruption. Hmm, yeah. Out of memory is unlikely; the core is only a couple hundred MB on a dedicated 2GB box. t_delete is in the depths of the Solaris malloc implementation. I'll ask Sun if they can make anything out of "malloc(35)" causing a SEGV; doesn't exactly sound like documented behavior. You're right that without a memory debugger it's tough to trust any of this. But it's also tough to run a memory debugger in production...they generally slow things down a bit more than I'd like.

1 0

Re: (ITS#4723) SEGV in syncprov search
by hyc＠symas.com 26 Oct '06

26 Oct '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026_2-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > What a day. I've never had to "_2" dated backtraces ever before... > > Syncprov search, SEGV'd. See "t@13" thread in linked backtrace. I have no idea what t_delete is but it seems to be dying in your malloc library. Assuming it's not out of memory, you'll probably need some kind of malloc debugger (like efence) that can detect heap corruption. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 26 Oct '06

26 Oct '06

Full_Name: Aaron Richton Version: 2.3.28 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026_2-backtrace.txt Submission from: (NULL) (68.196.250.61) What a day. I've never had to "_2" dated backtraces ever before... Syncprov search, SEGV'd. See "t@13" thread in linked backtrace.

1 0

Re: (ITS#4721) thr_stub.c needs do nothing ldap_pvt_thread_pool_tid()
by ando＠sys-net.it 26 Oct '06

26 Oct '06

rk(a)owen.sj.ca.us wrote: > Here is the trivial patch rkowen-061026.patch > Thanks for the fix. It's in HEAD now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4722) crash in daemon.c
by quanah＠stanford.edu 26 Oct '06

26 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.27/HEAD OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) With the latest updates, I hit a assert in daemon.c (from HEAD). It appears there is still a possible race condition. The assert hit was: daemon.c:551 assert( SLAP_SOCK_IS_ACTIVE( s )); in slapd_clr_write called from: connection.c:808 slapd_clr_write( sd, 1 ); in connection_closing It looks like the write needs to be cleared before the mutex is unlocked. --Quanah

1 0

(ITS#4721) thr_stub.c needs do nothing ldap_pvt_thread_pool_tid()
by rk＠owen.sj.ca.us 26 Oct '06

26 Oct '06

Full_Name: R.K. Owen Version: Anon-CVS OS: Ubuntu-6.05 Linux URL: ftp://ftp.openldap.org/incoming/rkowen-061026.patch Submission from: (NULL) (66.87.79.68) After trying to "configure --without-threads ...", the build resulted in the following error message: connection.o: In function `connection_operation':/home/owen/rk/nim/openldap/openldap-cvs/servers/slapd/connection.c:1044: undefined reference to `ldap_pvt_thread_pool_tid' connection.o: In function `connection_fake_init':/home/owen/rk/nim/openldap/openldap-cvs/servers/slapd/connection.c:1955: undefined reference to `ldap_pvt_thread_pool_tid' This can be resolved by creating the trivial do-nothing ldap_pvt_thread_pool_tid() function in thr_stub.c Here is the trivial patch rkowen-061026.patch

1 0

Re: (ITS#4720) hdb deadlock
by hyc＠symas.com 26 Oct '06

26 Oct '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt > Submission from: (NULL) (68.193.253.190) > > > Solaris 9, BDB 4.2.52+4, OL 2.3.28. > > ldapadd submitted, deadlocked one hdb suffix. Other hdb's remained fine. Fixed now in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4720) hdb deadlock
by hyc＠symas.com 26 Oct '06

26 Oct '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt > Submission from: (NULL) (68.193.253.190) > > > Solaris 9, BDB 4.2.52+4, OL 2.3.28. > > ldapadd submitted, deadlocked one hdb suffix. Other hdb's remained fine. > Backtrace of dead slapd at > > https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt > > and db_stat -CA of affected database at > > https://www.nbcs.rutgers.edu/~richton/richton-20061026-dbstatCA.txt > > > I have the core file saved if you need any variables out, but this was > production so I had to restart the service/no opportunity for live debugging. For an immediate workaround, turn off syncprov's contextCSN checkpointing. It will only checkpoint during a clean shutdown, but that shouldn't be a problem. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4720) hdb deadlock
by richton＠nbcs.rutgers.edu 26 Oct '06

26 Oct '06

Full_Name: Aaron Richton Version: 2.3.28 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt Submission from: (NULL) (68.193.253.190) Solaris 9, BDB 4.2.52+4, OL 2.3.28. ldapadd submitted, deadlocked one hdb suffix. Other hdb's remained fine. Backtrace of dead slapd at https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt and db_stat -CA of affected database at https://www.nbcs.rutgers.edu/~richton/richton-20061026-dbstatCA.txt I have the core file saved if you need any variables out, but this was production so I had to restart the service/no opportunity for live debugging.

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by bgmilne＠staff.telkomsa.net 24 Oct '06

24 Oct '06

--nextPart6645744.gz20WZ6vTg Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 24 October 2006 21:00, quanah(a)stanford.edu wrote: > --On Tuesday, October 24, 2006 6:52 PM +0000 Kurt(a)OpenLDAP.org wrote: > > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: > >> quanah(a)stanford.edu wrote: > >>> It would be nice if you could pass -u and -g options to run as another > >>> user/group so that on systems where OpenLDAP is running as another us= er > >>> or group, the files created by slapadd & slapindex have the correct > >>> ownerships (rather than root, for example). > >> > >> OK for slapadd; for slapindex and other tools, what about using > >> user/group info from the file(s) itself? > > > > Why not just use su(1)? the only reason slapd(8) has -u/-g options > > is because it changes root after some initialization. > > Because some people are brain dead, and because other people set up > application accounts that don't actually have a shell. And some brain-dead OS's have an su without a -s flag ? > It also makes=20 > things more consistent behavior wise. I personally don't have this issue > because I run openldap as root anyway, but I've seen list traffic about > this on more than one occasion, and am seeing people hit it on the debian > openldap list as well. Debian doesn't have a brain-dead su, so 'su -s /bin/bash -c "slapadd ...."'= =20 etc. is feasible. One of my colleagues has a sticker on his monitor which says: Social Engineering Specialist: because there is no patch for stupidity. I haven't seen the need for this myself (but then I don't use back-config, = and=20 my initscript parses slapd.conf to find all database directories, and check= s=20 ownership on all of them). Regards, Buchan =2D-=20 Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592) --nextPart6645744.gz20WZ6vTg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFPwhOrJK6UGDSBKcRApYPAKCecAu2I8CXqMin3Uz9a1MQv8cUEgCfZFPm TLqaOhPzhqr0KV8Y0W7fNR4= =93Bl -----END PGP SIGNATURE----- --nextPart6645744.gz20WZ6vTg--

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by ahasenack＠terra.com.br 24 Oct '06

24 Oct '06

On Tue, Oct 24, 2006 at 12:46:30PM -0700, Quanah Gibson-Mount wrote: > >>Because some people are brain dead, and because other people set up > >>application accounts that don't actually have a shell. It also makes > >>things more consistent behavior wise. I personally don't have this > >>issue because I run openldap as root anyway, but I've seen list traffic > >>about this on more than one occasion, and am seeing people hit it on > >>the debian openldap list as well. > > > >The slapd initscript should/could chown the files whenever slapd is > >(re)started. > > And how would the init script know the locations of X number of databases, > particularly if back-config is used? With back-config things get more complicated, but with slapd.conf it's just a bunch of greps. What about storing this info inside the config file itself (i.e., "slapd_user ldap", "slapd_group ldap")? Chicken and egg problem?

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

--On Tuesday, October 24, 2006 7:16 PM +0000 ahasenack(a)terra.com.br wrote: > On Tue, Oct 24, 2006 at 07:00:40PM +0000, quanah(a)stanford.edu wrote: >> >> >> --On Tuesday, October 24, 2006 6:52 PM +0000 Kurt(a)OpenLDAP.org wrote: >> >> > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: >> >> quanah(a)stanford.edu wrote: >> >>> It would be nice if you could pass -u and -g options to run as >> >>> another user/group so that on systems where OpenLDAP is running as >> >>> another user or group, the files created by slapadd & slapindex have >> >>> the correct ownerships (rather than root, for example). >> >>> >> >> OK for slapadd; for slapindex and other tools, what about using >> >> user/group info from the file(s) itself? >> > >> > Why not just use su(1)? the only reason slapd(8) has -u/-g options >> > is because it changes root after some initialization. >> >> Because some people are brain dead, and because other people set up >> application accounts that don't actually have a shell. It also makes >> things more consistent behavior wise. I personally don't have this >> issue because I run openldap as root anyway, but I've seen list traffic >> about this on more than one occasion, and am seeing people hit it on >> the debian openldap list as well. > > The slapd initscript should/could chown the files whenever slapd is > (re)started. And how would the init script know the locations of X number of databases, particularly if back-config is used? --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by ahasenack＠terra.com.br 24 Oct '06

24 Oct '06

On Tue, Oct 24, 2006 at 07:00:40PM +0000, quanah(a)stanford.edu wrote: > > > --On Tuesday, October 24, 2006 6:52 PM +0000 Kurt(a)OpenLDAP.org wrote: > > > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: > >> quanah(a)stanford.edu wrote: > >>> It would be nice if you could pass -u and -g options to run as another > >>> user/group so that on systems where OpenLDAP is running as another user > >>> or group, the files created by slapadd & slapindex have the correct > >>> ownerships (rather than root, for example). > >>> > >> OK for slapadd; for slapindex and other tools, what about using > >> user/group info from the file(s) itself? > > > > Why not just use su(1)? the only reason slapd(8) has -u/-g options > > is because it changes root after some initialization. > > Because some people are brain dead, and because other people set up > application accounts that don't actually have a shell. It also makes > things more consistent behavior wise. I personally don't have this issue > because I run openldap as root anyway, but I've seen list traffic about > this on more than one occasion, and am seeing people hit it on the debian > openldap list as well. The slapd initscript should/could chown the files whenever slapd is (re)started.

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by hyc＠symas.com 24 Oct '06

24 Oct '06

Kurt(a)OpenLDAP.org wrote: > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: >> quanah(a)stanford.edu wrote: >>> It would be nice if you could pass -u and -g options to run as another >>> user/group so that on systems where OpenLDAP is running as another user or >>> group, the files created by slapadd & slapindex have the correct ownerships >>> (rather than root, for example). >>> >> OK for slapadd; for slapindex and other tools, what about using >> user/group info from the file(s) itself? > > Why not just use su(1)? the only reason slapd(8) has -u/-g options > is because it changes root after some initialization. Agreed. As for using info from the files themselves - that requires per-backend functions to return the user/group info. Seems like unnecessary effort. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

--On Tuesday, October 24, 2006 6:52 PM +0000 Kurt(a)OpenLDAP.org wrote: > At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: >> quanah(a)stanford.edu wrote: >>> It would be nice if you could pass -u and -g options to run as another >>> user/group so that on systems where OpenLDAP is running as another user >>> or group, the files created by slapadd & slapindex have the correct >>> ownerships (rather than root, for example). >>> >> OK for slapadd; for slapindex and other tools, what about using >> user/group info from the file(s) itself? > > Why not just use su(1)? the only reason slapd(8) has -u/-g options > is because it changes root after some initialization. Because some people are brain dead, and because other people set up application accounts that don't actually have a shell. It also makes things more consistent behavior wise. I personally don't have this issue because I run openldap as root anyway, but I've seen list traffic about this on more than one occasion, and am seeing people hit it on the debian openldap list as well. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by ando＠sys-net.it 24 Oct '06

24 Oct '06

quanah(a)stanford.edu wrote: >> OK for slapadd; for slapindex and other tools, what about using >> user/group info from the file(s) itself? >> > > What file(s)? Assuming this is a new (and only) index? I guess the __db.* > files? or the id2entry file? Just trying to see specifically where you are > going on this. :) > I mean: if slapadding a brand new db, -u/-g (but -g is already in use by glue stuff) is fine. If slapadding/slapindexing an existing db, get the info from the existing file, if any, or from id2entry.bdb. I'd use a specific option, though, and bail out if no definite answer can be gathered (e.g. -H means use ownership from file, -HH use ownership from file, or from id2entry.bdb if file does not exist). Note that it would make sense to have the -HH behavior as the default... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by Kurt＠OpenLDAP.org 24 Oct '06

24 Oct '06

At 11:48 AM 10/24/2006, ando(a)sys-net.it wrote: >quanah(a)stanford.edu wrote: >> It would be nice if you could pass -u and -g options to run as another >> user/group so that on systems where OpenLDAP is running as another user or >> group, the files created by slapadd & slapindex have the correct ownerships >> (rather than root, for example). >> >OK for slapadd; for slapindex and other tools, what about using >user/group info from the file(s) itself? Why not just use su(1)? the only reason slapd(8) has -u/-g options is because it changes root after some initialization.

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

--On Tuesday, October 24, 2006 8:49 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: > quanah(a)stanford.edu wrote: >> It would be nice if you could pass -u and -g options to run as another >> user/group so that on systems where OpenLDAP is running as another user >> or group, the files created by slapadd & slapindex have the correct >> ownerships (rather than root, for example). >> > OK for slapadd; for slapindex and other tools, what about using > user/group info from the file(s) itself? What file(s)? Assuming this is a new (and only) index? I guess the __db.* files? or the id2entry file? Just trying to see specifically where you are going on this. :) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4719) Support for running slapadd/slapindex as a user
by ando＠sys-net.it 24 Oct '06

24 Oct '06

quanah(a)stanford.edu wrote: > It would be nice if you could pass -u and -g options to run as another > user/group so that on systems where OpenLDAP is running as another user or > group, the files created by slapadd & slapindex have the correct ownerships > (rather than root, for example). > OK for slapadd; for slapindex and other tools, what about using user/group info from the file(s) itself? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

Full_Name: Quanah Gibson-Mount Version: All OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) It would be nice if you could pass -u and -g options to run as another user/group so that on systems where OpenLDAP is running as another user or group, the files created by slapadd & slapindex have the correct ownerships (rather than root, for example).

1 0

Re: (ITS#4718) Option 'network-timeout' missing from slapd-meta man pages
by ando＠sys-net.it 24 Oct '06

24 Oct '06

damonmo(a)gmail.com wrote: > The option 'network-timeout' used to stablish a socket-level timeout on meta > backend is missing on slapd-meta man pages. > Fixed in HEAD/re23. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4718) Option 'network-timeout' missing from slapd-meta man pages
by damonmo＠gmail.com 24 Oct '06

24 Oct '06

Full_Name: Daniel Montero Motilla Version: 2.3.27 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12) The option 'network-timeout' used to stablish a socket-level timeout on meta backend is missing on slapd-meta man pages.

1 0

Re: (ITS#4696) Assert core in connection.c
by quanah＠stanford.edu 23 Oct '06

23 Oct '06

--On Monday, October 23, 2006 7:13 PM +0000 richton(a)nbcs.rutgers.edu wrote: > I just got bit with this c_writewaiter assert. This is 2.3.27 with patch > for #4708 and #4695. See > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt for > *c (full backtrace included for good measure). I'll note an important difference between your hitting this issue and my hitting this issue. In my case: (a) I was using connection.c code from HEAD (b) c_writewaiter was zero, and not one. The issue in my case I believe was due to two things: (1) An optimization bug in gcc, because once I rebuilt with gcc 4.1.1, I never got this issue, and (2) A race condition that existed in the HEAD code, that was recently fixed. I no longer experience this problem with the updated HEAD code and gcc 4.1.1 as the compiler. I'd actually say that your report on this issue is a new ITS. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4696) Assert core in connection.c
by Kurt＠OpenLDAP.org 23 Oct '06

23 Oct '06

At 12:13 PM 10/23/2006, richton(a)nbcs.rutgers.edu wrote: >I just got bit with this c_writewaiter assert. This is 2.3.27 with patch >for #4708 and #4695. See >https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt for >*c (full backtrace included for good measure). Try 2.3.28.

1 0

Re: (ITS#4696) Assert core in connection.c
by richton＠nbcs.rutgers.edu 23 Oct '06

23 Oct '06

I just got bit with this c_writewaiter assert. This is 2.3.27 with patch for #4708 and #4695. See https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt for *c (full backtrace included for good measure).

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs