Re: [Touch-packages] [Bug 1821343] [NEW] slapd process failure is not detected by systemd

2019-03-22 Thread Ryan Tandy
Hello Hector,

On Fri, Mar 22, 2019 at 12:36:57PM -, Heitor R. Alves de Siqueira wrote:
>The slapd package for OpenLDAP is shipped with a SysV-style init script 
>(/etc/init.d/slapd). Systemd automatically converts this to a systemd 
>service by generating the unit file using the systemd-sysv-generator(8) 
>utility. The generated unit file contains Type=forking and 
>RemainAfterExit=yes directives.
>
>If the slapd daemon process exits due to some failure (e.g., it receives
>a SIGTERM or SIGKILL), the failure is not detected properly by systemd.
>The service is still reported as active even though the child (daemon)
>process has exited with a signal.
>
>We can easily fix this by including a proper systemd service file for
>slapd in the openldap package.

Do you need a whole service file for this? I thought you could achieve 
the same with a drop-in that just overrides the required keys:

/etc/systemd/systems/slapd.service.d/remain-after-exit.conf:

[Service]
Type=forking
RemainAfterExit=no
Restart=on-failure

(untested, based on bug 1488962)

-- 
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/1821343

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  Confirmed
Status in openldap source package in Xenial:
  Confirmed
Status in openldap source package in Bionic:
  Confirmed
Status in openldap source package in Cosmic:
  Confirmed

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed

  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

  If the slapd daemon process exits due to some failure (e.g., it
  receives a SIGTERM or SIGKILL), the failure is not detected properly
  by systemd. The service is still reported as active even though the
  child (daemon) process has exited with a signal.

  We can easily fix this by including a proper systemd service file for
  slapd in the openldap package. Since the init.d script already does
  most of the necessary work (parsing configs, setting up PID files,
  etc.), we don't need anything complicated for the systemd unit file.
  Just making sure that RemainAfterExit is set to "no" makes the systemd
  service behave in the expected way.

  [Test Case]
  1) Deploy a disco container
  $ lxc launch images:ubuntu/disco disco

  2) Install slapd
  ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y

  3) Verify that slapd is running with the auto-generated service
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
 Loaded: loaded (/etc/init.d/slapd; generated)
 Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
   Docs: man:systemd-sysv-generator(8)
Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
  Tasks: 3 (limit: 4915)
 Memory: 712.6M
 CGroup: /system.slice/slapd.service
 └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d

  4) SIGKILL the slapd process (PID is displayed in systemctl status output)
  ubuntu@disco:~$ sudo kill -9 1109

  5) Check if systemd service lists slapd as still active, even though it was 
terminated
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
 Loaded: loaded (/etc/init.d/slapd; generated)
 Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago
   Docs: man:systemd-sysv-generator(8)
Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)

  [Regression Potential]
  The regression potential for this fix should be very low, if we keep the new 
systemd unit file close to the one generated by systemd-sysv-generator(8). The 
only significant change would be the RemainAfterExit directive, and this should 
make the slapd service behave like a "normal" forking service. Nonetheless, 
we'll perform scripted test runs to make sure no regressions arise.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+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


[Touch-packages] [Bug 1821343] [NEW] slapd process failure is not detected by systemd

2019-03-22 Thread Heitor R. Alves de Siqueira
Public bug reported:

[Impact]
Systemd service reports slapd as active, even though it may have failed

[Description]
The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

If the slapd daemon process exits due to some failure (e.g., it receives
a SIGTERM or SIGKILL), the failure is not detected properly by systemd.
The service is still reported as active even though the child (daemon)
process has exited with a signal.

We can easily fix this by including a proper systemd service file for
slapd in the openldap package. Since the init.d script already does most
of the necessary work (parsing configs, setting up PID files, etc.), we
don't need anything complicated for the systemd unit file. Just making
sure that RemainAfterExit is set to "no" makes the systemd service
behave in the expected way.

[Test Case]
1) Deploy a disco container
$ lxc launch images:ubuntu/disco disco

2) Install slapd
ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y

3) Verify that slapd is running with the auto-generated service
ubuntu@disco:~$ systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access 
Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated)
   Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
 Docs: man:systemd-sysv-generator(8)
  Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
Tasks: 3 (limit: 4915)
   Memory: 712.6M
   CGroup: /system.slice/slapd.service
   └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap 
-F /etc/ldap/slapd.d

4) SIGKILL the slapd process (PID is displayed in systemctl status output)
ubuntu@disco:~$ sudo kill -9 1109

5) Check if systemd service lists slapd as still active, even though it was 
terminated
ubuntu@disco:~$ systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access 
Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated)
   Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago
 Docs: man:systemd-sysv-generator(8)
  Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)

[Regression Potential]
The regression potential for this fix should be very low, if we keep the new 
systemd unit file close to the one generated by systemd-sysv-generator(8). The 
only significant change would be the RemainAfterExit directive, and this should 
make the slapd service behave like a "normal" forking service. Nonetheless, 
we'll perform scripted test runs to make sure no regressions arise.

** Affects: openldap (Ubuntu)
 Importance: Medium
 Assignee: Heitor R. Alves de Siqueira (halves)
 Status: Confirmed

** Affects: openldap (Ubuntu Xenial)
 Importance: Medium
 Assignee: Heitor R. Alves de Siqueira (halves)
 Status: Confirmed

** Affects: openldap (Ubuntu Bionic)
 Importance: Medium
 Assignee: Heitor R. Alves de Siqueira (halves)
 Status: Confirmed

** Affects: openldap (Ubuntu Cosmic)
 Importance: Medium
 Assignee: Heitor R. Alves de Siqueira (halves)
 Status: Confirmed


** Tags: sts

** Also affects: openldap (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: openldap (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: openldap (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: openldap (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: openldap (Ubuntu Bionic)
   Status: New => Confirmed

** Changed in: openldap (Ubuntu Cosmic)
   Status: New => Confirmed

** Changed in: openldap (Ubuntu Xenial)
 Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)

** Changed in: openldap (Ubuntu Bionic)
 Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)

** Changed in: openldap (Ubuntu Cosmic)
 Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)

** Changed in: openldap (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: openldap (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: openldap (Ubuntu Cosmic)
   Importance: Undecided => Medium

-- 
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/1821343

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  Confirmed
Status in openldap source package in Xenial:
  Confirmed
Status in openldap source package in Bionic:
  Confirmed
Status in openldap source package in Cosmic:
  Confirmed

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed