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
