Sssd doesn't clean up PIDfile after crash
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
sssd (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Medium
|
Karl Stenerud |
Bug Description
[Impact]
sssd doesn't check for PIDfile validity when starting. As a result, a PID file from a crashed sssd process will prevent it from launching again until the pidfile is manually removed.
[Test Case]
$ lxc launch ubuntu:xenial tester
$ lxc exec tester bash
# apt update
# apt dist-upgrade -y
# apt install -y sssd
# echo "[nss]
filter_groups = root
filter_users = root
reconnection_
[pam]
reconnection_
[sssd]
config_file_version = 2
reconnection_
sbus_timeout = 30
services = nss, pam
domains = europe.
[domain/
#With this as false, a simple "getent passwd" for testing won't work. You must do getent passwd <email address hidden>
enumerate = false
cache_credentials = true
id_provider = ldap
access_provider = ldap
auth_provider = krb5
chpass_provider = krb5
ldap_uri = ldaps:/
ldap_search_base = dc=europe,
ldap_tls_cacert = /etc/ssl/
#This parameter requires that the DC present a completely validated certificate chain. If you're testing or don't care, use 'allow' or 'never'.
ldap_tls_reqcert = demand
krb5_realm = EUROPE.EXAMPLE.COM
dns_discovery_
ldap_schema = rfc2307bis
ldap_access_order = expire
ldap_account_
ldap_force_
ldap_user_
ldap_group_
ldap_user_
ldap_user_name = sAMAccountName
ldap_user_fullname = displayName
ldap_user_
ldap_user_principal = userPrincipalName
ldap_group_
ldap_group_name = sAMAccountName
#Bind credentials
ldap_default_
ldap_default_
[domain/
#With this as false, a simple "getent passwd" for testing won't work. You must do getent passwd <email address hidden>
enumerate = false
cache_credentials = true
id_provider = ldap
access_provider = ldap
auth_provider = krb5
chpass_provider = krb5
ldap_uri = ldaps:/
ldap_search_base = dc=asia,
ldap_tls_cacert = /etc/ssl/
#This parameter requires that the DC present a completely validated certificate chain. If you're testing or don't care, use 'allow' or 'never'.
ldap_tls_reqcert = demand
krb5_realm = ASIA.EXAMPLE.COM
dns_discovery_
ldap_schema = rfc2307bis
ldap_access_order = expire
ldap_account_
ldap_force_
ldap_user_
ldap_group_
ldap_user_
ldap_user_name = sAMAccountName
ldap_user_fullname = displayName
ldap_user_
ldap_user_principal = userPrincipalName
ldap_group_
ldap_group_name = sAMAccountName
#Bind credentials
ldap_default_
ldap_default_
# chmod 600 /etc/sssd/sssd.conf
# service sssd start
# pkill -KILL -F /var/run/sssd.pid
# service sssd start
# journalctl -xe
Oct 30 10:25:46 xtest sssd[7110]: SSSD is already running
[Regression Potential]
The change would be to check if the pid in the file is still active, which shouldn't cause regressions.
[Original Description]
After having crashed, sssd will not start, because the old PIDfile is still present. The fact that the process does not exist any more does not cause the PIDfile to be cleaned up.
This bug is already known, but not fixed, upstream: https:/
(also contains instructions for reproduction).
In our environment, with hundreds of computers running Ubuntu, the 'solution' brought forth in that discussion, to investigate and handle the issue manually, is not a serious option.
So I propose that we make systemd handle the PIDfile in case of a crash. With the attached one-line patch applied, systemd will clean up the PIDfile after a crash. That way, sssd doesn't have to make assumptions about namespaces, but the package still handles the issue.
Mandatory data:
Ubuntu version:
Ubuntu 16.04.4 LTS
Package version:
apt-cache policy $(dpkg -S /lib/systemd/
sssd-common: Installed: 1.13.4-1ubuntu1.11
What I expect to happen:
After
kill -9 $(cat /var/run/sssd.pid)
the command
systemctl start sssd
results in a running sssd.
What happens instead:
No sssd is running. Only after
rm /var/run/sssd.pid
systemctl start sssd
does it run again.
Related branches
- Andreas Hasenack: Approve
- Canonical Server: Pending requested
-
Diff: 56 lines (+34/-0)3 files modifieddebian/changelog (+7/-0)
debian/patches/add-back-pidfile.patch (+26/-0)
debian/patches/series (+1/-0)
Changed in sssd (Ubuntu Xenial): | |
assignee: | nobody → Karl Stenerud (kstenerud) |
description: | updated |
Changed in sssd (Ubuntu Xenial): | |
status: | Triaged → In Progress |
The attachment "Add PIDFile setting in sssd.service" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]