openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#8193) error in ldap logs
by quanah＠zimbra.com 09 Jul '15

09 Jul '15

--On Thursday, July 09, 2015 9:51 AM +0000 JB0035697(a)techmahindra.com wrote: > Full_Name: Bourguignon J-L > Version: 2.4.35 > OS: Sun OS 5.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.89.32.88) > > > Hi all, > > I've searched on the web for this kind of error but I've not find any > relevant answer. > > Is someone can explain what does means this following error : > > slapd(58): setsockopt(SO_KEEPALIVE) failed errno=22 (Invalid argument) > > It seems that when it appears, the process is still running but slapd > process doesn't answer to queries anymore. > > The only way to solve it, it's to restart the process. It would appear you have keepalive settings in your configuration, which are only valid for Linux, as noted in the man page. I will make a SWAG that they were added because you have a firewall breaking connections between clients and the server. As per the ldap_get_option(3) man page: Mainly intended for use with Linux, they may not be portable. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8194) Service slapd falldown in a search with client ldapsearch
by hyc＠symas.com 09 Jul '15

09 Jul '15

richard.larrieu-manan(a)cgi.com wrote: > Full_Name: CGI - Richard Larrieu-Manan > Version: 2.4.41 > OS: Red Hat 4.4.7-4 > URL: ftp://ftp.openldap.org/incoming/CGI_20150709.core.33604.tgz > Submission from: (NULL) (195.6.127.108) > > > Hello, > > When searching in the directory ldap 2.4.41 with ldapsearch client, 1 out of 4 > ldap service falldown. So I have provided you a core dump > (ftp://ftp.openldap.org/incoming/CGI_20150709.core.33604.tgz) during the bug. In > 2.4.38 version of the problem does not arise. Thanks for the report but we cannot use your core file. Please send your slapd configuration and the stack trace from the core. http://www.openldap.org/faq/data/cache/59.html -- -- 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#8194) Service slapd falldown in a search with client ldapsearch
by richard.larrieu-manan＠cgi.com 09 Jul '15

09 Jul '15

Full_Name: CGI - Richard Larrieu-Manan Version: 2.4.41 OS: Red Hat 4.4.7-4 URL: ftp://ftp.openldap.org/incoming/CGI_20150709.core.33604.tgz Submission from: (NULL) (195.6.127.108) Hello, When searching in the directory ldap 2.4.41 with ldapsearch client, 1 out of 4 ldap service falldown. So I have provided you a core dump (ftp://ftp.openldap.org/incoming/CGI_20150709.core.33604.tgz) during the bug. In 2.4.38 version of the problem does not arise. Thank you to consider this anomaly.

1 0

(ITS#8173)
by Adrian.Raemy＠vtg.admin.ch 09 Jul '15

09 Jul '15

--_000_BE8E19527611BA409D68FF6EA186AF9002A27CB3BEREXMBX19ifc1i_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Howard, I could now install the missing debug pakages and below you find the output= of gdb. I did check 6 Dumps where the slapd crashed and always I had the same outpu= t. Now you can see where it crashes. Let me know if you need more...hope you can localize the problem and give a= s a fix. Regards Adrian Reading symbols from /usr/lib/openldap/slapd...Reading symbols from /usr/li= b/debug/usr/lib/slapd.debug...done. done. [New LWP 11777] [New LWP 11778] [New LWP 11823] [New LWP 11821] [New LWP 11970] [New LWP 11826] [New LWP 11824] [New LWP 11775] [New LWP 11971] [New LWP 11776] [New LWP 11785] [New LWP 11820] [New LWP 11825] [New LWP 11822] [New LWP 11827] [New LWP 11828] [New LWP 11972] [New LWP 11788] warning: Could not load shared library symbols for stics. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= s://0.0.0.0:636 -f /etc/op'. Program terminated with signal 11, Segmentation fault. #0 0x00007fcbb60572c6 in ldap_back_bind () (gdb) where #0 0x00007fcbb60572c6 in ldap_back_bind () #1 0x00007fcbb5f47fcb in fe_op_bind () #2 0x00007fcbb5fb66fd in overlay_op_walk () #3 0x00007fcbb5fb6956 in over_op_func () #4 0x00007fcbb5fb69de in over_op_bind () #5 0x00007fcbb5f47697 in do_bind () #6 0x00007fcbb5f1df19 in connection_operation () #7 0x00007fcbb5f1e4e1 in connection_read_thread () #8 0x00007fcbb5a53c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l= ibldap_r-2.4.so.2 #9 0x00007fcbb4e6c806 in start_thread (arg=3D<optimized out>) at pthread_c= reate.c:301 #10 0x00007fcbb36b702d in gnu_dev_makedev (major=3D3066092544, minor=3D<opt= imized out>) at ../sysdeps/unix/sysv/linux/makedev.c:37 #11 0x0000000000000000 in ?? () (gdb) --_000_BE8E19527611BA409D68FF6EA186AF9002A27CB3BEREXMBX19ifc1i_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"DE-CH" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Dear Howard,<o:p></o:p><= /p> <o:p> </o:p> I could now install the missing= debug pakages and below you find the output of gdb.<o:p></o:p> I did check 6 Dumps where the s= lapd crashed and always I had the same output. <o:p></o:p> Now you can see where it crashe= s.<o:p></o:p> <o:p> </o:p> Let me know if you need more&#8= 230;hope you can localize the problem and give as a fix.<o:p></o:p><= /p> <o:p> </o:p> Regards<o:p></o:p> Adrian<o:p></o:p> <o:p> </o:p> Reading symbols from /usr/lib/o= penldap/slapd...Reading symbols from /usr/lib/debug/usr/lib/slapd.debug...d= one.<o:p></o:p> done.<o:p></o:p> [New LWP 11777]<o:p></o:p></spa= n> [New LWP 11778]<o:p></o:p></spa= n> [New LWP 11823]<o:p></o:p></spa= n> [New LWP 11821]<o:p></o:p></spa= n> [New LWP 11970]<o:p></o:p></spa= n> [New LWP 11826]<o:p></o:p></spa= n> [New LWP 11824]<o:p></o:p></spa= n> [New LWP 11775]<o:p></o:p></spa= n> [New LWP 11971]<o:p></o:p></spa= n> [New LWP 11776]<o:p></o:p></spa= n> [New LWP 11785]<o:p></o:p></spa= n> [New LWP 11820]<o:p></o:p></spa= n> [New LWP 11825]<o:p></o:p></spa= n> [New LWP 11822]<o:p></o:p></spa= n> [New LWP 11827]<o:p></o:p> [New LWP 11828]<o:p></o:p></spa= n> [New LWP 11972]<o:p></o:p></spa= n> [New LWP 11788]<o:p></o:p></spa= n> <o:p> </o:p> warning: Could not load shared = library symbols for stics.<o:p></o:p> Do you need "set solib-sea= rch-path" or "set sysroot"?<o:p></o:p> [Thread debugging using libthre= ad_db enabled]<o:p></o:p> Using host libthread_db library= "/lib64/libthread_db.so.1".<o:p></o:p> Core was generated by `/usr/lib= /openldap/slapd -h  ldap://0.0.0.0:389  ldaps://0.0.0.0:636 = -f /etc/op'.<o:p></o:p> Program terminated with signal = 11, Segmentation fault.<o:p></o:p> #0  0x00007fcbb60572c6 in = ldap_back_bind ()<o:p></o:p> (gdb) where<o:p></o:p></= p> #0  0x00007fcbb60572c6 in = ldap_back_bind ()<o:p></o:p> #1  0x00007fcbb5f47fcb in fe_op_bind ()<o:p></o= :p> #2  0x00007fcbb5fb66fd in = overlay_op_walk ()<o:p></o:p> #3  0x00007fcbb5fb6956 in = over_op_func ()<o:p></o:p> #4  0x00007fcbb5fb69de in = over_op_bind ()<o:p></o:p> #5  0x00007fcbb5f47697 in = do_bind ()<o:p></o:p> #6  0x00007fcbb5f1df19 in = connection_operation ()<o:p></o:p> #7  0x00007fcbb5f1e4e1 in = connection_read_thread ()<o:p></o:p> #8  0x00007fcbb5a53c3c in = ldap_int_thread_pool_wrapper () from /usr/lib64/libldap_r-2.4.so.2<o:p></o:= p> #9  0x00007fcbb4e6c806 in = start_thread (arg=3D<optimized out>) at pthread_create.c:301<o:p></o:= p> #10 0x00007fcbb36b702d in gnu_d= ev_makedev (major=3D3066092544, minor=3D<optimized out>) at ../sysdep= s/unix/sysv/linux/makedev.c:37<o:p></o:p> #11 0x0000000000000000 in ?? ()<o:p></o:p> (gdb)<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html> --_000_BE8E19527611BA409D68FF6EA186AF9002A27CB3BEREXMBX19ifc1i_--

1 0

(ITS#8193) error in ldap logs
by JB0035697＠techmahindra.com 09 Jul '15

09 Jul '15

Full_Name: Bourguignon J-L Version: 2.4.35 OS: Sun OS 5.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.89.32.88) Hi all, I've searched on the web for this kind of error but I've not find any relevant answer. Is someone can explain what does means this following error : slapd(58): setsockopt(SO_KEEPALIVE) failed errno=22 (Invalid argument) It seems that when it appears, the process is still running but slapd process doesn't answer to queries anymore. The only way to solve it, it's to restart the process. Thx in advance for help. Brgds, Jean-Luc.

1 0

Re: (ITS#8188) unable to see the users on client after importing the TLS certificate
by quanah＠zimbra.com 08 Jul '15

08 Jul '15

--On Friday, July 03, 2015 2:53 PM +0000 vijeshkrishna(a)yahoo.com wrote: > Full_Name: Vijesh > Version: 2.4 > OS: RHEL 6.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.219.201.69) > > > Hello Team, Hello, The ITS system is for reporting bugs, not asking usage questions. Please direct your questions to the openldap-technical(a)openldap.org email list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8192) liblmdb confuses Windows error code with errno values
by h.b.furuseth＠usit.uio.no 08 Jul '15

08 Jul '15

Typo in original report: > #define MDB_FILE_NEW (MDB_LAST_ERRCODE + 9) > (above instead of MDB_NO_ROOT for easier cherry-picking.) "above instead of below MDB_NO_ROOT". On 08/07/15 22:36, Howard Chu wrote: > When there is a platform-specific error code that describes the > situation, we should use it. In particular, if the error code comes from > an underlying system call and accurately describes that failure, we > should pass it through. Yes. I only meant to talk about where mdb.c explicitly picks errno codes, like it does with EIO/ENOSPC. (And where it compares codes from system calls with errno codes.) > If the failure is LMDB-specific, and not related > to any particular system call, then we should define an MDB_* code for it.

1 0

Re: (ITS#8192) liblmdb confuses Windows error code with errno values
by hyc＠symas.com 08 Jul '15

08 Jul '15

h.b.furuseth(a)usit.uio.no wrote: > On 08/07/15 20:29, h.b.furuseth(a)usit.uio.no wrote: >> Finally, I suggest we replace the explicit EIO/ENOSPC returns >> with either a new MDB code or #define MDB_EIO EIO on Unix >> and something else on Windows. > > I mean, without waiting for LMDB-1.*. They are fairly > obscure errors, I doubt anyone is testing for them. When there is a platform-specific error code that describes the situation, we should use it. In particular, if the error code comes from an underlying system call and accurately describes that failure, we should pass it through. If the failure is LMDB-specific, and not related to any particular system call, then we should define an MDB_* code for it. -- -- 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#8192) liblmdb confuses Windows error code with errno values
by h.b.furuseth＠usit.uio.no 08 Jul '15

08 Jul '15

On 08/07/15 20:29, h.b.furuseth(a)usit.uio.no wrote: > Finally, I suggest we replace the explicit EIO/ENOSPC returns > with either a new MDB code or #define MDB_EIO EIO on Unix > and something else on Windows. I mean, without waiting for LMDB-1.*. They are fairly obscure errors, I doubt anyone is testing for them.

1 0

(ITS#8192) liblmdb confuses Windows error code with errno values
by h.b.furuseth＠usit.uio.no 08 Jul '15

08 Jul '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.15 OS: Windows 7 with cygwin URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_env_write_meta() loops to retry_write if ErrCode() == EINTR. That's ERROR_TOO_MANY_OPEN_FILES = 4 on Windows. New in 0.9.15. == This one is older, in mdb_env_setup_locks(). Also wrong on Windows: rc = ErrCode(); if (rc && rc != EACCES && rc != EAGAIN) I don't know what that code is doing. I think that belongs under if ((rc = mdb_env_excl_lock(env, excl))) goto fail; where it would read as if (*excl <= 0 && (rc = ErrCode()) && rc != EACCES && rc != EAGAIN) ==D%D ENOENT confusion: mdb_env_read_header() can explicitly return ENOENT, but only as an internal code. So mdb_strerror() should drop ENOENT. We can rename/renumber it to avoid confusion: /* Internal result codes, not exposed outside liblmdb */ #define MDB_FILE_NEW (MDB_LAST_ERRCODE + 9) (above instead of MDB_NO_ROOT for easier cherry-picking.) OTOH lmdb.h lists "ENOENT - the directory specified by the path parameter doesn't exist." That's not related to the above. It should be "ENOENT (Unix) or ERROR_PATH_NOT_FOUND (Windows) - ..." Or maybe the doc for this code should say something more general, or simply be omitted. I found the Windows code by testing @ Windows. Reading Windows doc did not help. == Finally, I suggest we replace the explicit EIO/ENOSPC returns with either a new MDB code or #define MDB_EIO EIO on Unix and something else on Windows. (I think ENOSPC should be EIO too, there could be other reasons for a short write.) Then we can drop those from mdb_strerror() too.

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