openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

We are in luck. I started fresh with my two servers (deleted the data and repopulated). During the INITIAL sync-up on "server1" (receiving data from server2): <= index_entry_add( 225, "krb5PrincipalName=host/seven.relay.example.com(a)RELAY.EXAMPLE.COM ,cn=RELAY.EXAMPLE.COM,cn=gssapi,cn=auth,dc=real,dc=example,dc=com" ) success => entry_encode(0x000000e1): <= entry_encode(0x000000e1): => acl_get: [2] matched => acl_get: [2] attr userPassword => match[dn0]: 0 60 uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com => match[dn1]: 0 3 uid => match[dn2]: 4 14 plainproxy => acl_mask: access to entry "uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com", attr "userPassword" requested => acl_mask: to value by "", (=0) <= check a_dn_pat: self <= check a_dn_pat: uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com <= check a_dn_pat: uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com <= check a_dn_pat: anonymous <= acl_mask: [4] applying auth(=xd) (stop) <= acl_mask: [4] mask: auth(=xd) => slap_access_allowed: auth access granted by auth(=xd) => access_allowed: auth access granted by auth(=xd) conn=1 op=1 BIND dn="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" mech=SIMPLE ssf=0 do_bind: v3 bind: "uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" to "uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" send_ldap_result: conn=1 op=1 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=2 tag=97 err=0 ber_flush2: 22 bytes to sd 33 0000: 30 84 00 00 00 10 02 01 02 61 84 00 00 00 07 0a 0........a...... 0010: 01 00 04 00 04 00 ...... tls_write: want=101, written=101 0000: 17 03 02 00 60 3e 98 2a 48 b2 d9 ae 12 70 ab db ....`>.*H....p.. 0010: 5e 46 c2 ef 7f c3 32 72 d4 41 ef 4d 58 07 d0 50 ^F.... 2r.A.MX..P 0020: 53 a2 da 54 69 d7 1c 61 ed a7 ce 53 14 16 46 73 S..Ti..a...S..Fs 0030: 91 74 c4 92 9e 35 24 84 ce 8c 6f 18 18 6a 68 0a .t... 5$...o..jh. 0040: b0 69 70 75 0d 6a 5d fa 02 38 89 e9 d7 99 c9 99 .ipu.j].. 8...... 0050: bb 7b be 62 5d 50 91 2f a9 a2 6e d5 88 47 f8 ed .{.b] P./..n..G.. 0060: 5e 3c a7 dd 17 ^<... ldap_write: want=22, written=22 0000: 30 84 00 00 00 10 02 01 02 61 84 00 00 00 07 0a 0........a...... 0010: 01 00 04 00 04 00 ...... daemon: activity on 1 descriptor daemon: activity on: 33r daemon: read active on 33 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero daemon: epoll: listen=10 active_threads=0 tvp=zero daemon: epoll: listen=11 active_threads=0 tvp=zero connection_get(33) connection_get(33): got connid=1 connection_read(33): checking for input on id=1 ber_get_next tls_read: want=5, got=5 0000: 17 03 02 00 c0 ..... tls_read: want=192, got=192 0000: 60 a2 1b 5e 6f 13 18 52 f1 86 c7 b5 ff ae ec bf `..^o..R........ 0010: 7e 7f 65 19 30 c0 4a 3a 7d de 76 77 5b bf 0b dc ~.e. 0.J:}.vw[... 0020: 22 15 34 f9 5b dd 2d 8f f5 19 e3 25 0d 25 a8 b6 ".4. [.-....%.%.. 0030: 07 34 75 a5 08 c6 3e c2 8e 18 58 11 ee 5d 25 7c . 4u...>...X..]%| 0040: 00 9b fb 14 a4 9c 7d c1 37 bf 92 f7 ee ef 04 94 ......}. 7....... 0050: 81 a8 98 d8 eb 5b 80 0f ce 7d 21 3c 24 fa ba ca ..... [...}!<$... 0060: 3f 9a 94 ef dd 7f 47 17 e0 f2 cb 08 04 a5 25 a3 ?.....G.......%. 0070: f0 3e 92 a4 75 a2 6e d3 34 1a 82 29 7b 9f b0 07 .>..u.n. 4..){... 0080: fd 4e 5f 1e 8f f2 55 33 c5 eb 5f 34 a1 f6 3d 0a .N_...U3.._4..=. 0090: c3 e7 4f 4a 77 85 a5 1e 40 f8 d4 60 8e bd 08 8c ..OJw...@..`.... 00a0: 8e 87 7d 93 50 11 da c1 ea b0 e1 74 60 34 ad b8 ..}.P......t`4.. 00b0: c0 9a f3 66 44 3c e5 bf 6e b1 4f 4f f8 51 18 df ...fD<..n.OO.Q.. ldap_read: want=8, got=8 0000: 30 53 02 01 03 63 4e 04 0S...cN. ldap_read: want=77, got=77 0000: 2e 63 6e 3d 70 6c 61 69 6e 2c 63 6e 3d 61 75 74 .cn=plain,cn=aut 0010: 68 2c 64 63 3d 76 65 72 69 6f 2c 64 63 3d 61 6e h,dc=relay,dc=ex 0020: 6f 6e 79 6d 69 7a 65 72 2c 64 63 3d 63 6f 6d 0a ample ,dc=com. 0030: 01 01 0a 01 00 02 01 01 02 01 00 01 01 00 a3 0b ................ 0040: 04 03 75 69 64 04 04 72 6f 6f 74 30 00 ..uid..root0. ber_get_next: tag 0x30 len 83 contents: ber_dump: buf=0x2a0d1d0 ptr=0x2a0d1d0 end=0x2a0d223 len=83 0000: 02 01 03 63 4e 04 2e 63 6e 3d 70 6c 61 69 6e 2c ...cN..cn=plain, 0010: 63 6e 3d 61 75 74 68 2c 64 63 3d 76 65 72 69 6f cn=auth,dc=relay 0020: 2c 64 63 3d 61 6e 6f 6e 79 6d 69 7a 65 72 2c 64 ,dc=example,dc=com 0030: 63 3d 63 6f 6d 0a 01 01 0a 01 00 02 01 01 02 01 ........... 0040: 00 01 01 00 a3 0b 04 03 75 69 64 04 04 72 6f 6f ........uid..roo 0050: 74 30 00 t0. op tag 0x63, time 1255629604 connection_input: conn=1 deferring operation: binding ber_get_next tls_read: want=5 error=Resource temporarily unavailable ldap_read: want=8, got=0 daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero daemon: epoll: listen=10 active_threads=0 tvp=zero daemon: epoll: listen=11 active_threads=0 tvp=zero Segmentation fault <--------- HERE IT IS Again, this was just the initial sync-up. Jeff

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

I can - I just wish it wasn't a segfault for no reason. I was not doing any "write testing" at the time of the crash, so I have no idea what will trigger it. Nevertheless, I'll put slapd into trace mode and watch the logs, and will post anything of importance. Thanks again, Jeff On Oct 15, 2009, at 10:49 , Quanah Gibson-Mount wrote: > --On Thursday, October 15, 2009 5:43 PM +0000 j(a)telepaths.org wrote: > >> OK, problems: >> >> slapd just crashed for no apparent reason. >> >> slapd[8131]: segfault at 433e8a00 ip 433e8a00 sp 433e89a8 error 15 >> >> Not good. What version of slapd should I be using to guarantee: >> >> * No deadlocks >> * No replication errors >> * No SEGFAULTS >> >> It just seems like one buggy slapd release after another. Never >> happened with 2.3 releases ..... > > I assume you have core dumps enabled, and built OpenLDAP with > debugging symbols, and can provide the full backtrace of the > generated core? > > --Quanah > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

hang during ldapmodify?
by Mark Dieterich 15 Oct '09

15 Oct '09

Hi all, I'm not sure if this is a bug or we are doing something wrong. For quite some time now, we have been using ldap to provide group information for our linux/unix desktop machines. I believer there are multiple methods of providing group access, this is the format we are using: # foobar, group, cs.brown.edu dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu objectClass: posixGroup objectClass: top cn: ugrad gidNumber: 1200 memberUid: t1 memberUid: t2 memberUid: t3 memberUid: t4 memberUid: t5 . . . Up until recently, this had been working great. We are now experiencing hangs whenever we try to update the records with one particular group. I think the hangs are occur when we try to feed too much data to ldapmodify at a time. For instance, if I have the above group and try to apply the following ldif file: dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu changetype: modify replace: memberUid memberUid: t1 memberUid: t2 memberUid: t3 memberUid: t4 memberUid: t5 memberUid: t6 memberUid: t7 memberUid: t8 memberUid: t9 . . . memberUid: t2477 memberUid: t2478 memberUid: t2479 The update simply hangs. Tossing a "-d 65535" shows that the process is sitting in loop spitting out messages similar to: ldap_int_select ldap_result ld 0x1e72bf0 msgid 5 wait4msg ld 0x1e72bf0 msgid 5 (timeout 100000 usec) wait4msg continue ld 0x1e72bf0 msgid 5 all 1 ** ld 0x1e72bf0 Connections: * host: ldapmaster.cs.brown.edu port: 6360 (default) refcnt: 2 status: Connected last used: Thu Oct 15 10:27:45 2009 ** ld 0x1e72bf0 Outstanding Requests: * msgid 5, origid 5, status InProgress outstanding referrals 0, parent count 0 ld 0x1e72bf0 request count 1 (abandoned 0) ** ld 0x1e72bf0 Response Queue: Empty ld 0x1e72bf0 response count 0 ldap_chkResponseList ld 0x1e72bf0 msgid 5 all 1 ldap_chkResponseList returns ld 0x1e72bf0 NULL ldap_int_select Hopefully, this means something more to someone on this list than it does to me;) Interestingly, if I drop the last entry and change the ldif file to be: dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu changetype: modify replace: memberUid memberUid: t1 memberUid: t2 memberUid: t3 memberUid: t4 memberUid: t5 memberUid: t6 memberUid: t7 memberUid: t8 memberUid: t9 . . . memberUid: t2476 memberUid: t2477 memberUid: t2478 Then the update proceeds. However, if I change the last entry to read: memberUid: t2478000 Then it hangs again. Whereas with the last entry of memberUid: t247800 it updates just fine. This smells of some buffer filling or something else similar. We are running with debian's lenny version of openldap, version 2.4.11-1 (not sure what's different about the "-1" version). Other details which may be pertinent: - we are running back_bdb - syncprov - GSSAPI authentication I have not tried setting up a test server running 2.4.16/19, but did spend time looking through the chnage logs and bug system and didn't see anything that appeared to apply. However, I certainly could have missed something. Any help would be most appreciated, as we currently have one group which we are no longer able to add any entries to. Thanks! Mark

2 1

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by quanah＠zimbra.com 15 Oct '09

15 Oct '09

--On Thursday, October 15, 2009 5:43 PM +0000 j(a)telepaths.org wrote: > OK, problems: > > slapd just crashed for no apparent reason. > > slapd[8131]: segfault at 433e8a00 ip 433e8a00 sp 433e89a8 error 15 > > Not good. What version of slapd should I be using to guarantee: > > * No deadlocks > * No replication errors > * No SEGFAULTS > > It just seems like one buggy slapd release after another. Never > happened with 2.3 releases ..... I assume you have core dumps enabled, and built OpenLDAP with debugging symbols, and can provide the full backtrace of the generated core? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

OK, problems: slapd just crashed for no apparent reason. slapd[8131]: segfault at 433e8a00 ip 433e8a00 sp 433e89a8 error 15 Not good. What version of slapd should I be using to guarantee: * No deadlocks * No replication errors * No SEGFAULTS It just seems like one buggy slapd release after another. Never happened with 2.3 releases ..... Jeff

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

My apologies On Oct 15, 2009, at 10:26 , Quanah Gibson-Mount wrote: > --On Thursday, October 15, 2009 10:19 AM -0700 Jeff Doyle <j(a)telepaths.org > > wrote: > >> Thank you Gibson, my checkpoints (both definitions) have not changed >> since you last asked, but the fact that it can help with shutdown >> times >> is a very useful tip, thanks! >> >> Jeff > > Just to note, my first name is "Quanah", not "Gibson". "Gibson- > Mount" is my last name. > > Which is why I sign my emails thusly: > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by quanah＠zimbra.com 15 Oct '09

15 Oct '09

--On Thursday, October 15, 2009 10:19 AM -0700 Jeff Doyle <j(a)telepaths.org> wrote: > Thank you Gibson, my checkpoints (both definitions) have not changed > since you last asked, but the fact that it can help with shutdown times > is a very useful tip, thanks! > > Jeff Just to note, my first name is "Quanah", not "Gibson". "Gibson-Mount" is my last name. Which is why I sign my emails thusly: --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

Thank you Gibson, my checkpoints (both definitions) have not changed since you last asked, but the fact that it can help with shutdown times is a very useful tip, thanks! Jeff

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by quanah＠zimbra.com 15 Oct '09

15 Oct '09

--On Thursday, October 15, 2009 4:50 PM +0000 j(a)telepaths.org wrote: > OK, I believe the dead-lock issue is solved, however OCCASIONALLY when > attempting a restart or stop of the slapd process, it throws an error > saying 'slapd stop failed', however the slapd process does quit as > expected, so its a "false failure". > > The one possibility for the reason this is happening, aside from > blaming slapd, is that my two test boxes are VMs ... so I kind of > expect sluggish responses, especially on a VMware server as busy as > ours. I will note that our production LDAP servers are NOT VMs and > will never be ;-) > > I believe you were correct, Pierangelo. I will post my findings over > the next fews days to keep everyone in the loop. Probably the issue. Make sure you have checkpoints defined for all bdb/hdb databases as well, which will help with shutdown times. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

OK, I believe the dead-lock issue is solved, however OCCASIONALLY when attempting a restart or stop of the slapd process, it throws an error saying 'slapd stop failed', however the slapd process does quit as expected, so its a "false failure". The one possibility for the reason this is happening, aside from blaming slapd, is that my two test boxes are VMs ... so I kind of expect sluggish responses, especially on a VMware server as busy as ours. I will note that our production LDAP servers are NOT VMs and will never be ;-) I believe you were correct, Pierangelo. I will post my findings over the next fews days to keep everyone in the loop. Thanks, Jeff

1 0

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