[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldap_add do_ldap_select ber_get_next ldap_read ldap_perror

Further research indicates the data is clean.
This problem is related to the order in which the data is loaded.
It's interesting that the server process (slapd) dies.
Best guess is that this problem is caused by a bug in OpenLDAP.
Let me know how I can be of assistance in helping to resolve this.

At 04:07 PM 1/7/2004, Bob Gorman wrote:
Help with this issue will be greatly appreciated!

I have an ldap database that gets created fresh, automatically, every night.
This is done via ldapadd from a source data file on the local hard disk.
A problem has just started occurring which is reproducible.
The load stops at the same record every time in the source data file.
There are less then 2000 records being inserted, no large fields.
If I rearrange the records the problem does not occur.
When the load stops, the slapd process has died, or visa versa.

I'm not sure how much information to include. I can send a sample data set, and the slapd.conf file.  Below is some debug output.

This running on a fully patch RedHat Linux 7.3 (i386) machine, openldap-2.0.27-2.7.3, kernel-2.4.20-28.7.

Where should I look for the problem?

ldap_add
ldap_send_initial_request
ldap_send_server_request
ber_flush: 174 bytes to sd 4
  0000:  30 81 ab 02 02 05 6b 68  81 a4 04 17 75 69 64 3d   0.....kh....uid=
  0010:  50 33 36 37 35 36 37 2c  6f 3d 66 6f 72 65 63 6f   P367567,o=foreco
  0020:  75 72 74 30 81 88 30 1e  04 0b 6f 62 6a 65 63 74   urt0..0...object
  0030:  43 6c 61 73 73 31 0f 04  0d 69 6e 65 74 4f 72 67   Class1...inetOrg
  0040:  50 65 72 73 6f 6e 30 1d  04 04 6d 61 69 6c 31 15   Person0...mail1.
  0050:  04 13 69 67 65 77 75 72  7a 40 68 6f 74 6d 61 69   ..igewurz@hotmai
  0060:  6c 2e 63 6f 6d 30 13 04  02 63 6e 31 0d 04 0b 49   l.com0...cn1...I
  0070:  6c 61 6e 20 47 65 77 75  72 7a 30 10 04 05 74 69   lan Gewurz0...ti
  0080:  74 6c 65 31 07 04 05 50  61 72 74 79 30 0e 04 02   tle1...Party0...
  0090:  73 6e 31 08 04 06 47 65  77 75 72 7a 30 10 04 03   sn1...Gewurz0...
  00a0:  75 69 64 31 09 04 07 50  33 36 37 35 36 37         uid1...P367567
ldap_write: want=174, written=174
  0000:  30 81 ab 02 02 05 6b 68  81 a4 04 17 75 69 64 3d   0.....kh....uid=
  0010:  50 33 36 37 35 36 37 2c  6f 3d 66 6f 72 65 63 6f   P367567,o=foreco
  0020:  75 72 74 30 81 88 30 1e  04 0b 6f 62 6a 65 63 74   urt0..0...object
  0030:  43 6c 61 73 73 31 0f 04  0d 69 6e 65 74 4f 72 67   Class1...inetOrg
  0040:  50 65 72 73 6f 6e 30 1d  04 04 6d 61 69 6c 31 15   Person0...mail1.
  0050:  04 13 69 67 65 77 75 72  7a 40 68 6f 74 6d 61 69   ..igewurz@hotmai
  0060:  6c 2e 63 6f 6d 30 13 04  02 63 6e 31 0d 04 0b 49   l.com0...cn1...I
  0070:  6c 61 6e 20 47 65 77 75  72 7a 30 10 04 05 74 69   lan Gewurz0...ti
  0080:  74 6c 65 31 07 04 05 50  61 72 74 79 30 0e 04 02   tle1...Party0...
  0090:  73 6e 31 08 04 06 47 65  77 75 72 7a 30 10 04 03   sn1...Gewurz0...
  00a0:  75 69 64 31 09 04 07 50  33 36 37 35 36 37         uid1...P367567
ldap_result msgid 1387
ldap_chkResponseList for msgid=1387, all=1
ldap_chkResponseList returns NULL
wait4msg (infinite timeout), msgid 1387
wait4msg continue, msgid 1387, all 1
** Connections:
* host: 127.0.0.1  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Tue Jan  6 11:20:51 2004

** Outstanding Requests:
 * msgid 1387,  origid 1387, status InProgress
   outstanding referrals 0, parent count 0
** Response Queue:
   Empty
ldap_chkResponseList for msgid=1387, all=1
ldap_chkResponseList returns NULL
do_ldap_select
read1msg: msgid 1387, all 1
ber_get_next
ldap_read: want=1, got=0

ldap_perror
ldap_add: Can't contact LDAP server
ldif_record() = 81
ldap_unbind
ldap_free_request (origid 1387, msgid 1387)
ldap_free_connection
ldap_send_unbind
ber_flush: 8 bytes to sd 4
  0000:  30 06 02 02 05 6c 42 00                            0....lB.
ldap_write: want=8, written=8
  0000:  30 06 02 02 05 6c 42 00                            0....lB.
ldap_free_connection: actually freed