touch-packages team mailing list archive

[Ryan Tandy <1376548@xxxxxxxxxxxxxxxxxx>]

On Fri, Oct 3, 2014 at 5:32 AM, Paul Bickerstaff
<paul.bickerstaff@xxxxxxxxxxxxxxxxxxxxx> 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