Re: (ITS#5504) ldapsearch hangs retrieving info
by hyc＠symas.com
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/
14 years, 10 months
Re: (ITS#5503) Openldap segmentation fault when running syncrepl.
by hyc＠symas.com
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/
14 years, 10 months
(ITS#5504) ldapsearch hangs retrieving info
by Javier.Fernandez＠cern.ch
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
14 years, 10 months
(ITS#5503) Openldap segmentation fault when running syncrepl.
by zulcss＠ubuntu.com
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
14 years, 10 months
Re: (ITS#5500) comments in cn=config entries
by h.b.furuseth＠usit.uio.no
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
14 years, 10 months
(ITS#5502) LDAP problem
by javed_ansari＠infosys.com
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
14 years, 10 months
Re: (ITS#5248) non-atomic signal variables
by hyc＠symas.com
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/
14 years, 10 months
Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com
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.
14 years, 10 months
Re: (ITS#5500) comments in cn=config entries
by hyc＠symas.com
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/
14 years, 10 months
