openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: ITS#5822 slapd goes into sleeping mode
by ando＠sys-net.it 20 Nov '08

20 Nov '08

There exists no OpenLDAP 2.1 b102. There exists a 2.1 branch, which was obsoleted few years ago. Even if there existed one, you don't provide enough info that could help debugging your issue. Please see <http://www.openldap.org/faq/data/cache/56.html> for details about how to report an issue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5822) slapd goes into sleeping mode
by egarciab＠alcatel-lucent.com 20 Nov '08

20 Nov '08

Full_Name: Eduardo Garcia Version: slapd 2.1 b102 OS: solaris 5.9 URL: ftp://ftp.openldap.org/incoming/traza_mala Submission from: (NULL) (194.113.59.80) Hello, We are using a customized version of the slapd v2.1 b102. The problem that we are seeing in the last days is that the slapd process goes into a sleeping mode, and none ldap request is answered. This problems seems to happend in an intervals of 72 hours more or less. The process slapd is alive, but it seems to be stuck. Last time this problem arised, I run a truss command to get more clues about it. Above these lines, you can find the ooutput of truss and also a snoop of the port 389 in the slapd machine. Could you please look into this problem? Any further info you need , please tell me. Thanks a lot in advance Eduardo PS: we have implemented a local script to verify if the slapd process is up and answering and we could see that in the moment when this problem happens, the slapd did not answer to this local ldap request either. It kept sleeping and running This was the output of the truss command: /1: lwp_wait(2, 0xFFBFFCC4) (sleeping...) /4: lwp_park(0x00000000, 0) (sleeping...) /5: lwp_park(0x00000000, 0) (sleeping...) /7: lwp_park(0x00000000, 0) (sleeping...) /11: lwp_park(0x00000000, 0) (sleeping...) /8: lwp_park(0x00000000, 0) (sleeping...) /12: lwp_park(0x00000000, 0) (sleeping...) /13: lwp_park(0x00000000, 0) (sleeping...) /10: read(15, 0x002E6476, 2064) (sleeping...) /18: lwp_park(0x00000000, 0) (sleeping...) /17: lwp_park(0x00000000, 0) (sleeping...) /16: lwp_park(0x00000000, 0) (sleeping...) /3: lwp_park(0x00000000, 0) (sleeping...) /15: lwp_park(0x00000000, 0) (sleeping...) /9: lwp_park(0x00000000, 0) (sleeping...) /2: poll(0xFE3FD418, 3, -1) (sleeping...) /6: lwp_park(0x00000000, 0) (sleeping...) /14: lwp_park(0x00000000, 0) (sleeping...) I also get a snoop trace in the slapd machine to see which was the messages received and sent from our machine ---> traza_mala file at ftp://ftp.openldap.org/incoming/

1 0

(ITS#5821) Small mistake in man page
by kkalev＠gmail.com 20 Nov '08

20 Nov '08

Full_Name: Kostas Kalevras Version: 2.4.12 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.102.247.100) In the manpage for slapd.conf (slapd.conf.5) in the limits directive description the value for the size.unchecked pattern should be disabled and not disable according to limits.c

1 0

Re: (ITS#5793) RFE for flexible logging at 256/stats level
by ando＠sys-net.it 20 Nov '08

20 Nov '08

michael(a)stroeder.com wrote: > ando(a)sys-net.it wrote: >> Wouldn't it make sense to entirely give up syslog'ging and use >> slapo-accesslog instead? > > Hmm, I think this change would be too radical. I still see some value in > text messages going to syslog. Configuration issues are sometimes more > obvious if you see the syslog messages of LDAP-enabled components and > the LDAP server one after the other in the same log. I meant "give up" by not looking at logs for Gavin's purposes, not to eradicate them from the code. Modifying "stats" logging would not probably be a big issue, if we define a specific mask: one bit for each operation, and one bit for success/failure. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5793) RFE for flexible logging at 256/stats level
by michael＠stroeder.com 20 Nov '08

20 Nov '08

ando(a)sys-net.it wrote: > Wouldn't it make sense to entirely give up syslog'ging and use > slapo-accesslog instead? Hmm, I think this change would be too radical. I still see some value in text messages going to syslog. Configuration issues are sometimes more obvious if you see the syslog messages of LDAP-enabled components and the LDAP server one after the other in the same log. Ciao, Michael.

1 0

(ITS#5820) segfault with slapacl
by ghenry＠OpenLDAP.org 20 Nov '08

20 Nov '08

Full_Name: Gavin Henry Version: 2.4.12 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Hi All, I've just hit this: /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" authcDN: "uid=ghenry,cn=auth" read access to userPassword=: DENIED Segmentation fault gdb: Starting program: /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1208350960 (LWP 10744)] authcDN: "uid=ghenry,cn=auth" read access to userPassword=: DENIED Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208350960 (LWP 10744)] 0x005f70c7 in free () from /lib/libc.so.6 (gdb) bt #0 0x005f70c7 in free () from /lib/libc.so.6 #1 0x00158c0a in ber_memfree_x (p=0x0, ctx=0x0) at memory.c:152 #2 0x08089ee8 in ch_free () #3 0x080d4d3c in slap_tool_destroy () #4 0x080d71a1 in slapacl () #5 0x080564d2 in main () (gdb) q I'm just compiling up HEAD now to test with the latest code and will get back to you. Gavin.

1 0

Re: (ITS#5819) On add, slapd does not add distinguished values if naming attribute already present
by ando＠sys-net.it 19 Nov '08

19 Nov '08

Fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5819) On add, slapd does not add distinguished values if naming attribute already present
by ando＠sys-net.it 19 Nov '08

19 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando To trigger, try # works fine dn: cn=Foo,dc=example,dc=com objectClass: device # error dn: cn=Bar,dc=example,dc=com objectClass: device cn: Foo I'd expect both to succeed, and a "cn" of "Foo" or "Bar" to be automatically added by slapd according to RFC4511 (since "cn" is multi-valued). p.

1 0

Re: (ITS#5793) RFE for flexible logging at 256/stats level
by ghenry＠OpenLDAP.org 19 Nov '08

19 Nov '08

----- "Pierangelo Masarati" <ando(a)sys-net.it> wrote: > ghenry(a)OpenLDAP.org wrote: > > > Just a quick note to say it would be nice to be able to break out > loglevel 256 > > i.e. Log just writes. The same as accesslog config. > > Are you thinking of something like a read/write/auth flag, plus > possibly > a success/failure flag, or a per-operation granularity? Probably the later. It's more to not lot searches, but writes, as 256 can really fill up your logfile. > Wouldn't it make sense to entirely give up syslog'ging and use > slapo-accesslog instead? For some users, yes. But having the phyiscal log is appealing too. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5817) ldapadd crashes with '-' in input
by ando＠sys-net.it 19 Nov '08

19 Nov '08

Jan Safranek wrote: > Pierangelo Masarati wrote: >> I've applied a fix to HEAD code, please test. > > Thanks for a quick fix! Now it prints "ldap_add: Bad parameter to an > ldap routine (-9)", which is a bit better than the assert before. Yes. I modified ldap_add_ext(3) to further validate input parameters instead of crashing. ldapadd(1) needs work in order to intercept the issue earlier and complain as appropriate. I was more concerned by libldap because it might be used in more critical applications than ldapadd(1) itself. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

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