This bug was fixed in the package sssd - 1.13.4-1ubuntu1.12
---------------
sssd (1.13.4-1ubuntu1.12) xenial; urgency=medium
* d/p/add-back-pidfile.patch: Re-add PIDFILE entry to
/lib/systemd/system/sssd.service (LP: #1777860)
-- Karl Stenerud <karl.stene...@canonical.com> Wed, 31 Oct 2018
15:41:19 +0100
** Changed in: sssd (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1777860
Title:
Sssd doesn't clean up PIDfile after crash
Status in sssd package in Ubuntu:
Fix Released
Status in sssd source package in Xenial:
Fix Released
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_retries = 3
[pam]
reconnection_retries = 3
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = europe.example.com,asia.example.com
[domain/europe.example.com]
#With this as false, a simple "getent passwd" for testing won't work. You
must do getent passwd u...@domain.com
enumerate = false
cache_credentials = true
id_provider = ldap
access_provider = ldap
auth_provider = krb5
chpass_provider = krb5
ldap_uri = ldaps://dc1.europe.example.com,ldaps://dc2.europe.example.com
ldap_search_base = dc=europe,dc=example,dc=com
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
#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_domain = EUROPE.EXAMPLE.COM
ldap_schema = rfc2307bis
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
ldap_user_search_base = dc=europe,dc=example,dc=com
ldap_group_search_base = dc=europe,dc=example,dc=com
ldap_user_object_class = user
ldap_user_name = sAMAccountName
ldap_user_fullname = displayName
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_group_name = sAMAccountName
#Bind credentials
ldap_default_bind_dn =
cn=europe-ldap-reader,cn=Users,dc=europe,dc=example,dc=com
ldap_default_authtok = secret
[domain/asia.example.com]
#With this as false, a simple "getent passwd" for testing won't work. You
must do getent passwd u...@domain.com
enumerate = false
cache_credentials = true
id_provider = ldap
access_provider = ldap
auth_provider = krb5
chpass_provider = krb5
ldap_uri = ldaps://dc1.asia.example.com,ldaps://dc2.asia.example.com
ldap_search_base = dc=asia,dc=example,dc=com
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
#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_domain = ASIA.EXAMPLE.COM
ldap_schema = rfc2307bis
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
ldap_user_search_base = dc=asia,dc=example,dc=com
ldap_group_search_base = dc=asia,dc=example,dc=com
ldap_user_object_class = user
ldap_user_name = sAMAccountName
ldap_user_fullname = displayName
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_group_name = sAMAccountName
#Bind credentials
ldap_default_bind_dn = cn=asia-ldap-reader,cn=Users,dc=asia,dc=example,dc=com
ldap_default_authtok = secret" >/etc/sssd/sssd.conf
# 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://pagure.io/SSSD/sssd/issue/3528
(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/system/sssd.service )
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1777860/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
