openldap-bugs May 2008

openldap-bugs@openldap.org

54 participants
208 discussions

Re: (ITS#5504) ldapsearch hangs retrieving info
by hyc＠symas.com 09 May '08

09 May '08

Javier.Fernandez(a)cern.ch wrote: > Full_Name: Javier Fernandez > Version: 2.2.13 > OS: SL4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (156.35.192.4) OpenLDAP 2.2 was moved to Historical status a few years ago. Upgrade to a current supported release if you want anyone to look into this. > > Hi, > ldapsearch gets stuck retrieving info and after some minutes the following error > message is thrown: > ldap_result: Can't contact LDAP server (-1) > > I'm using: > ldapsearch -V > ldapsearch: @(#) $OpenLDAP: ldapsearch 2.2.13 (May 3 2007 03:01:11) $ > root@lxcert-amd64:/scratch/rpmbuild.7430.xx7460/openldap-2.2.13/openldap-2.2.13/build-clients/clients/tools > (LDAP library: OpenLDAP 20213) > > under > Linux 2.6.9-55.EL.cernsmp #1 SMP Thu May 10 18:09:56 CEST 2007 x86_64 x86_64 > x86_64 GNU/Linux > > Things used to work until one day when it began to give problems, so it could be > a site network port filtering problem, but our network administrator does not > know how to debug, so we would need any hint on how to trace back the problem. > > The command, which starts working but after some time gets stuck, is: > > ldapsearch -p 2170 -h exp-bdii.cern.ch -x -LLL -b "o=grid" -d -1 > > Of course, we CAN do a telnet on that port and that host. Any help is really > welcome and apreciated. Here is a snippet from the output of the command: -- -- 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

Re: (ITS#5503) Openldap segmentation fault when running syncrepl.
by hyc＠symas.com 09 May '08

09 May '08

zulcss(a)ubuntu.com wrote: > Full_Name: Chuck Short > Version: 2.4.9 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.224.150.216) > > > When running the following scripts openldap crashes when trying to run a > syncrepl from a slave server. The original bug report can be found at: > http://bugs.launchpad.net/bugs/227178. > > Steps to reproduce it: > > 1. Download the attachment in the bug report. > 2. mkdir /home/amg1127/ > 3. Unpack the attachment in the just created directory. > 4. Run the ./create-master-base.sh script. > 5. In one terminal run the run-master-slapd.sh script. > 6. In another terminal create the run-slave-slapd.sh script. > 7. The result will be a segmentation fault in the slave server. > > Thanks > chuck Thanks for the report, too bad you didn't forward it to us sooner. This is now fixed in CVS HEAD. -- -- 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#5504) ldapsearch hangs retrieving info
by Javier.Fernandez＠cern.ch 09 May '08

09 May '08

Full_Name: Javier Fernandez Version: 2.2.13 OS: SL4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (156.35.192.4) Hi, ldapsearch gets stuck retrieving info and after some minutes the following error message is thrown: ldap_result: Can't contact LDAP server (-1) I'm using: ldapsearch -V ldapsearch: @(#) $OpenLDAP: ldapsearch 2.2.13 (May 3 2007 03:01:11) $ root@lxcert-amd64:/scratch/rpmbuild.7430.xx7460/openldap-2.2.13/openldap-2.2.13/build-clients/clients/tools (LDAP library: OpenLDAP 20213) under Linux 2.6.9-55.EL.cernsmp #1 SMP Thu May 10 18:09:56 CEST 2007 x86_64 x86_64 x86_64 GNU/Linux Things used to work until one day when it began to give problems, so it could be a site network port filtering problem, but our network administrator does not know how to debug, so we would need any hint on how to trace back the problem. The command, which starts working but after some time gets stuck, is: ldapsearch -p 2170 -h exp-bdii.cern.ch -x -LLL -b "o=grid" -d -1 Of course, we CAN do a telnet on that port and that host. Any help is really welcome and apreciated. Here is a snippet from the output of the command: ldap_create ldap_url_parse_ext(ldap://exp-bdii.cern.ch:2170) ldap_bind_s ldap_simple_bind_s ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_new_connection ldap_int_open_connection ldap_connect_to_host: TCP exp-bdii.cern.ch:2170 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 128.142.173.206:2170 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 ldap_open_defconn: successful ldap_send_server_request ber_flush: 14 bytes to sd 3 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`........ ldap_result msgid 1 ldap_chkResponseList for msgid=1, all=1 ldap_chkResponseList returns NULL wait4msg (infinite timeout), msgid 1 wait4msg continue, msgid 1, all 1 ** Connections: * host: exp-bdii.cern.ch port: 2170 (default) refcnt: 2 status: Connected last used: Fri May 9 18:19:40 2008 ** Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** Response Queue: Empty ldap_chkResponseList for msgid=1, all=1 ldap_chkResponseList returns NULL ldap_int_select read1msg: msgid 1, all 1 ber_get_next ---snip------ ldap_int_select read1msg: msgid -1, all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 82 03 57 02 01 02 64 0..W...d ldap_read: want=851, got=571 0000: 82 03 50 04 51 47 6c 75 65 43 6c 75 73 74 65 72 ..P.QGlueCluster 0010: 55 6e 69 71 75 65 49 44 3d 67 62 2d 63 65 2d 61 UniqueID=gb-ce-a 0020: 6d 63 2e 61 6d 63 2e 6e 6c 2c 4d 64 73 2d 56 6f mc.amc.nl,Mds-Vo 0030: 2d 6e 61 6d 65 3d 4c 53 47 2d 41 4d 43 2c 4d 64 -name=LSG-AMC,Md 0040: 73 2d 56 6f 2d 6e 61 6d 65 3d 6c 6f 63 61 6c 2c s-Vo-name=local, 0050: 6f 3d 67 72 69 64 30 82 02 f9 30 60 04 0b 6f 62 o=grid0...0`..ob 0060: 6a 65 63 74 43 6c 61 73 73 31 51 04 0e 47 6c 75 jectClass1Q..Glu 0070: 65 43 6c 75 73 74 65 72 54 6f 70 04 0b 47 6c 75 eClusterTop..Glu 0080: 65 43 6c 75 73 74 65 72 04 11 47 6c 75 65 53 63 eCluster..GlueSc 0090: 68 65 6d 61 56 65 72 73 69 6f 6e 04 16 47 6c 75 hemaVersion..Glu 00a0: 65 49 6e 66 6f 72 6d 61 74 69 6f 6e 53 65 72 76 eInformationServ 00b0: 69 63 65 04 07 47 6c 75 65 4b 65 79 30 25 04 0f ice..GlueKey0%.. 00c0: 47 6c 75 65 43 6c 75 73 74 65 72 4e 61 6d 65 31 GlueClusterName1 00d0: 12 04 10 67 62 2d 63 65 2d 61 6d 63 2e 61 6d 63 ...gb-ce-amc.amc 00e0: 2e 6e 6c 30 71 04 12 47 6c 75 65 43 6c 75 73 74 .nl0q..GlueClust 00f0: 65 72 53 65 72 76 69 63 65 31 5b 04 2b 67 62 2d erService1[.+gb- 0100: 63 65 2d 61 6d 63 2e 61 6d 63 2e 6e 6c 3a 32 31 ce-amc.amc.nl:21 0110: 31 39 2f 6a 6f 62 6d 61 6e 61 67 65 72 2d 70 62 19/jobmanager-pb 0120: 73 2d 6d 65 64 69 75 6d 04 2c 67 62 2d 63 65 2d s-medium.,gb-ce- 0130: 61 6d 63 2e 61 6d 63 2e 6e 6c 3a 32 31 31 39 2f amc.amc.nl:2119/ 0140: 6a 6f 62 6d 61 6e 61 67 65 72 2d 70 62 73 2d 65 jobmanager-pbs-e 0150: 78 70 72 65 73 73 30 29 04 13 47 6c 75 65 43 6c xpress0)..GlueCl 0160: 75 73 74 65 72 55 6e 69 71 75 65 49 44 31 12 04 usterUniqueID1.. 0170: 10 67 62 2d 63 65 2d 61 6d 63 2e 61 6d 63 2e 6e .gb-ce-amc.amc.n 0180: 6c 30 82 01 3a 04 0e 47 6c 75 65 46 6f 72 65 69 l0..:..GlueForei 0190: 67 6e 4b 65 79 31 82 01 26 04 18 47 6c 75 65 53 gnKey1..&..GlueS 01a0: 69 74 65 55 6e 69 71 75 65 49 44 3d 4c 53 47 2d iteUniqueID=LSG- 01b0: 41 4d 43 04 3a 47 6c 75 65 43 45 55 6e 69 71 75 AMC.:GlueCEUniqu 01c0: 65 49 44 3d 67 62 2d 63 65 2d 61 6d 63 2e 61 6d eID=gb-ce-amc.am 01d0: 63 2e 6e 6c 3a 32 31 31 39 2f 6a 6f 62 6d 61 6e c.nl:2119/jobman 01e0: 61 67 65 72 2d 70 62 73 2d 6d 65 64 69 75 6d 04 ager-pbs-medium. 01f0: 3b 47 6c 75 65 43 45 55 6e 69 71 75 65 49 44 3d ;GlueCEUniqueID= 0200: 67 62 2d 63 65 2d 61 6d 63 2e 61 6d 63 2e 6e 6c gb-ce-amc.amc.nl 0210: 3a 32 31 31 39 2f 6a 6f 62 6d 61 6e 61 67 65 72 :2119/jobmanager 0220: 2d 70 62 73 2d 65 78 70 72 65 73 73 04 18 47 6c -pbs-express..Gl 0230: 75 65 53 69 74 65 55 6e 69 71 75 ueSiteUniqu ber_get_next failed. wait4msg continue, msgid -1, all 0 ** Connections: * host: exp-bdii.cern.ch port: 2170 (default) refcnt: 2 status: Connected last used: Fri May 9 18:57:52 2008 ** Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** Response Queue: Empty ldap_chkResponseList for msgid=-1, all=0 ldap_chkResponseList returns NULL ldap_int_select ldap_result: Can't contact LDAP server (-1) Thank you very much in advance

1 0

(ITS#5503) Openldap segmentation fault when running syncrepl.
by zulcss＠ubuntu.com 09 May '08

09 May '08

Full_Name: Chuck Short Version: 2.4.9 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.224.150.216) When running the following scripts openldap crashes when trying to run a syncrepl from a slave server. The original bug report can be found at: http://bugs.launchpad.net/bugs/227178. Steps to reproduce it: 1. Download the attachment in the bug report. 2. mkdir /home/amg1127/ 3. Unpack the attachment in the just created directory. 4. Run the ./create-master-base.sh script. 5. In one terminal run the run-master-slapd.sh script. 6. In another terminal create the run-slave-slapd.sh script. 7. The result will be a segmentation fault in the slave server. Thanks chuck

1 0

Re: (ITS#5500) comments in cn=config entries
by h.b.furuseth＠usit.uio.no 09 May '08

09 May '08

hyc(a)symas.com writes: >h.b.furuseth(a)usit.uio.no wrote: >> However the attribute for general notes ('info') should probably be >> treated as X-ORDERED 'VALUES', I haven't checked if it's inconvenient >> to do that with a preexisting attribute without that feature. The >> valsort overlay does, but I don' suggest to require valsort. > > The X-ORDERED flag obviously cannot be added to existing schema > elements; That's why I said "treated as" X-ORDERED (when occurring in cn=config). If that's too cumbersome though: > you need to define a new attribute. An attribute private to OpenLDAP should have a prefix like "olc", but an RFCed attribute must wait till (X-)ORDERED is standardized. I suggest "olc-note", then. Still stands out from the rest since the others do not use hyphens, and also sorts it before the other "olc"s. -- Hallvard

1 0

(ITS#5502) LDAP problem
by javed_ansari＠infosys.com 08 May '08

08 May '08

Full_Name: Javed Ansari Version: 2.3.30 OS: Sun URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.225.64.6) Since yesterday, we are facing LDAP problems while insertion of data. When we try to insert data in the ldap we get the following error: [LDAP: error code 80 - entry store failed] There however seems to be no problem with the login though, this occurs only during registration

1 0

Re: (ITS#5248) non-atomic signal variables
by hyc＠symas.com 08 May '08

08 May '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> As I recall, the only reason we needed the waking counter here was to >> make sure we never filled the pipe buffer, which would cause a >> single-threaded server to deadlock. We can simply set the pipe to >> nonblocking instead, and eliminate the counter. > > Sounds good... > >> The other point was that if there was already a pending wake event, >> there was no reason to write another one. > > Aha! Now the code makes more sense to me:-) And if 'waking' is > just a boolean flag, we can keep it as long as it is treated that way. > > #define WAKE_LISTENER(w) do { \ > if ((w)&& !waking) { \ > waking = 1; \ > tcp_write( SLAP_FD2SOCK(wake_sds[1]), "0", 1 ); \ > } \ > } while (0) > > I need to stare at it a bit to look for race conditions with readers. > I don't suggest to hold next RE24 for this though. It's hardly urgent, > and should be tested a bit --without-threads first. > Actually this can all be simplified even further if you're building --without-threads - in that case, the only WAKE_LISTENER call that matters is the one made from the signal handler. In every other case, the calling function will eventually return and fall back into the main event loop anyway. -- -- 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#5501) syncprov/glue crash with RE24 CVS
by mark.cave-ayland＠siriusit.co.uk 08 May '08

08 May '08

Full_Name: Mark Cave-Ayland Version: 2.4.8cvs-RE24-2008-05-06 OS: RHEL4, x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.207.197.142) Hi there, We've located a segfault in openldap 2.4.8cvs RE24 branch from 2 days ago (which we believe is almost exactly the same as the 2.4.9 release) when using a combination of glue/syncprov. Details from the slapd log and the gdb core file can be found here: http://pastebin.siriusit.co.uk/openldap-bug-20080508.txt More information from the gdb core file can be obtained upon request. Many thanks, Mark.

1 0

Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 07 May '08

07 May '08

Le Jeu 8 mai 2008 00:03, Howard Chu a écrit : > raphael.ouazana(a)linagora.com wrote: >> It is not really hung, it is more in an infinite loop. > > Nothing in this trace indicates a loop; all of the threads are in wait > states. > Is there anything in the logs that indicates a loop? Yes, at least two things: - one CPU is about at 100% - logs from slapd.1.log and slapd.2.log are slowly increasing It seems to be an infinite loop between the first slapd and the second slapd, where the second is always active. I'm sorry I won't be able to access the logs until Tuesday, and all the processes are now killed. Regards, Raphaël Ouazana.

1 0

Re: (ITS#5500) comments in cn=config entries
by hyc＠symas.com 07 May '08

07 May '08

h.b.furuseth(a)usit.uio.no wrote: > One problem with back-config is that comments in slapd.conf > are lost when converting to cn=config, and cn=config does > not offer attributes in which to put comments. So I suggest: > > Add something like 'MAY ( description $ info )' to object class > olcConfig, and slapd.conf keywords with the same name. description > to describe the slapd entry, info for other notes about it. > > The slapd.conf keywords would allow admins to "upgrade" most comments in > slapd.conf before converting to cn=config. They'll need to insert any > context into the comments though, and preferably move frontend directives > with comments in slapd.conf to an explicit frontend database. > > I think it'd be best if these attribute names do not have a prefix > like "olc", so they'll stand out a bit from the rest. Thus the > suggestion to stick to preexisting RFCed attributes. However the > attribute for general notes ('info') should probably be treated as > X-ORDERED 'VALUES', I haven't checked if it's inconvenient to do > that with a preexisting attribute without that feature. The valsort > overlay does, but I don' suggest to require valsort. The X-ORDERED flag obviously cannot be added to existing schema elements; you need to define a new attribute. -- -- 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

← Newer
1
...
14
15
16
17
18
19
20
21
Older →

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 May 2008