The failure to stop was consistent. There was no logging, consistent with the successful exit code triggered by --oknodo. Experimentation showed that --exec was failing and it was because /proc/$(pidof slapd)/exe could not be read ("Permission denied" to root). It has occurred to me belatedly that this is because I'm running slapd inside a docker container (Docker version 1.2). I apologize for not being alert enough to recognize this earlier. The container is running with various capabilities (NET_ADMIN, SYS_ADMIN, SYSLOG, DAC_OVERRIDE, NET_BIND_SERVICE, SETGID, SETUID). It will not run in privileged mode -- due to (flaws in the profile for) apparmor. So /proc is a protected area (read-only for example if not in privileged mode but even more limited for security reasons). While I now understand what is causing the problem, and can edit the init.d script when building the docker image, I believe that the logic in the stop_slapd function is flawed. The slapd function is not stopping, due to a failure, but the stop function is ending with exit code 0. The fundamental flaw may well be in start-stop-daemon but this init script tests for the existence of SLAPD_PIDFILE but assumes erroneously that "--exec $SLAPD" is functional. I admit I don't grasp why --oknodo is not recognizing a failure (which is evident if this option is dropped) and interpreting the situation as nothing to do. I suggest that the environment I am running in will become increasingly more common and plea for a fix to be made. The scenario of concern driving the current script, i.e. an existing pidfile but daemon has died, could be tested for. If not the case then --pidfile alone should be sufficient. If the daemon has stopped then it would be OK for the stop function to exit gracefully, possibly with a warning about the pidfile. If there is no pidfile then I think the script is already exiting. One could, if the pidfile didn't stop a running daemon, attempt the --exec option. One can also try a brute force stop without using either option if both fail. Cheers Paul Bickerstaff DevOps, Portland Software Services Mobile: +6421390266 -----Original Message----- From: