Bug#1107395: OpenLDAP: slapd 2.5.13+dfsg-5 service frequently stops during everyday use

[Ryan Tandy]

Control: tag -1 moreinfo

Hello,

On Fri, Jun 06, 2025 at 07:08:48PM -0700, chandler wrote:
>Since upgrading slapd from 2.5.13+dfsg-2~bpo11+1 on April 29, 2025, it 
>frequently yet randomly stops gracefully.  It's as if I ran `systemctl 
>stop slapd` myself, and I have to run `systemctl start slapd` myself to 
>fix it.  Sometimes it will stop several times a day, or it may last 
>several days before stopping. It sounds exactly the same as what Jose 
>described in #688797,

As far as I know, #688797 describes a deadlock issue where slapd stopped 
answering requests, not the server exiting.

>although he claims the problem went away when upgrading to mdb, which 
>we're already using.  This was never an issue with 
>2.5.13+dfsg-2~bpo11+1, which we had been using for over a year since I 
>checked /var/log/apt/history, which has a year of apt history

I guess you were running bullseye-backports previously and have now 
upgraded to bookworm, is that correct?

Between 2.5.13+dfsg-2 and -5 there are no code changes except for one 
fix to the sha2 password module.

>and there were no other mentions of slapd.  Like Jose, I've had to 
>create a systemd timer that runs a slapd-checker.service every few 
>seconds to start slapd.service if needed

Did you try customizing slapd.service itself with Restart=always? (via a 
drop-in since the .service is generated)

>otherwise all kinds of weird things start happening in our networks 
>without ldap working.

That sounds like an understatement.

>There's nothing out of the ordinary shown in the syslog or journal or 
>slapd.log (which is what "-l local0" is used for).

Could you please share some of these logs?

>I'm curious what "slapd/invalid_config: true" means in the debconf info 
>below.

https://sources.debian.org/src/openldap/2.6.10%2Bdfsg-1/debian/slapd.config/#L25-L77

It means one of the initial debconf questions was answered incorrectly 
(for example, the two attempts at entering the admin password did not 
match). It remains set to true even if you get it right on the retry.

>Other than that, what more can be checked?

Good question. I think the important thing is to determine whether the 
events are initiated by slapd itself, or by something external telling 
systemd to stop it. I'm not a systemd expert and don't know the best way 
to figure that out, but I'd be looking at the journal, comparing logs 
with one of your events vs an explicit 'systemctl stop', and checking 
the behaviour with Restart=always. That is, I'd expect Restart=always to 
restart the service if the stop was unexpected (even if the slapd 
process exited gracefully), but not if systemctl thinks it was told to 
stop it.

thanks,
Ryan