Comment 0 for bug 1908065

[Impact]

 * On Ubuntu (Focal) 20.04, SSSD 2.2.3-3, logs in Journald have invalid (non-numeric) SYSLOG_PID. Any tooling collecting SYSLOG_PID further, or attempting to work with syslog directly, fail to parse the PID as number.

 * Systemd does not validate, and simply expects SYSLOG_PID as numeric integers formatted as decimal strings:
   https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#SYSLOG_FACILITY=

[Test Case]

 * Deploy fresh 20.04 image, and update:
   apt update && apt dist-upgrade

 * apt -qqy install sssd

 * cat << EOF > /etc/sssd/sssd.conf
[sssd]
  config_file_version = 2
  domains = EXAMPLE.COM
  services =

[nss]

[pam]

[sudo]

[domain/EXAMPLE.COM]
  id_provider = files
  access_provider = permit
EOF

 * chmod 600 /etc/sssd/sssd.conf

 * systemctl restart sssd.service

 * journalctl -o verbose -u sssd-sudo.service | grep SYSLOG_PID=
   SYSLOG_PID=sudo

 * journalctl -u sssd.service # Produces malformed example lines:
   Dec 07 14:10:00 servername sssd[be[1234]: Starting up

 * grep sssd /var/log/syslog # Displays non-numeric PIDs:
   Dec 7 08:00:00 servername sssd[be[EXAMPLE.COM]]: Starting up
   Dec 7 08:00:00 servername sssd[nss]: Starting up
   Dec 7 08:00:00 servername sssd[sudo]: Starting up
   Dec 7 08:00:00 servername sssd[pam]: Starting up

[Where problems could occur]

 * Someone might depend on the malformed output already, and have tooling in place to transform it manually.

[Other Info]

 * Is not reproducible on Ubuntu (Groovy) 20.10 containing SSSD 2.3.1-3. Considering Debian testing is currently at SSSD 2.4.0-1, it does not appear applicable to fix in upstream.