Recurring problem with "slapd.service

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…

Add:

root@adpdchost:~# systemctl status slapd.service
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
   Loaded: loaded (/etc/init.d/slapd; static; vendor preset: enabled)
   Active: failed (Result: signal) since Wed 2023-08-16 12:17:34 CEST; 22min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 16473 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
 Main PID: 16489 (code=killed, signal=ABRT)

Aug 16 12:16:55 adpdchost slapd[16489]: get_ssa: conn 40172 unknown attribute type=sudoHost (17)
Aug 16 12:16:55 adpdchost slapd[16489]: get_ssa: conn 40172 unknown attribute type=sudoHost (17)
Aug 16 12:16:56 adpdchost slapd[16489]: get_filter: conn 40173 unknown attribute type=sudoHost (17)
Aug 16 12:16:56 adpdchost slapd[16489]: get_ssa: conn 40173 unknown attribute type=sudoHost (17)
Aug 16 12:16:56 adpdchost slapd[16489]: get_ssa: conn 40173 unknown attribute type=sudoHost (17)
Aug 16 12:16:56 adpdchost slapd[16489]: get_ssa: conn 40173 unknown attribute type=sudoHost (17)
Aug 16 12:16:56 adpdchost slapd[16489]: get_ssa: conn 40173 unknown attribute type=sudoHost (17)
Aug 16 12:16:56 adpdchost slapd[16489]: get_ssa: conn 40173 unknown attribute type=sudoHost (17)
Aug 16 12:17:34 adpdchost systemd[1]: slapd.service: Main process exited, code=killed, status=6/ABRT
Aug 16 12:17:34 adpdchost systemd[1]: slapd.service: Failed with result 'signal'.

Doesn’t anyone have any ideas on how I can tackle the problem better? It would really help me a lot. :pray:

Hi,

I probably can’t help you since I’m not really a LDAP-Specialist yet.

I am puzzled by the message:

unknown attribute type=sudoHost

Have you modified the LDAP schema?

with best
sven

Hm… I didn’t do it, but maybe someone else did. I only took over support from a few months ago and the previous admins are no longer available.

i would check this about the schema:

rg
Christian

1 Like

Hello, thank you for this suggestion.
Unfortunately, the term “sudoHost” does not appear in the entire LDAP tree.

root@adpdchost :~# slapcat | grep sudoHost
root@adpdchost :~#

Also slapschema does not throw an error:

root@adpdchost:~# slapschema
root@adpdchost:~#

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.

1 Like

These messages are probably caused by a SSSD client.

1 Like
Mastodon