Have the latest openldap, and slapd starts fine from boot rc confic or with /etc/inid.d/slapd start, once /etc/openldap/slapd.conf is edited properly. However, "stop" can't find the proper pid file and refuses to kill the process, "restart" has the same problem. Killing the process manually does no good either, as the "start" script will complain that it is already started, even though it isn't. Reproducible: Always Steps to Reproduce: 1. emerge openldap 2. edit /etc/openldap/slapd.conf until slapd -t reports no errors 3. /etc/init.d/slapd start 4. /etc/init.d/slapd restart Actual Results: "/etc/init.d/slapd stop" fails with a cryptic "[!!]" message. Killing slapd manually with "killall -9 slapd" will kill the slapd process. But then /etc/init.d/slapd start will exit with an error "slapd has already been started". You can't win. Expected Results: "/etc/init.d/slapd restart" should find every running slapd and kill it, giving a warning (not an error) if it cannot find such a process. It should then start a new instance. This could be a bug in the openldap port, or in gentoo's start-stop-daemon mechanism. Probably it is both. It may be caused because openldap tries to put the PID file in /var/run/openldap, rather than /var/run directly, or makes some other invalid assumption about how either /sbin/runscript or /sbin/start-stop-daemon operates. This would mean that the /etc/init.d/slapd file in the openldap package (at least) is broken. More troubling is the fact that neither of the two binary files (runscript or start-stop-daemon) have a man page on the system (a gentoo no-no, I understand), especially since they seem to be the heart and soul of the SysV init scripts and rc-update system. If I add --help or -? to them they do give some info, but the don't have the level of detail or the FILES section that I expect to see in a good man page. I really hate seeing (let alone learning) yet another scripting language on top of sh, bash, csh, perl, tkl, python, and all the rest. Why, oh why, can't scripts like these be written in sh (or bash) as the GNU gods decreed? It seems clear to me that these executable files are also buggy, in that they don't check and report the failure to create the /var/run/xxx.pid file, if that file is REQUIRED for functionality later on (e.g. to stop the service and clean up after yourself). Alternatively, they could attempt to work around the problem in the event the PID file is missing, but the service is running anyway (e.g. scan a "ps ax" to see if the service is running and "killall slapd"). Worse yet, they seem to do some undocumented prior internal housekeeping that causes them to report "slapd is already running", even if it has been killed manually or died on its own. This makes a reboot required to clear this undocumented system flag. I don't know what these two files do that is so special, but I have a hard time understanding why we need a binary executable file to do it. If it were a script, I would know where the problem is and could probably just submit a patch. The time saved with a binary here is probably very small, compared to the "easy accesibility" factor. In any event they need to be much more robust, so that they work as expected even if some elements (such us the appropriate PID file) don't work out as planned. Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808- r1, 2.4.26-gentoo-r13 i686) ================================================================= System uname: 2.4.26-gentoo-r13 i686 AMD Duron(tm) Processor Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/ share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acl apm arts avi berkdb bitmap-fonts crypt cups encode foomaticdb fortran gdbm gif gnome gpm gtk gtk2 ipv6 jpeg kde ldap libwww mad mikmod motif mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png postgres python qt quicktime readline samba sdl spell ssl svga tcpd tiff truetype xml2 xmms xv zlib"
Temporary workaround: eliminate -m flag from "start" line in /etc/init.d/slapd, configure /etc/openldap/slapd.conf to set a PID file in /var/run/openldap/slapd.pid (or wherever) which works okay; pass the same parameter to the stop command, reboot to clear any garbage. It will work, but depends on coordination of the pidfile localtion between the /etc/openldap/slapd.conf and /etc/init.d/slapd files.
Debian woody uses a sed script in /etc/init.d/slapd to extract the pidfile location from the /etc/ldap/slapd.conf file, then feeds that value to start-stop-daemon. Which leaves me wondering whether s-s-d is responsible to create the pid file, or whether it just counts on slapd to do it. If s-s-d does it, then why would we even need the parameter in the slapd.conf file?
OK, mea culpa. The s-s-d DOES have a man page. I probably misspelled DAEMON again (not the first time), but runscript does not have a man page. Looks like I made a substitute /etc/openldap/slapd.conf that modded the pidfile parameter or something. Or maybe I was working too late with square eyeballs from staring at this @#$% screen. "emerge openldap" got me back to a working state, so it must be a problem in one of my mucked-up config files (like a bad pidfile location?). I'll try again from clean, testing each step this time. The man page for s-s-d clearly that the PID file is checked for a running process. If there is no such file, apparently it STILL looks for a slapd process, or my workaround mod (mentioned earlier) would not function properly for all states of running/not running and start/stop (which it does).
