Bug 43313 - UCS' /etc/init.d/slapd graceful-restart incompatible with systemd - fails to start
UCS' /etc/init.d/slapd graceful-restart incompatible with systemd - fails to ...
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 4.2
Other Linux
: P1 normal (vote)
: UCS 4.2
Assigned To: Philipp Hahn
Arvid Requate
: interim-2, systemd
: 43329 (view as bug list)
Depends on: 38438
Blocks: 42380 43330 43874
  Show dependency treegraph
 
Reported: 2017-01-06 16:49 CET by Philipp Hahn
Modified: 2017-09-26 10:47 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Development Internal
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Hahn univentionstaff 2017-01-06 16:49:51 CET
# service slapd status
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
   Loaded: loaded (/etc/init.d/slapd)
   Active: active (exited) since Fr 2017-01-06 09:00:58 EST; 1h 13min ago
  Process: 998 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)

For systemd slapd is running "status=0/SUCESS", so calling "systemctl start slapd.service" does nothing.

It was triggered by ucs-test/01_base/07kpasswd_output:
# less /var/log/user.log
>Jan  6 09:03:21 master091 univention-mount-homedir: Creating home directory '/home/Td6410d73654'
>Jan  6 09:03:51 master091 logger: /etc/init.d/slapd graceful-restart (pid: 5205, ppid: 4855 admingrp-user-p)
>Jan  6 09:03:51 master091 logger: /etc/init.d/slapd graceful-stop (pid: 5216, ppid: 5205 slapd)

# systemctl stop slapd.service
# systemctl start slapd.service
# systemctl status slapd.service
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
   Loaded: loaded (/etc/init.d/slapd)
   Active: active (running) since Fr 2017-01-06 10:43:48 EST; 3s ago
  Process: 1273 ExecStop=/etc/init.d/slapd stop (code=exited, status=0/SUCCESS)
  Process: 1452 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/slapd.service
           └─1469 /usr/sbin/slapd -h ldapi:/// ldap://:7389/ ldaps://:7636/
Comment 1 Stefan Gohmann univentionstaff 2017-01-12 06:31:30 CET
*** Bug 43329 has been marked as a duplicate of this bug. ***
Comment 2 Stefan Gohmann univentionstaff 2017-01-12 06:32:52 CET
From Bug #43329 Comment #1:
> As a temporary workaround:
> 
> r75700:
> * Replace the graceful-restart and graceful-stop with restart and stop
>   in order to get the first UCS 4.2 preview tests working (Bug #43329)
Comment 3 Philipp Hahn univentionstaff 2017-02-07 11:24:08 CET
See Bug #43450 comment 4 for the explanation and a possible solution.
Comment 4 Philipp Hahn univentionstaff 2017-02-07 11:27:14 CET
IMHO <https://lists.fedoraproject.org/pipermail/scm-commits/2011-November/678465.html> shows a good template, if we convert to slapd.service.
What complicates this is our added logic to check the LDAP schema before starting and applying failed.ldif after starting slapd.

Reminder to self: convert those to separate units and shell scripts.
Comment 5 Philipp Hahn univentionstaff 2017-02-27 16:31:13 CET
'gentlehup' was implemented through Bug #34440 comment 10 and reverted later again in Bug #34440 comment 13; as such the functionality does not work and already falls back to the non-gentle variant. `/etc/init.d/slapd graceful-restart` is still used by
 management/univention-admingrp-user-passwordreset/conffiles/admingrp-user-passwordreset:34
 management/univention-admingrp-user-passwordreset/ldap-group-to-file-hooks.d/admingrp-user-passwordreset:72
 management/univention-ldap/listener/ldap_extension.py:86
 management/univention-ldap/well-known-sid-name-mapping.d/univention-ldap-server.py:49
 management/univention-management-console/umc-service-providers.py:78
and should be "systemctl reload-or-try-restart"
'graceful-stop' is used nowhere and should be removed completely.

We still need to fix the the issue from Bug #43450 comment 4, as "service start slapd" should work always, even when the previous instance of slapd no longer exists. The best solution would be to convert /etc/init.d/slapd into separate systemd units:
 slapd-bdbrecover.service:
  [Unit]
  Description=Check OpenLDAP Berkeley DB for consistency before start
  [Service]
  Type=oneshot
  ExecStart=/etc/init.d/slapd bdbrecover
  RemainAfterExit=yes
  
 slapd-replog.service:
  [Unit]
  Description=Create /var/lib/univention-ldap/replog/replog* paths
  [Service]
  Type=oneshot
  ExecStart=/etc/init.d/slapd check_replog_file 
  RemainAfterExit=yes

 slapd.service:
  [Unit]
  Description=OpenLDAP Server Daemon
  ConditionPathExists=!/etc/ldap/noslapd
  Requires=slapd-bdbrecover.service slapd-replog.service
  After=syslog.target
  After=slapd-bdbrecover.service
  OnFailure=slapd-schema-check.service
  [Service]
  Type=simple
  #Environment="SLAPD_CONF=/etc/ldap/slapd.conf"
  #Environment="SLAPD_USER=openldap"
  #Environment="SLAPD_GROUP=openldap"
  Environment="SLAPD_DEBUG=stats"
  Environment="SLAPD_SERVICES=ldap://:7389/ ldap://:389/ ldaps://:7636/ ldaps://:636/ ldapi:///"
  Environment="SLAPD_OPTIONS="
  EnvironmentFile=-/etc/default/slapd
  LimitNOFILE=infinity
  #ExecStart=/usr/sbin/slapd -f ${SLAPD_CONF} -u ${SLAPD_USER} -g ${SLAPD_GROUP} -d ${SLAPD_DEBUG} -h ${SLAPD_SERVICES} $SLAPD_OPTIONS
  ExecStart=/usr/sbin/slapd -f /etc/ldap/slapd.conf -d ${SLAPD_DEBUG} -h ${SLAPD_SERVICES} $SLAPD_OPTIONS
  ExecStartPost=-/bin/ln -snf /var/run/slapd/ldapi /var/run/ldapi
  Restart=on-failure
  [Install]
  WantedBy=multi-user.target

 slapd-schema-check.service:
  [Unit]
  Description=Check OpenLDAP schema on start failure
  [Service]
  Type=oneshot
  ExecStart=/usr/sbin/slapschema  

 slapd-schema-dump.service:
  [Unit]
  Description=Dump OpenLDAP schema to file for replication
  Requires=slapd.service
  After=slapd.service
  [Service]
  Type=oneshot
  ExecStart=/etc/init.d/slapd check_subschema
  [Install]
  WantedBy=multi-user.target

 slapd-ldif.service:
  [Unit]
  Description=Apply failed.ldif to OpenLDAP
  ConditionFileIsExecutable=/usr/sbin/univention-directory-replication-resync
  ConditionPathExists=/var/lib/univention-directory-replication/failed.ldif
  Requires=slapd.service
  After=slapd.service
  [Service]
  Type=oneshot
  ExecStart=/usr/sbin/univention-directory-replication-resync /var/lib/univention-directory-replication/failed.ldif
  [Install]
  WantedBy=multi-user.target


As this change needs more investigation, I only changed the init script to track the PID file of slapd.

r77128 | Bug #43313 ldap: Adjust slapd.service to use pidfile

Package: univention-ldap
Version: 13.0.3-8A~4.2.0.201702271630
Branch: ucs_4.2-0
Comment 6 Arvid Requate univentionstaff 2017-03-02 21:09:15 CET
Ok, changelog missing, but may not be required.
Comment 7 Stefan Gohmann univentionstaff 2017-04-04 18:29:01 CEST
UCS 4.2 has been released:
 https://docs.software-univention.de/release-notes-4.2-0-en.html
 https://docs.software-univention.de/release-notes-4.2-0-de.html

If this error occurs again, please use "Clone This Bug".