[Bug libc/29544] New: Regression in syslog(3) calls breaks RFC due to extra whitespace

["reg.glibc.8bngd at fraggod dot net" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29544

            Bug ID: 29544
           Summary: Regression in syslog(3) calls breaks RFC due to extra
                    whitespace
           Product: glibc
           Version: 2.36
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: reg.glibc.8bngd at fraggod dot net
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Updating glibc from 2.35 to 2.36 introduced extra whitespace character into
messages formatted and sent through syslog()/vsyslog() calls, which seem to
break RFC and at least one common syslogd implementation (rsyslog).

For example, given following code in syslog.c file:

  #include <syslog.h>
  int main(int argc, char **argv) {
    openlog("test", LOG_PID, LOG_LOCAL0);
    syslog(LOG_ERR, "test");
    return 0;
  }

And then running it like this:

  gcc -o syslog syslog.c && strace -e sendto ./syslog

Should produce the following line (expected behavior, RFC, glibc-2.35):

  sendto(3, "<131>Sep  3 02:32:14 test[81843"...

But instead, it produces this line (actual behavior, glibc-2.36):

  sendto(3, "<131>Sep  3 02:32:14  test[81843"...

Difference is a single whitespace character inserted after timestamp, which
breaks parser in e.g. rsyslog daemon, and was confirmed by its author to be
incorrect output, not conforming to RFC (in the comment here -
https://github.com/rsyslog/rsyslog/issues/4979#issuecomment-1235380700 ).

Behavior seem to be consistent between apps using syslog() and vsyslog() calls,
and seem to be a regression in glibc-2.36 release.
glibc-2.35 and earlier versions appear to be working correctly, producing
output without that extra space in an otherwise exactly same VM.

Given recent rewrite in misc/syslog.c here, guess it might be a simple bug that
managed to slip through the cracks.

Related bug reports (with some degree of initial misattribution on my part):
- rsyslog - https://github.com/rsyslog/rsyslog/issues/4979
- systemd - https://github.com/systemd/systemd/issues/24540
- Arch Linux - https://bugs.archlinux.org/task/75776

Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.