[Touch-packages] [Bug 1908065] Re: Invalid SYSLOG_PID for (systemd) journal messages
** No longer affects: systemd (Ubuntu) ** Also affects: sssd (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: sssd (Ubuntu) Status: Triaged => Fix Released ** Changed in: sssd (Ubuntu) Importance: Undecided => Low ** Changed in: sssd (Ubuntu Focal) Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1908065 Title: Invalid SYSLOG_PID for (systemd) journal messages Status in sssd package in Ubuntu: Fix Released Status in sssd source package in Focal: New Bug description: [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. * The package itself does not appear to provide any SYSLOG_PID. The SYSLOG_IDENTIFIER appears to instead 'leak' over into PID, hinting at trouble on systemd side. SSSD source at: https://github.com/SSSD/sssd/blob/sssd-2_2_3/src/util/sss_log.c#L110 * Applying a change to SYSLOG_IDENTIFIER (prefixing with "sssd[" and suffixing with "]") results in "SYSLOG_IDENTIFIER=sssd_be" being logged, and no SYSLOG_PID being reported. Cherry-picked upstream commit for testing: https://github.com/SSSD/sssd/commit/18233532b72e62452eac6886652fa633ba055d8c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1908065/+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 1908065] Re: Invalid SYSLOG_PID for (systemd) journal messages
Thank you for subscribing ubuntu-sponsors. Feel free to handles this after 2.2.3-3ubuntu0.3 reaches focal-updates, as that was published on focal-proposed yesterday (2021-01-22), and this change is not necessarily of such high priority compared to it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1908065 Title: Invalid SYSLOG_PID for (systemd) journal messages Status in sssd package in Ubuntu: Triaged Status in systemd package in Ubuntu: Invalid Bug description: [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. * The package itself does not appear to provide any SYSLOG_PID. The SYSLOG_IDENTIFIER appears to instead 'leak' over into PID, hinting at trouble on systemd side. SSSD source at: https://github.com/SSSD/sssd/blob/sssd-2_2_3/src/util/sss_log.c#L110 * Applying a change to SYSLOG_IDENTIFIER (prefixing with "sssd[" and suffixing with "]") results in "SYSLOG_IDENTIFIER=sssd_be" being logged, and no SYSLOG_PID being reported. Cherry-picked upstream commit for testing: https://github.com/SSSD/sssd/commit/18233532b72e62452eac6886652fa633ba055d8c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1908065/+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 1908065] Re: Invalid SYSLOG_PID for (systemd) journal messages
The attachment "sssd_2.2.3-3ubuntu0.4.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] ** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1908065 Title: Invalid SYSLOG_PID for (systemd) journal messages Status in sssd package in Ubuntu: Triaged Status in systemd package in Ubuntu: Invalid Bug description: [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. * The package itself does not appear to provide any SYSLOG_PID. The SYSLOG_IDENTIFIER appears to instead 'leak' over into PID, hinting at trouble on systemd side. SSSD source at: https://github.com/SSSD/sssd/blob/sssd-2_2_3/src/util/sss_log.c#L110 * Applying a change to SYSLOG_IDENTIFIER (prefixing with "sssd[" and suffixing with "]") results in "SYSLOG_IDENTIFIER=sssd_be" being logged, and no SYSLOG_PID being reported. Cherry-picked upstream commit for testing: https://github.com/SSSD/sssd/commit/18233532b72e62452eac6886652fa633ba055d8c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1908065/+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 1908065] Re: Invalid SYSLOG_PID for (systemd) journal messages
** Patch added: "sssd_2.2.3-3ubuntu0.4.debdiff" https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1908065/+attachment/5456023/+files/sssd_2.2.3-3ubuntu0.4.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1908065 Title: Invalid SYSLOG_PID for (systemd) journal messages Status in sssd package in Ubuntu: Triaged Status in systemd package in Ubuntu: Invalid Bug description: [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. * The package itself does not appear to provide any SYSLOG_PID. The SYSLOG_IDENTIFIER appears to instead 'leak' over into PID, hinting at trouble on systemd side. SSSD source at: https://github.com/SSSD/sssd/blob/sssd-2_2_3/src/util/sss_log.c#L110 * Applying a change to SYSLOG_IDENTIFIER (prefixing with "sssd[" and suffixing with "]") results in "SYSLOG_IDENTIFIER=sssd_be" being logged, and no SYSLOG_PID being reported. Cherry-picked upstream commit for testing: https://github.com/SSSD/sssd/commit/18233532b72e62452eac6886652fa633ba055d8c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1908065/+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 1908065] Re: Invalid SYSLOG_PID for (systemd) journal messages
Sorry Dan, I did not initially grasp the full implication of your message if it was intended that way. Thank you for the upstream commit linked. Will poke around a bit more and provide a proposed debdiff to be sponspored then, but to summarize from SSSD side: indeed not reproducible with a minimal C program (and is indeed Status: Invalid for systemd) as the sd_journal_send() branch never actually runs from SSSD side. The rules override_dh_auto_configure does not set --with- syslog=journald in the Focal version, and instead leaves the default --with-syslog=syslog path, indicated by Journald showing _TRANSPORT=syslog as well. That must be where the SYSLOG_PID parsing comes in to play, and that is the reason why the syslog messages are indeed malformed the way they are. The newer packages (for 20.10 and 21.04) set the Journald logging configuration flag, and have the referenced program name clean-up commit. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1908065 Title: Invalid SYSLOG_PID for (systemd) journal messages Status in sssd package in Ubuntu: Triaged Status in systemd package in Ubuntu: Invalid Bug description: [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. * The package itself does not appear to provide any SYSLOG_PID. The SYSLOG_IDENTIFIER appears to instead 'leak' over into PID, hinting at trouble on systemd side. SSSD source at: https://github.com/SSSD/sssd/blob/sssd-2_2_3/src/util/sss_log.c#L110 * Applying a change to SYSLOG_IDENTIFIER (prefixing with "sssd[" and suffixing with "]") results in "SYSLOG_IDENTIFIER=sssd_be" being logged, and no SYSLOG_PID being reported. Cherry-picked upstream commit for testing: https://github.com/SSSD/sssd/commit/18233532b72e62452eac6886652fa633ba055d8c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1908065/+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 1908065] Re: Invalid SYSLOG_PID for (systemd) journal messages
It does not appear that systemd-journald is automatically parsing
SYSLOG_IDENTIFIER. The following sample program:
#include
int main(int argc, char *argv[]) {
sd_journal_send("MESSAGE=%s", "Hello world!",
"SYSLOG_IDENTIFIER=%s", "sssd[sudo]",
NULL);
}
produces logs with:
MESSAGE=Hello world!
SYSLOG_IDENTIFIER=sssd[sudo]
There is no SYSLOG_PID, and SYSLOG_IDENTIFIER is the literal
"sssd[sudo]".
/var/log/syslog also contains: "
sssd[sudo][12345]: Hello world!"
systemd.journal-fields documentation also states the fields are not
explicitly validated, so that implies to me no processing on them should
be taking place.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1908065
Title:
Invalid SYSLOG_PID for (systemd) journal messages
Status in sssd package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Invalid
Bug description:
[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.
* The package itself does not appear to provide any SYSLOG_PID. The
SYSLOG_IDENTIFIER appears to instead 'leak' over into PID, hinting at
trouble on systemd side. SSSD source at:
https://github.com/SSSD/sssd/blob/sssd-2_2_3/src/util/sss_log.c#L110
* Applying a change to SYSLOG_IDENTIFIER (prefixing with "sssd[" and
suffixing with "]") results in "SYSLOG_IDENTIFIER=sssd_be" being logged, and no
SYSLOG_PID being reported.
Cherry-picked upstream commit for testing:
https://github.com/SSSD/sssd/commit/18233532b72e62452eac6886652fa633ba055d8c
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1908065/+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 1908065] Re: Invalid SYSLOG_PID for (systemd) journal messages
sssd is setting SYSLOG_IDENTIFIER to the debug_prg_name internal var, which is set via calls to server_setup(), and in focal (and probably earlier) that's set to a name like "sssd[sudo]". However the syslog MSG section TAG field format requires only alphanumeric characters: https://tools.ietf.org/html/rfc3164#section-4.1.3 therefore, providing an identifier of "sssd[sudo]" results in the TAG field (indicating the process name) to be "sssd" and "[sudo]" is the start of the CONTENT field. The convention specified in the RFC states that if the CONTENT field starts with "[PID]:" the value contained inside the brackets may be considered the PID, which is exactly what systemd-journald is doing. https://tools.ietf.org/html/rfc3164#section-5.3 So, when SYSLOG_IDENTIFIER is set to "sssd[sudo]" that results in a syslog message TAG section that's parsed as having program name 'sssd' and pid 'sudo'. This is fixed upstream in sssd with commit 00e7b1ada3d1c1071eac79b65c17cd2701c2ae6a, included in groovy and later. ** Changed in: systemd (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1908065 Title: Invalid SYSLOG_PID for (systemd) journal messages Status in sssd package in Ubuntu: Triaged Status in systemd package in Ubuntu: Invalid Bug description: [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. * The package itself does not appear to provide any SYSLOG_PID. The SYSLOG_IDENTIFIER appears to instead 'leak' over into PID, hinting at trouble on systemd side. SSSD source at: https://github.com/SSSD/sssd/blob/sssd-2_2_3/src/util/sss_log.c#L110 * Applying a change to SYSLOG_IDENTIFIER (prefixing with "sssd[" and suffixing with "]") results in "SYSLOG_IDENTIFIER=sssd_be" being logged, and no SYSLOG_PID being reported. Cherry-picked upstream commit for testing: https://github.com/SSSD/sssd/commit/18233532b72e62452eac6886652fa633ba055d8c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1908065/+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 1908065] Re: Invalid SYSLOG_PID for (systemd) journal messages
Hi Valters, This really seems to be a systemd issue: sssd never sets SYSLOG_PID when calling sd_journal_send(), yet journalctl shows e.g. SYSLOG_PID=sudo instead of an empty string. Looks like systemd is mixing the variables or leaking one into the others. The sssd upstream patch you pointed to may act as a partial workaround, but the logging is still odd as you noted. The sssd upstream devs agree the problem is likely on the systemd side in the bug report you opened [1]. I tried to install systemd and its dependencies from Groovy and Hirsute on a Focal system as a rough way to see if a newer version of systemd fixes the issue, but it kept behaving exactly the same. I think debugging this requires writing a reproducer in the form of a minimal C program calling sd_journal_send() like sssd does, having it log/set SYSLOG_PID even when it should not. I'm adding a systemd task to this bug report. Paride [1] https://github.com/SSSD/sssd/issues/5431, Dec 15 comment. ** Bug watch added: github.com/SSSD/sssd/issues #5431 https://github.com/SSSD/sssd/issues/5431 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1908065 Title: Invalid SYSLOG_PID for (systemd) journal messages Status in sssd package in Ubuntu: Triaged Status in systemd package in Ubuntu: New Bug description: [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. * The package itself does not appear to provide any SYSLOG_PID. The SYSLOG_IDENTIFIER appears to instead 'leak' over into PID, hinting at trouble on systemd side. SSSD source at: https://github.com/SSSD/sssd/blob/sssd-2_2_3/src/util/sss_log.c#L110 * Applying a change to SYSLOG_IDENTIFIER (prefixing with "sssd[" and suffixing with "]") results in "SYSLOG_IDENTIFIER=sssd_be" being logged, and no SYSLOG_PID being reported. Cherry-picked upstream commit for testing: https://github.com/SSSD/sssd/commit/18233532b72e62452eac6886652fa633ba055d8c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1908065/+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 1908065] Re: Invalid SYSLOG_PID for (systemd) journal messages
** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1908065 Title: Invalid SYSLOG_PID for (systemd) journal messages Status in sssd package in Ubuntu: Triaged Status in systemd package in Ubuntu: New Bug description: [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. * The package itself does not appear to provide any SYSLOG_PID. The SYSLOG_IDENTIFIER appears to instead 'leak' over into PID, hinting at trouble on systemd side. SSSD source at: https://github.com/SSSD/sssd/blob/sssd-2_2_3/src/util/sss_log.c#L110 * Applying a change to SYSLOG_IDENTIFIER (prefixing with "sssd[" and suffixing with "]") results in "SYSLOG_IDENTIFIER=sssd_be" being logged, and no SYSLOG_PID being reported. Cherry-picked upstream commit for testing: https://github.com/SSSD/sssd/commit/18233532b72e62452eac6886652fa633ba055d8c To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1908065/+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
