[Touch-packages] [Bug 1821343] Re: slapd process failure is not detected by systemd
I've been doing some research on how we could implement a proper systemd
unit file for slapd, and came up with interesting results.
There are a number of options that we can pass to the slapd service that will
give us lots of troubles on an "idiomatic" service file. To give some examples:
- The PID file can be directly obtained from /etc/default/slapd if set, or it
has to be parsed from /etc/ldap/slapd.d or /etc/ldap/slapd.conf. The /etc/ldap
files don't follow the /etc/default syntax, so we can't just pass them with
"EnvironmentFile=" in the systemd service. We would have to parse those files
as is currently done by the init script.
- slapd has the "-f" and "-F" flags that can be used to specify a config file or
directory, respectively. It does not accept both at the same time, but
SLAPD_CONF in /etc/default/slapd allows either a file or directory. The init
script will figure out which of those is set, and pass the correct flag
accordingly. I don't see a simple way of doing this in systemd without either
polluting the SLAPD_CONF option with the necessary flag, or delegating it to a
helper script which would check whether the option meant a file or a
directory.
- The slapd.conf file is used by other related tools (see slapd.conf(5)), which
prevents us from pulling some of the options to another centralized file
without also updating these tools
I hoped that the upstream package would have some insight on the proper
way of writing the service file, but unfortunately it seems that
upstream Openldap devs are very much against the idea of shipping them
(be they sysv-init or systemd files). There are some discussions on the
openldap lists, one of which deals specifically with adding systemd
support for slapd [0]. From that discussion, it's clear that upstream
openldap is not ready to provide the necessary systemd files out-of-the-
box, even when approached with relevant patches.
I also checked how CentOS implement their slapd.service file since they don't
seem to run into these problems. They don't use an autogenerated unit file, and
have a proper one instead [1]. From what I've checked, this is easier for them
for two reasons:
1) The CentOS configs for slapd are much simpler than what we have in
Debian/Ubuntu (their defaults don't include most of the options that we do)
2) They use helper scripts for the funky parsing we have in the sysv-init
script ("ExecStartPre=/usr/libexec/openldap/check-config.sh", which also
invokes some other helper scripts)
On Debian/Ubuntu, the autogenerated unit file for slapd uses the sysv-init
script as a "shim" to manage the service, which makes it possible to keep the
whole config-parsing insanity consistent between sysv-init and systemd.
It's not the most elegant solution, but for now I believe it makes sense to
include an override file for the "RemainAfterExit=" option until we have a
native systemd unit file for slapd (similar to what was done for apache2 in bug
1488962 mentioned by Ryan Tandy).
[0] https://www.openldap.org/its/index.cgi/Incoming?id=8707
[1] https://git.centos.org/blob/rpms!openldap.git/c7/SOURCES!slapd.service
--
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 -
[Touch-packages] [Bug 1821343] [NEW] slapd process failure is not detected by systemd
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
[Touch-packages] [Bug 1821343] Re: slapd process failure is not detected by systemd
-- 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] Re: slapd process failure is not detected by systemd
** Patch added: "debdiff for xenial" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248493/+files/lp1821343-xenial.debdiff ** Tags added: sts-sponsor -- 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] Re: slapd process failure is not detected by systemd
** Patch added: "debdiff for bionic" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248492/+files/lp1821343-bionic.debdiff -- 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] Re: slapd process failure is not detected by systemd
** Patch added: "debdiff for disco" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248489/+files/lp1821343-disco.debdiff -- 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] Re: slapd process failure is not detected by systemd
** Patch added: "debdiff for cosmic" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248490/+files/lp1821343-cosmic.debdiff -- 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] Re: slapd process failure is not detected by systemd
The sysv init script does some funky parsing of configuration files that might give us some trouble in an independent service file. I'll check if we can't work around that and do away with the sysv init script altogether, otherwise we might as well go with the drop-in override since the new service wouldn't be much different from it. ** Patch removed: "debdiff for disco" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248489/+files/lp1821343-disco.debdiff ** Patch removed: "debdiff for cosmic" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248490/+files/lp1821343-cosmic.debdiff ** Patch removed: "debdiff for bionic" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248492/+files/lp1821343-bionic.debdiff ** Patch removed: "debdiff for xenial" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248493/+files/lp1821343-xenial.debdiff -- 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 1815129] [NEW] apt segfaults when generating cache file
Public bug reported: [Impact] apt crashes (core dump) during cache creation [Description] When executing apt-cache several times on a memory constrained system, apt-cache can sometimes crash with a core dump file. This is related to mmap() failing allocations during cache generation, according to an upstream bug report (803417). There is an upstream patch for this bug (6789e01e do not segfault in cache generation on mmap failure) and it's included in the apt package for other series (see below), so we only need to backport it to Trusty. Upstream commit: https://salsa.debian.org/apt- team/apt/commit/6789e01e9370b3b7f65d52138c5657eaa712b4d1 $ git describe --contains 6789e01e9370 1.1_exp16~5 $ rmadison apt apt | 1.0.1ubuntu2| trusty | source, amd64, arm64, armhf, i386, powerpc, ppc64el apt | 1.0.1ubuntu2.19 | trusty-security | source, amd64, arm64, armhf, i386, powerpc, ppc64el apt | 1.0.1ubuntu2.19 | trusty-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el apt | 1.2.10ubuntu1 | xenial | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x apt | 1.6.1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x apt | 1.7.0 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x apt | 1.8.0~rc2 | disco| source, amd64, arm64, armhf, i386, ppc64el, s390x [Test Case] Unfortunately, this issue is not easy to reproduce. It seems to trigger randomly when "apt-cache policy" is called on a system under memory pressure, triggering the failure path in the mmap() allocations. [Regression Potential] The regression potential for this should be low, as it's a change in the failure path for memory allocations. This shouldn't be triggered during normal usage, and we'll thoroughly test the patched package with autopkgtests and perform scripted runs in memory-constrained systems with stress-ng. We also have a confirmation from an impacted user that the upstream patch fixes their issue without further problems. ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Affects: apt (Ubuntu Trusty) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1815129 Title: apt segfaults when generating cache file Status in apt package in Ubuntu: New Status in apt source package in Trusty: New Bug description: [Impact] apt crashes (core dump) during cache creation [Description] When executing apt-cache several times on a memory constrained system, apt-cache can sometimes crash with a core dump file. This is related to mmap() failing allocations during cache generation, according to an upstream bug report (803417). There is an upstream patch for this bug (6789e01e do not segfault in cache generation on mmap failure) and it's included in the apt package for other series (see below), so we only need to backport it to Trusty. Upstream commit: https://salsa.debian.org/apt- team/apt/commit/6789e01e9370b3b7f65d52138c5657eaa712b4d1 $ git describe --contains 6789e01e9370 1.1_exp16~5 $ rmadison apt apt | 1.0.1ubuntu2| trusty | source, amd64, arm64, armhf, i386, powerpc, ppc64el apt | 1.0.1ubuntu2.19 | trusty-security | source, amd64, arm64, armhf, i386, powerpc, ppc64el apt | 1.0.1ubuntu2.19 | trusty-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el apt | 1.2.10ubuntu1 | xenial | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x apt | 1.6.1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x apt | 1.7.0 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x apt | 1.8.0~rc2 | disco| source, amd64, arm64, armhf, i386, ppc64el, s390x [Test Case] Unfortunately, this issue is not easy to reproduce. It seems to trigger randomly when "apt-cache policy" is called on a system under memory pressure, triggering the failure path in the mmap() allocations. [Regression Potential] The regression potential for this should be low, as it's a change in the failure path for memory allocations. This shouldn't be triggered during normal usage, and we'll thoroughly test the patched package with autopkgtests and perform scripted runs in memory-constrained systems with stress-ng. We also have a confirmation from an impacted user that the upstream patch fixes their issue without further problems. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1815129/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe :
[Touch-packages] [Bug 1815129] Re: apt segfaults when generating cache file
** Description changed: [Impact] apt crashes (core dump) during cache creation [Description] When executing apt-cache several times on a memory constrained system, apt-cache can sometimes crash with a core dump file. This is related to mmap() failing allocations during cache generation, according to an upstream bug report (803417). There is an upstream patch for this bug (6789e01e do not segfault in cache generation on mmap failure) and it's included in the apt package for other series (see below), so we only need to backport it to Trusty. Upstream commit: https://salsa.debian.org/apt- team/apt/commit/6789e01e9370b3b7f65d52138c5657eaa712b4d1 $ git describe --contains 6789e01e9370 1.1_exp16~5 $ rmadison apt - apt | 1.0.1ubuntu2| trusty | source, amd64, arm64, armhf, i386, powerpc, ppc64el - apt | 1.0.1ubuntu2.19 | trusty-security | source, amd64, arm64, armhf, i386, powerpc, ppc64el - apt | 1.0.1ubuntu2.19 | trusty-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el - apt | 1.2.10ubuntu1 | xenial | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x - apt | 1.6.1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x - apt | 1.7.0 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x - apt | 1.8.0~rc2 | disco| source, amd64, arm64, armhf, i386, ppc64el, s390x - + apt | 1.0.1ubuntu2| trusty | source, ... + apt | 1.0.1ubuntu2.19 | trusty-security | source, ... + apt | 1.0.1ubuntu2.19 | trusty-updates | source, ... + apt | 1.2.10ubuntu1 | xenial | source, ... + apt | 1.6.1 | bionic | source, ... + apt | 1.7.0 | cosmic | source, ... + apt | 1.8.0~rc2 | disco| source, ... [Test Case] - Unfortunately, this issue is not easy to reproduce. It seems to trigger randomly when "apt-cache policy" is called on a system under memory pressure, triggering the failure path in the mmap() allocations. + 1) Deploy a Trusty (14.04 LTS) vm w/ 128M + 2) Fetch latest stress-ng src code + 2.1) git clone git://kernel.ubuntu.com/cking/stress-ng + 2.2) cd stress-ng + 2.3) make clean + 2.4) make + 3) Stress the mmap() with stress-ng + 3.1) ./stress-ng --brk 2 --mmap 5 --vm 1 --mmap-bytes 90% + 4) Disable swap (if any) + 4.1) swapoff -a + 5) for i in `seq 1 1`;do apt-cache policy vsftpd;done + ... + vsftpd: + Installed: (none) + Candidate: 3.0.2-1ubuntu2.14.04.1 + Version table: + 3.0.2-1ubuntu2.14.04.1 0 + 500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages + 3.0.2-1ubuntu2 0 + 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages + Segmentation fault (core dumped) + Segmentation fault (core dumped) + Segmentation fault (core dumped) + Segmentation fault (core dumped) + Segmentation fault (core dumped) + Segmentation fault (core dumped) + ... [Regression Potential] The regression potential for this should be low, as it's a change in the failure path for memory allocations. This shouldn't be triggered during normal usage, and we'll thoroughly test the patched package with autopkgtests and perform scripted runs in memory-constrained systems with stress-ng. We also have a confirmation from an impacted user that the upstream patch fixes their issue without further problems. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1815129 Title: apt segfaults when generating cache file Status in apt package in Ubuntu: Fix Released Status in apt source package in Trusty: In Progress Status in apt package in Debian: Unknown Bug description: [Impact] apt crashes (core dump) during cache creation [Description] When executing apt-cache several times on a memory constrained system, apt-cache can sometimes crash with a core dump file. This is related to mmap() failing allocations during cache generation, according to an upstream bug report (803417). There is an upstream patch for this bug (6789e01e do not segfault in cache generation on mmap failure) and it's included in the apt package for other series (see below), so we only need to backport it to Trusty. Upstream commit: https://salsa.debian.org/apt- team/apt/commit/6789e01e9370b3b7f65d52138c5657eaa712b4d1 $ git describe --contains 6789e01e9370 1.1_exp16~5 $ rmadison apt apt | 1.0.1ubuntu2| trusty | source, ... apt | 1.0.1ubuntu2.19 | trusty-security | source, ... apt | 1.0.1ubuntu2.19 | trusty-updates | source, ... apt | 1.2.10ubuntu1 | xenial | source, ... apt | 1.6.1 | bionic
[Touch-packages] [Bug 1815129] Re: apt segfaults when generating cache file
Tested on apt-1.0.1ubuntu2.20 from trusty-proposed. Tried reproducing according to the test case from description, and verified that apt-cache does not crash: ubuntu@apt-stress:~/stress-ng$ dpkg -l | grep apt ii apt 1.0.1ubuntu2.20 (while having stress-ng running) ubuntu@apt-stress:~/stress-ng$ for i in `seq 1 1`;do apt-cache policy vsftpd;done E: Couldn't make mmap of 30021560 bytes - MMap-mmap (12: Cannot allocate memory) E: The package lists or status file could not be parsed or opened. ** Tags removed: verification-needed verification-needed-trusty ** Tags added: verification-done-trusty ** Tags added: verification-needed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1815129 Title: apt segfaults when generating cache file Status in apt package in Ubuntu: Fix Released Status in apt source package in Trusty: Fix Committed Status in apt package in Debian: Fix Released Bug description: [Impact] apt crashes (core dump) during cache creation [Description] When executing apt-cache several times on a memory constrained system, apt-cache can sometimes crash with a core dump file. This is related to mmap() failing allocations during cache generation, according to an upstream bug report (803417). There is an upstream patch for this bug (6789e01e do not segfault in cache generation on mmap failure) and it's included in the apt package for other series (see below), so we only need to backport it to Trusty. Upstream commit: https://salsa.debian.org/apt- team/apt/commit/6789e01e9370b3b7f65d52138c5657eaa712b4d1 $ git describe --contains 6789e01e9370 1.1_exp16~5 $ rmadison apt apt | 1.0.1ubuntu2| trusty | source, ... apt | 1.0.1ubuntu2.19 | trusty-security | source, ... apt | 1.0.1ubuntu2.19 | trusty-updates | source, ... apt | 1.2.10ubuntu1 | xenial | source, ... apt | 1.6.1 | bionic | source, ... apt | 1.7.0 | cosmic | source, ... apt | 1.8.0~rc2 | disco| source, ... [Test Case] 1) Deploy a Trusty (14.04 LTS) vm w/ 128M 2) Fetch latest stress-ng src code 2.1) git clone git://kernel.ubuntu.com/cking/stress-ng 2.2) cd stress-ng 2.3) make clean 2.4) make 3) Stress the mmap() with stress-ng 3.1) ./stress-ng --brk 2 --mmap 5 --vm 1 --mmap-bytes 90% 4) Disable swap (if any) 4.1) swapoff -a 5) for i in `seq 1 1`;do apt-cache policy vsftpd;done ... vsftpd: Installed: (none) Candidate: 3.0.2-1ubuntu2.14.04.1 Version table: 3.0.2-1ubuntu2.14.04.1 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages 3.0.2-1ubuntu2 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) ... [Regression Potential] The regression potential for this should be low, as it's a change in the failure path for memory allocations. This shouldn't be triggered during normal usage, and we'll thoroughly test the patched package with autopkgtests and perform scripted runs in memory-constrained systems with stress-ng. We also have a confirmation from an impacted user that the upstream patch fixes their issue without further problems. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1815129/+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 1815129] Re: apt segfaults when generating cache file
There are two armhf autopkgtest regressions for apt-1.0.1ubuntu2.20, in tests for apt [0] and autopkgtest [1]. From the autopkgtest pages we can see that these regressions were introduced long before this SRU, so it seems like a long standing issue unrelated to this patch. [0] http://autopkgtest.ubuntu.com/packages/a/apt/trusty/armhf [1] http://autopkgtest.ubuntu.com/packages/a/autopkgtest/trusty/armhf -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1815129 Title: apt segfaults when generating cache file Status in apt package in Ubuntu: Fix Released Status in apt source package in Trusty: Fix Committed Status in apt package in Debian: Fix Released Bug description: [Impact] apt crashes (core dump) during cache creation [Description] When executing apt-cache several times on a memory constrained system, apt-cache can sometimes crash with a core dump file. This is related to mmap() failing allocations during cache generation, according to an upstream bug report (803417). There is an upstream patch for this bug (6789e01e do not segfault in cache generation on mmap failure) and it's included in the apt package for other series (see below), so we only need to backport it to Trusty. Upstream commit: https://salsa.debian.org/apt- team/apt/commit/6789e01e9370b3b7f65d52138c5657eaa712b4d1 $ git describe --contains 6789e01e9370 1.1_exp16~5 $ rmadison apt apt | 1.0.1ubuntu2| trusty | source, ... apt | 1.0.1ubuntu2.19 | trusty-security | source, ... apt | 1.0.1ubuntu2.19 | trusty-updates | source, ... apt | 1.2.10ubuntu1 | xenial | source, ... apt | 1.6.1 | bionic | source, ... apt | 1.7.0 | cosmic | source, ... apt | 1.8.0~rc2 | disco| source, ... [Test Case] 1) Deploy a Trusty (14.04 LTS) vm w/ 128M 2) Fetch latest stress-ng src code 2.1) git clone git://kernel.ubuntu.com/cking/stress-ng 2.2) cd stress-ng 2.3) make clean 2.4) make 3) Stress the mmap() with stress-ng 3.1) ./stress-ng --brk 2 --mmap 5 --vm 1 --mmap-bytes 90% 4) Disable swap (if any) 4.1) swapoff -a 5) for i in `seq 1 1`;do apt-cache policy vsftpd;done ... vsftpd: Installed: (none) Candidate: 3.0.2-1ubuntu2.14.04.1 Version table: 3.0.2-1ubuntu2.14.04.1 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages 3.0.2-1ubuntu2 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) ... [Regression Potential] The regression potential for this should be low, as it's a change in the failure path for memory allocations. This shouldn't be triggered during normal usage, and we'll thoroughly test the patched package with autopkgtests and perform scripted runs in memory-constrained systems with stress-ng. We also have a confirmation from an impacted user that the upstream patch fixes their issue without further problems. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1815129/+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] Re: slapd process failure is not detected by systemd
** Bug watch added: Debian Bug tracker #926657 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926657 ** Also affects: openldap (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926657 Importance: Unknown Status: Unknown ** Patch added: "lp1821343-disco.debdiff" https://bugs.launchpad.net/debian/+source/openldap/+bug/1821343/+attachment/5254240/+files/lp1821343-disco.debdiff -- 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 Status in openldap package in Debian: Unknown 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] Re: slapd process failure is not detected by systemd
@slashd I don't think we need anything special for systemd in the
debian/{control,rules} files, since we're not shipping full systemd
support with this. The slapd service is still handled by systemd-sysv-
generator(8), so there's no service units that we need to include or
activate in dh_systemd rules.
To make sure things are working fine I went ahead and tested a package
upgrade with this debdiff:
ubuntu@disco:~$ dpkg -l | grep slapd
ii slapd 2.4.47+dfsg-3ubuntu1amd64
OpenLDAP server (slapd)
ubuntu@disco:~$ sudo apt-get --only-upgrade install slapd
ubuntu@disco:~$ dpkg -l | grep slapd
ii slapd 2.4.47+dfsg-3ubuntu2amd64
OpenLDAP server (slapd)
ubuntu@disco:~$ systemctl cat slapd
# /run/systemd/generator.late/slapd.service
# Automatically generated by systemd-sysv-generator
[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/slapd
Description=LSB: OpenLDAP standalone server (Lightweight Directory Access
Protocol)
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target
After=network-online.target
Wants=network-online.target
[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/slapd start
ExecStop=/etc/init.d/slapd stop
# /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf
[Service]
Type=forking
RemainAfterExit=no
Thanks!
--
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
Status in openldap package in Debian:
New
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
