On Fri, Oct 3, 2014 at 5:32 AM, Paul Bickerstaff
<paul.bickerst...@portland-software.com> 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. ** Also affects: docker.io (Ubuntu) Importance: Undecided Status: New ** Changed in: openldap (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1376548 Title: service slapd stop fails Status in “docker.io” package in Ubuntu: New Status in “openldap” package in Ubuntu: Invalid Bug description: In "Ubuntu 14.04.1 LTS" amd64 with slapd package version "2.4.31-1+nmu2ubuntu8", "OpenLDAP server (slapd)", executing the following standard service command fails to have effect. # service slapd stop * Stopping OpenLDAP slapd [ OK ] # ps -ef | grep slapd | grep -v grep openldap 196 1 0 02:00 ? 00:00:00 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d i.e. it reports all is OK but it failed to stop the running process which continues with the same pid. The problem is clouded by the --oknodo option in /etc/init.d/slapd. This is responsible for the erroneous report. stop_slapd() { reason="`start-stop-daemon --stop --quiet --oknodo --retry TERM/10 \ --pidfile "$SLAPD_PIDFILE" \ --exec $SLAPD 2>&1`" } Removing --oknodo demonstrates a failure with exit code 1. The role of oknodo should be reconsidered here. Further experimentation shows that the --exec option is not working. Since the init script is checking for $SLAPD_PIDFILE and exiting if empty, I suggest just dropping "--exec $SLAPD" from the init script. It is superfluous and the "service slapd stop" command will work after its removal. SLAPD_PIDFILE is correctly identified on my system. Mine is a stock standard fresh slapd install. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1376548/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
