Oh, so I misunderstood. I thought 'journalctl' was giving the wrong output, but it's
actually in the text logs. Most likely this has nothing to do with systemd.

Hello,

I assume that you are using the imjournal module to load logs from the journal.
After analyzing the journal output you provided I can see two different kinds of logs:

The first one has identifier as "journal":
Sep 22 08:02:43 localhost journal[2202]: Boot VGA GPU /dev/dri/card0 selected as primary
with metadata: _COMM=gnome-shell
               SYSLOG_IDENTIFIER is NOT specified

The second one has identifier as "gnome-shell":
Sep 22 08:07:00 localhost gnome-shell[2202]: Window manager warning: W4 appears to be one of the offending windows with a timestamp of 275728.
with metadata: _COMM=gnome-shell
               SYSLOG_IDENTIFIER=gnome-shell

As you can see the SYSLOG_IDENTIFIER might be the difference here. Rsyslog does not work with the journals directly, instead we use the journal API. Whatever is passed through the API we display it according to a certain template. Thus, this is not a bug on the rsyslog side.
Let me know what you think. Thanks.

This description seems correct, except for the conclusions. As you note, the journal API is used,
which means that rsyslog has access to the same information that the journalctl client does.
The way that the entry looks is under rsyslog's control, being the result of the template used.

This is how the identifier is created:

if (journalGetData("SYSLOG_IDENTIFIER", &get, &length) >= 0) {
	CHKiRet(sanitizeValue(((const char *)get) + 18, length - 18, &sys_iden));
} else {
	CHKmalloc(sys_iden = strdup("journal"));
}

So the "journal" field in the message is treated as a fallback. Another thing that I observed from the provided logs is that there is a difference between the used transport method:
 * the first one is received via the native journal protocol(_TRANSPORT=journal)
 * the second one is received from a services's standard output or error output (_TRANSPORT=stdout)
I think the client should provide the SYSLOG_IDENTIFIER field.

If you would like to add the name of the command that invoked the message, then you can do that by specifying a custom template. Every single journal field is stored in a JSON object of the message. If you want to know what journal fields are available to you, then write out the message using the RSYSLOG_DebugFormat template, e.g.: *.* action(type="omfile" File="/var/log/test.log" Template="RSYSLOG_DebugFormat") and you will get something like:

$!:{ "PRIORITY": "6", "_BOOT_ID": "3895bc9247a64d8bbbd982a4e96bbbbb", "_MACHINE_ID": "77f6a405c2a74b63b06593a959555", "_HOSTNAME": "localhost.localdomain", "_TRANSPORT": "syslog", "_COMM": "logger", "_SELINUX_CONTEXT": "unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023", "_GID": "1000", "_UID": "1000", "SYSLOG_IDENTIFIER": "alakatos", "SYSLOG_FACILITY": "22", "SYSLOG_TIMESTAMP": "Sep 27 09:22:29 ", "MESSAGE": "My message 1", "_PID": "14999", "_SOURCE_REALTIME_TIMESTAMP": "1664263349893412" }

These fields are available and you can display as many of them as you would like.

Righto. So "journal" is not a very good fallback. Journalctl uses the following logic:
 
        PARSE_FIELD_VEC_ENTRY("SYSLOG_IDENTIFIER=", &identifier, &identifier_len),
        PARSE_FIELD_VEC_ENTRY("_COMM=", &comm, &comm_len),
        ...

        if (mode == OUTPUT_WITH_UNIT && ...) {
                /* Not interesting for rsyslog I guess */

        } else if (identifier && shall_print(identifier, identifier_len, flags)) {
                fprintf(f, " %.*s", (int) identifier_len, identifier);
                n += identifier_len + 1;
        } else if (comm && shall_print(comm, comm_len, flags)) {
                fprintf(f, " %.*s", (int) comm_len, comm);
                n += comm_len + 1;
        } else
                fputs(" unknown", f);

In other words, it uses SYSLOG_IDENTIFIER and falls back to _COMM.

That makes sense. Thanks for the detailed report. Let me take the issue upstream what they think about this.

Attached upstream pull request.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (rsyslog bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:6444