Hello!
At one of our customers, the “slapd.service” stops working at irregular intervals (approx. 3 to 8 days). Of course, this always results in various subsequent errors.
Unfortunately, I have not yet been successful in finding the cause.
At the moment, I don’t have much information that I can provide.
Host:
KVM-VM
DISTRIB_ID=Univention
DISTRIB_RELEASE=“5.0-4 errata771”
DISTRIB_DESCRIPTION=“Univention Corporate Server 5.0-4 errata771”
PRETTY_NAME=“Debian GNU/Linux 10 (buster)”
NAME=“Debian GNU/Linux”
CPU(s): 4
Thread(s) per core: 1
# free -g -t
total used free shared buff/cache available
Mem: 7 1 3 0 2 6
Swap: 3 0 3
Total: 11 1 7
I examined a core dump with “gdb”. Unfortunately, this didn’t really help me:
# gdb /usr/sbin/slapd /core
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/slapd...(no debugging symbols found)...done.
[New LWP 563]
[New LWP 22475]
[New LWP 22476]
[New LWP 8998]
[New LWP 562]
[New LWP 24422]
[New LWP 24421]
[New LWP 22487]
[New LWP 8999]
[New LWP 24416]
[New LWP 561]
[New LWP 24419]
[New LWP 22594]
[New LWP 24420]
[New LWP 22474]
[New LWP 24418]
[New LWP 24417]
[New LWP 22595]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/slapd -h ldapi:/// ldap://:7389/ ldaps://:7636/ -f /etc/ldap/slapd.co'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
[Current thread is 1 (Thread 0x7f8a63fff700 (LWP 563))]
(gdb) q
Unfortunately, I am not any wiser than before.
The programme ended because of signal SIGABRT.
We restart the service with the following command line: "systemctl stop nscd ; systemctl stop slapd ; sleep 3 ; systemctl restart slapd".
I am happy about any suggestion that can help me find the cause and eliminate the problem. At the moment I don’t know where to start…
To me this sounds as if the schema extension from this cool soultion has been installed at some point and then it has been uninstalled without first checking that the attributes are not used any longer. From previous experience with slapd a suggest that you check slapcat | grep -i sudoHost, i.e. with a case insensitive search, as slapd shows unknown attributes in capital letters.
OTOH, this could also be just a client that specified (sudoHost=foo) in an LDAP query. So let’s go back to the raw data instead of guessing: When you run “gdb /usr/sbin/slapd /core” you should check the output of the following command in gdb:
thread apply all bt
This should output the backtrace of the state of all threads of the process. One of them must show the trace where the abort signal occurrs (probably __GI_raise will show up there). It would be interesting to see the backtrace of that thread, so what function calls happened before that (i.e. in the frames “above” frame #0 of that thread).
Probably you should at least run “univention-install slapd-dbgsym” before, so gdb is able to resolve the symbols in the backtraces.
