group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1777860@xxxxxxxxxxxxxxxxxx>]

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.stenerud@xxxxxxxxxxxxx>  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 user@xxxxxxxxxx
  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 user@xxxxxxxxxx
  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