Hi there,
I've MMR running on two FreeBSD servers with OpenLDAP 2.4.47. After few days one node always crash with signal 11.
The last log I got from slapd is:
Jul 17 18:04:19 slapd[676]: syncprov_matchops: skipping original sid 001
When I try to restart the slapd process it eats all the ram memory, until the server become irresponsible. I have to delete the database and re-sync everything to make it works again.
Is there a way to find out how can I fix this issue?
Thanks.
Alex Hebra wrote:
Hi there,
I've MMR running on two FreeBSD servers with OpenLDAP 2.4.47. After few days one node always crash with signal 11.
The last log I got from slapd is:
Jul 17 18:04:19 slapd[676]: syncprov_matchops: skipping original sid 001
When I try to restart the slapd process it eats all the ram memory, until the server become irresponsible. I have to delete the database and re-sync everything to make it works again.
Is there a way to find out how can I fix this issue?
Attach to the running slapd with gdb and let it run, then examine the stack trace when it gets the SIGSEGV,
# gdb /usr/local/libexec/slapd GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) run -h ldaps://10.138.138.216 ldap://127.0.0.1 ldaps://127.0.0.1 -u ldap -g ldap Starting program: /usr/local/libexec/slapd -h ldaps://10.138.138.216 ldap:// 127.0.0.1 ldaps://127.0.0.1 -u ldap -g ldap (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...usage: /usr/local/libexec/slapd options -4 IPv4 only -6 IPv6 only -T {acl|add|auth|cat|dn|index|passwd|test} Run in Tool mode -c cookie Sync cookie of consumer -d level Debug level -f filename Configuration file -F dir Configuration directory -g group Group (id or name) to run as -h URLs List of URLs to serve -l facility Syslog facility (default: LOCAL4) -n serverName Service name -o <opt>[=val] generic means to specify options; supported options: slp[={on|off|(attrs)}] enable/disable SLP using (attrs) -r directory Sandbox directory to chroot to -s level Syslog level -u user User (id or name) to run as -V print version info (-VV exit afterwards, -VVV print info about static overlays and backends)
Program exited with code 01. Current language: auto; currently minimal
Am I missing something?
Thanks.
On Thu, Jul 18, 2019 at 7:44 PM Howard Chu hyc@symas.com wrote:
Alex Hebra wrote:
Hi there,
I've MMR running on two FreeBSD servers with OpenLDAP 2.4.47. After few
days one node always crash with signal 11.
The last log I got from slapd is:
Jul 17 18:04:19 slapd[676]: syncprov_matchops: skipping original sid 001
When I try to restart the slapd process it eats all the ram memory,
until the server become irresponsible. I have to delete the database and re-sync everything
to make it works again.
Is there a way to find out how can I fix this issue?
Attach to the running slapd with gdb and let it run, then examine the stack trace when it gets the SIGSEGV,
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Alex Hebra wrote:
# gdb /usr/local/libexec/slapd GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) run -h ldaps://10.138.138.216 http://10.138.138.216 ldap://127.0.0.1 http://127.0.0.1 ldaps://127.0.0.1 http://127.0.0.1 -u ldap -g ldap Starting program: /usr/local/libexec/slapd -h ldaps://10.138.138.216 http://10.138.138.216 ldap://127.0.0.1 http://127.0.0.1 ldaps://127.0.0.1 http://127.0.0.1 -u ldap -g ldap (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...usage: /usr/local/libexec/slapd options
Program exited with code 01. Current language: auto; currently minimal
Am I missing something?
Apparently. Re-read the slapd(8) manpage for proper option syntax.
Also, if you had actually done what I said - attach to an already running slapd - you wouldn't have had this problem. Following instructions is a pretty fundamental skill.
If you want to start under gdb you're also going to need a debug flag, otherwise it will just fork/exit out from under you.
Thanks.
On Thu, Jul 18, 2019 at 7:44 PM Howard Chu <hyc@symas.com mailto:hyc@symas.com> wrote:
Alex Hebra wrote: > Hi there, > > I've MMR running on two FreeBSD servers with OpenLDAP 2.4.47. After few days one node always crash with signal 11. > > The last log I got from slapd is: > > Jul 17 18:04:19 slapd[676]: syncprov_matchops: skipping original sid 001 > > When I try to restart the slapd process it eats all the ram memory, until the server become irresponsible. I have to delete the database and re-sync everything > to make it works again. > > Is there a way to find out how can I fix this issue? Attach to the running slapd with gdb and let it run, then examine the stack trace when it gets the SIGSEGV,
Ok, thanks.
On Fri, Jul 19, 2019 at 11:55 AM Howard Chu hyc@symas.com wrote:
Alex Hebra wrote:
# gdb /usr/local/libexec/slapd GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging
symbols found)...
(gdb) run -h ldaps://10.138.138.216 http://10.138.138.216 ldap://
127.0.0.1 http://127.0.0.1 ldaps://127.0.0.1 http://127.0.0.1 -u ldap -g ldap
Starting program: /usr/local/libexec/slapd -h ldaps://10.138.138.216 <
http://10.138.138.216%3E ldap://127.0.0.1 http://127.0.0.1 ldaps:// 127.0.0.1
http://127.0.0.1 -u ldap -g ldap (no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...usage: /usr/local/libexec/slapd options
Program exited with code 01. Current language: auto; currently minimal
Am I missing something?
Apparently. Re-read the slapd(8) manpage for proper option syntax.
Also, if you had actually done what I said - attach to an already running slapd - you wouldn't have had this problem. Following instructions is a pretty fundamental skill.
If you want to start under gdb you're also going to need a debug flag, otherwise it will just fork/exit out from under you.
Thanks.
On Thu, Jul 18, 2019 at 7:44 PM Howard Chu <hyc@symas.com <mailto:
hyc@symas.com>> wrote:
Alex Hebra wrote: > Hi there, > > I've MMR running on two FreeBSD servers with OpenLDAP 2.4.47.After few days one node always crash with signal 11.
> > The last log I got from slapd is: > > Jul 17 18:04:19 slapd[676]: syncprov_matchops: skipping originalsid 001
> > When I try to restart the slapd process it eats all the rammemory, until the server become irresponsible. I have to delete the database and re-sync
everything > to make it works again. > > Is there a way to find out how can I fix this issue? Attach to the running slapd with gdb and let it run, then examinethe stack trace when it
gets the SIGSEGV,-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
openldap-technical@openldap.org
-
Alex Hebra -
Howard Chu