Comment 3 for bug 1376548

On Fri, Oct 3, 2014 at 5:32 AM, Paul Bickerstaff
<email address hidden> wrote:
> 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.

Thanks, that's the key piece of info. I believe this is a bug in
Docker, then; either an upstream bug such as
https://github.com/docker/docker/issues/6800 which has been shown to
affect multiple Debian packages
(https://github.com/docker/docker/issues/6800#issuecomment-49685466 is
especially similar to your situation) or something more like
https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1320869 which
mentions apparmor.

I'm going to mark this as a Docker bug, and leave it up to its
maintainers to decide whether it should be marked as a duplicate or
triaged individually.

> 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.

We might have to agree to disagree on that. The same pattern is used
in plenty of other packages and is expected to work.

> 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 don't agree at all with "erroneously". --exec is expected to work.

> 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.

That should probably be reported as a bug in start-stop-daemon. I
would expect the failure to read /proc/N/exe to be reported as an
error, even under --oknodo.