Hi
Since quite some time I have problems with two applications
Here are the relevant links about the OpenLDAP related SIGSEGV issue:
FreeBSD Forum:
OpenLDAP Mailing List:
So my question is: Does FreeBSD still have this problem with the stack size? Or has this bug been fixed already? Is there a way to get at least OpenLDAP run stable enough for production usage with workaround(s)? Cause currently is just no way to use it, since it dies after seconds after the slapd service got started.
P.S.: Might setrlimit(2) be an option for OpenLDAP to use in order to request a larger maximum stack size?
Also, I just checked via ldd(1). It looks like slapd is successfully linked to /lib/libthr.so.3
Since quite some time I have problems with two applications
- OpenLDAP
- Munin
- Munin runs with more than around 100 plug-ins and about 150 graphs (times 4x, for day, week, month, year).
- OpenLDAP actually does not have that much of an workload. Regular PAM via nslcd(8). Some crashes happened every couple of hours or even only days. I wrote a supervisor script, in order to have a workaround for production usage. But since the mail server (Dovecot & Postfix) are connected to it - LDAP crashes with segmentation fault after a few seconds of work. Notice, that there is only one single test user connected. So now I am at the point where my logs are flooded with connection errors more then with successful connections. The workaround does not qualify to be usable any longer.
Here are the relevant links about the OpenLDAP related SIGSEGV issue:
FreeBSD Forum:
OpenLDAP Mailing List:
- http://www.openldap.org/lists/openldap-technical/201504/msg00220.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00228.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00237.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00241.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00238.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00239.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00248.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00249.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00250.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00254.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00255.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00256.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00257.html
- http://www.openldap.org/lists/openldap-technical/201504/msg00282.html
- http://www.openldap.org/lists/openldap-bugs/200506/msg00174.html
- http://lists.freebsd.org/pipermail/freebsd-current/2014-August/051646.html
So my question is: Does FreeBSD still have this problem with the stack size? Or has this bug been fixed already? Is there a way to get at least OpenLDAP run stable enough for production usage with workaround(s)? Cause currently is just no way to use it, since it dies after seconds after the slapd service got started.
P.S.: Might setrlimit(2) be an option for OpenLDAP to use in order to request a larger maximum stack size?
Also, I just checked via ldd(1). It looks like slapd is successfully linked to /lib/libthr.so.3
Code:
root@FreeBSD [~]$ ldd /usr/local/libexec/slapd
/usr/local/libexec/slapd:
libldap_r-2.4.so.2 => /usr/local/lib/libldap_r-2.4.so.2 (0x8009a7000)
liblber-2.4.so.2 => /usr/local/lib/liblber-2.4.so.2 (0x800bf5000)
libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x800e03000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x80100c000)
libwrap.so.6 => /usr/lib/libwrap.so.6 (0x80122c000)
libssl.so.7 => /usr/lib/libssl.so.7 (0x801435000)
libcrypto.so.7 => /lib/libcrypto.so.7 (0x8016a0000)
libthr.so.3 => /lib/libthr.so.3 (0x801a93000)
libc.so.7 => /lib/libc.so.7 (0x801cb8000)
Code:
root@FreeBSD [~]$ ls -lach /lib/libthr.so.3
-r--r--r-- 1 root wheel 103K 18 Jan 15:36 /lib/libthr.so.3