← Back to team overview

touch-packages team mailing list archive

Re: [Bug 1376548] [NEW] service slapd stop fails

 

Hi Paul,

Thanks for the report.

On Wed, Oct 1, 2014 at 8:03 PM, Paul Bickerstaff
<paul.bickerstaff@xxxxxxxxxxxxxxxxxxxxx> wrote:
> 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.

Is there any output from slapd in /var/log/syslog that might indicate
why it didn't stop? Is it still responding normally to connections
after that?

Is this happening consistently for you, or only intermittently? If the
latter, can you see any pattern in when it happens?

> The problem is clouded by the --oknodo option in /etc/init.d/slapd. This
> is responsible for the erroneous report.

JFTR: the intent of --oknodo is to provide idempotence, per the
examples in the start-stop-daemon(8) man page.

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

That agrees with the return codes; 0 with --oknodo and 1 without it
means that start-stop-daemon(8) thinks no action needs to be taken.

However, your ps output above shows the command as /usr/sbin/slapd,
which (assuming you haven't modified the init script) is exactly what
--exec should be checking for. So I don't understand why this wouldn't
be working for you.

It definitely doesn't seem that slapd is failing to stop (which
answers some of my questions above); I'd expect s-s-d to return 2 in
that case.

Can you verify that /proc/$(pidof slapd)/exe does point to
/usr/sbin/slapd?

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

As I understand it, the --exec test is there to protect against the
case where the daemon has already died but the pidfile is stil present
(for example, if it crashed), and some other unrelated process has
already taken over the PID. My larger concern is *why* --exec isn't
working properly on your system -- this could be a symptom of
something more subtle.

cheers,
Ryan

-- 
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 “openldap” package in Ubuntu:
  New

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/openldap/+bug/1376548/+subscriptions


Follow ups

References