Univention Bugzilla – Bug 50616
/etc/init.d/slapd fails to start slapd if another slapd is running in a Docker Container
Last modified: 2020-03-18 12:27:44 CET
If an App uses its own OpenLDAP server in a separate container, our outer slapd will not start: We patched /etc/init.d/slapd and use "pgrep /usr/sbin/slapd" which happens to find the docker descendent process and stops to start slapd as it assumes it is already running. The original Debian Stretch script does not use pgrep, but pidfile. Maybe we can update our UCR template? Or we can tell pgrep to not find those processes below /usr/bin/containerd.
See also Bug #18500 comment 5ff. https://github.com/univention/univention-corporate-server/pull/14
pgrep -f /usr/sbin/slapd -P 1 _seems_ to work.
Fixed in univention-ldap 15.0.0-33A~4.4.0.201912121001 /etc/init.d/slapd now uses --ppid 1 everywhere. I also tried to update the whole script or at least transition to "pidfile" instead of "pgrep", but had problems with start-stop-daemon which is actually starting /usr/sbin/slapd. This change is not very invasive and worked in my tests. Even if not started via "service slapd start", but with "/usr/sbin/slapd" directly on a TTY, the process somehow manages to get PPID 1. Still hold for things like "env X=Y /usr/sbin/slapd", so it should be okay. Note that doing this confuses systemd and should not be done, but this is not due to this bug, but a general rule.
I also adjusted ucs-test (9.0.3-128). Two tests were checking for /usr/sbin/slapd without taking PPID into consideration. On a side note, 10_ldap/26reconnect_univention_ldapsearch stopped, but did not start our OpenLDAP if a container had its own slapd process. So next to all tests after that one failed. On the other hand, it is marked as "dangerous"... (I mentioned this bug in another commit regarding appliance test configs, that was an error)
(In reply to Dirk Wiesenthal from comment #3) > pgrep -f /usr/sbin/slapd -P 1 > > _seems_ to work. FYI: Please do it correctly and use `pgrep -ns "$$" -f /usr/sbin/slapd`. Your solution might break as soon as we fix Bug #43691 and convert OpenLDAP to `systemd`, in which case `slapd` might not daemonize and as such does not get re-parented to init (PID 1). (actually systemd still double-forks when starting a service, so even works with `systemd` today as then PPID will be 1) Your solution will gets into trouble when `slapd` is started manually or is running from a debugger in the foreground, as then PPID!=1 but TCP:389/636/7389/7636 will already be taken and the LMDBs will be opened for exclusive write, so a 2nd `slapd` should not/cannot be started. `/etc/init.d/slapd` MUST fail then! Actually the test for '/usr/sbin/slapd' can also break during an update of the Debian slapd package: `slapd` is not stopped during the update phase, so its binary is locked in the file system by the Linux kernel. Because of this `dpkg` renames the binary and writes the new binary to the old location. Luckily `pgrep` still works as it checks the original command line from "/proc/$pid/cmdline" instead of following "/proc/$pid/exe", which changes due to the renaming; `start-stop-daemon --exec` uses that for example: ~/REPOS/DEBIAN/dpkg/utils/start-stop-daemon.c:1687 pid_is_exec()
> I also tried to update the whole script or at least transition to "pidfile" instead of "pgrep", but had problems with start-stop-daemon which is actually starting /usr/sbin/slapd. Why not use "--pidfile /var/run/slapd/slapd.pid" similar to but even simpler than what the Debian stretch package does? But I guess Philipps proposal may be even better.
I would like to keep it that way, very simple. I now mention this bug in univention-ldap 15.0.0-34A~4.4.0.201912171121. New versions of the init script should be aware of this workaround. A more modern approach with pidfiles should be incorporated as soon as we lift the whole script to "buster level" or so. I also tested this bug fix with our own Docker Images. Interestingly, it works with "--ppid 1" inside the container...
Looks ok.
<http://errata.software-univention.de/ucs/4.4/497.html>