Dear Maintainer, 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, 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, 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, otherwise all kinds of weird things start happening in our networks without ldap working. There's nothing out of the ordinary shown in the syslog or journal or slapd.log (which is what "-l local0" is used for). I'm curious what "slapd/invalid_config: true" means in the debconf info below. Other than that, what more can be checked? Thanks, Chandler
Hello, As far as I know, #688797 describes a deadlock issue where slapd stopped answering requests, not the server exiting. 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. Did you try customizing slapd.service itself with Restart=always? (via a drop-in since the .service is generated) That sounds like an understatement. Could you please share some of these logs? 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. 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
Yes sir! How unlike me, I apologize! Only if you insist. I'm no expert either but I did check all that beforehand and didn't notice *a thing*. My next best guess at that point was some sort of malicious query that silently shut down the server, since I often saw the same user making the last queries before the service stopped. After a while, that randomized though, so my conspiracy theory was in shambles. Sooo, I downgraded back to version 2.5.13+dfsg-2~bpo11+1 shortly after your message and, wouldn't you know, it's been steadily running since then, over 6 days now and a new record...