SYSTEMD.JOURNAL-FIELDS(7)

📦
version 262.1 · 16 versions
, in arch rolling

✨ SYSTEMD.JOURNAL-FIELDS(7) ✨

okay bestie, gather round, because this is systemd.journal-fields(7) and it's literally the lore drop for every single field that can show up inside a journal entry 💖 if you've ever run journalctl and gone "what is _TRANSPORT and why is it screaming at me", this page is your girl.

🌸 NAME 🌸

systemd.journal-fields — the special journal fields, aka the ones with Main Character Energy 👑

🦋 DESCRIPTION 🦋

So. Entries in the journal (the ones written by systemd-journald.service(8)) look like a UNIX process environment block syntactically, but plot twist: their field values can include binary data, and non-unique field names are allowed. 🙈

Mostly though, field values are formatted UTF-8 text strings — the binary encoding thing only kicks in where formatting as a UTF-8 text string makes basically no sense. Apps can freely define new fields whenever they want, but a select few fields have special meanings, and those are the ones listed below. 💅

Normally, a field shows up only once per log entry. However, there are special exceptions: some fields may appear more than once per entry, and when that's the case it's explicitly called out below. And listen — even though the logging subsystem puts no restrictions on which fields it'll accept non-unique values for, it is strongly recommended that you don't rely on that for the fields listed below (except where it says otherwise) so you don't create unnecessary incompatibilities with other applications. no cap. 🫶

🎀 USER JOURNAL FIELDS 🎀

These are the fields that get directly passed along from clients and stored in the journal. The people's fields, fr fr.

  • MESSAGE= — the human-readable message string for this entry. This is supposed to be the primary text shown to the user. It's usually not translated (though it might be in some cases), and it is not supposed to be parsed for metadata. Want multiple lines in one log entry? Separate them with newline characters (ASCII code 10), but encode the whole thing as a single MESSAGE= field. Do not add multiple values of this field type to the same entry (see the note above), because consuming applications generally do not expect that and are unlikely to show all the values in that case. 💀
  • MESSAGE_ID= — a 128-bit message identifier ID for recognizing certain message types, if you're into that. It should contain a 128-bit ID formatted as a lower-case hexadecimal string, with no separating dashes or anything like that. It's recommended to be a UUID-compatible ID, but that's not enforced, and it can be formatted differently. Devs can generate a fresh ID for this purpose with systemd-id128 new. ✨
  • PRIORITY= — a priority value between 0 ("emerg") and 7 ("debug"), formatted as a decimal string. This field is compatible with syslog's priority concept.
  • CODE_FILE=, CODE_LINE=, CODE_FUNC= — the code location that generated this message, if it's known. Contains the source filename, the line number, and the function name. 🧚
  • ERRNO= — the low-level Unix error number that caused this entry, if any. Contains the numeric value of errno(3) formatted as a decimal string.

Added in version 188.

  • INVOCATION_ID=, USER_INVOCATION_ID= — a randomized, unique 128-bit ID identifying each runtime cycle of the unit. This is different from _SYSTEMD_INVOCATION_ID in that it's only used for messages coming from systemd code (e.g. logs from the system/user manager, or from forked processes doing systemd-related setup).

Added in version 245.

  • SYSLOG_FACILITY=, SYSLOG_IDENTIFIER=, SYSLOG_PID=, SYSLOG_TIMESTAMP= — the syslog compatibility squad, containing the facility (formatted as a decimal string), the identifier string (i.e. the "tag"), the client PID, and the timestamp as specified in the original datagram. (Note that the tag is usually derived from glibc's program_invocation_short_name variable — see program_invocation_short_name(3).)

Heads up though: the journal service does not validate the values of any structured journal fields whose name isn't prefixed with an underscore, and that includes any syslog-related fields like these. So applications supplying a facility, PID, or log level are expected to do it properly formatted, i.e. as integers formatted as decimals. 👀

  • SYSLOG_RAW= — the original contents of the syslog line as received in the syslog datagram. This field is only included if the MESSAGE= field was modified compared to the original payload, or if the timestamp couldn't be located properly and isn't included in SYSLOG_TIMESTAMP=. Message truncation happens when the message contains leading or trailing whitespace (trailing and leading whitespace gets stripped), or when it contains an embedded NUL byte (the NUL byte and everything after it is not included). So the original syslog line is either stored as SYSLOG_RAW= or it can be recreated from the stored priority and facility, timestamp, identifier, and the message payload in MESSAGE=. 🍓

Added in version 240.

  • DOCUMENTATION= — a documentation URL with more info about the topic of the log message. Tools like journalctl will include a hyperlink to a URL specified this way in their output. Should be an "http://", "https://", "file:/", "man:" or "info:" URL.

Added in version 246.

  • TID= — the numeric thread ID (TID) the log message originates from.

Added in version 247.

  • UNIT=, USER_UNIT= — the name of a unit. Used by the system and user managers when logging about specific units.

When --unit=name or --user-unit=name are used with journalctl(1), a match pattern that includes "UNIT=name.service" or "USER_UNIT=name.service" will be generated. ✨

Added in version 251.

💜 TRUSTED JOURNAL FIELDS 💜

Fields prefixed with an underscore are trusted fields, i.e. fields that are implicitly added by the journal and cannot be altered by client code. They're the ones who were there first and don't take edits from strangers, periodt.

  • _PID=, _UID=, _GID= — the process number, user number, and group number of the process the journal entry originates from, formatted as decimals. Just so you know: entries obtained via "stdout" or "stderr" of forked processes will contain credentials valid for a parent process (the one that initiated the connection to systemd-journald). 😭
  • _COMM=, _EXE=, _CMDLINE= — the name, the executable path, and the command line of the process the journal entry originates from.
  • _CAP_EFFECTIVE= — the effective capabilities(7) of the process the journal entry originates from.

Added in version 206.

  • _AUDIT_SESSION=, _AUDIT_LOGINUID= — the session and login UID of the process the journal entry originates from, as maintained by the kernel audit subsystem.
  • _SYSTEMD_CGROUP=, _SYSTEMD_SLICE=, _SYSTEMD_UNIT=, _SYSTEMD_USER_UNIT=, _SYSTEMD_USER_SLICE=, _SYSTEMD_SESSION=, _SYSTEMD_OWNER_UID= — the control group path in the systemd hierarchy, the systemd slice unit name, the systemd unit name, the unit name in the systemd user manager (if any), the systemd session ID (if any), and the owner UID of the systemd user unit or systemd session (if any) of the process the journal entry originates from. That's a whole friend group right there. 👑
  • _SELINUX_CONTEXT= — the SELinux security context (label) of the process the journal entry originates from.
  • _SOURCE_REALTIME_TIMESTAMP= — the earliest trusted timestamp of the message, if any is known that's different from the reception time of the journal. The timestamp is the CLOCK_REALTIME time in microseconds, formatted as a decimal.
  • _SOURCE_BOOTTIME_TIMESTAMP= — the earliest trusted timestamp of the message in the CLOCK_BOOTTIME time, in the same format as _SOURCE_REALTIME_TIMESTAMP=.

Added in version 257.

  • _BOOT_ID= — the kernel boot ID for the boot the message was generated in, formatted as a 128-bit hexadecimal string.
  • _MACHINE_ID= — the machine ID of the originating host, as described in machine-id(5).
  • _SYSTEMD_INVOCATION_ID= — the invocation ID for the runtime cycle of the unit the message was generated in, as available to processes of the unit in $INVOCATION_ID (see systemd.exec(5)).

Added in version 233.

  • _HOSTNAME= — the hostname of the originating host.
  • _TRANSPORT= — how the entry was received by the journal service. The valid transports are:
    • audit — for those read from the kernel audit subsystem

Added in version 227.

  • driver — for internally generated messages

Added in version 205.

  • syslog — for those received via the local syslog socket with the syslog protocol

Added in version 205.

  • journal — for those received via the native journal protocol

Added in version 205.

  • stdout — for those read from a service's standard output or error output

Added in version 205.

  • kernel — for those read from the kernel

Added in version 205.

  • _STREAM_ID= — only applies to "_TRANSPORT=stdout" records: specifies a randomized 128-bit ID assigned to the stream connection when it was first created. This ID is useful for reconstructing individual log streams from the log records — all log records carrying the same stream ID originate from the same stream. 🌈

Added in version 235.

  • _LINE_BREAK= — only applies to "_TRANSPORT=stdout" records: indicates that the log message in the standard output/error stream was not terminated with a normal newline character ("\n", i.e. ASCII 10). Specifically, when set, this field is one of nul (in case the line was terminated by a NUL byte), line-max (in case the maximum log line length was reached, as configured with LineMax= in journald.conf(5)), eof (if this was the last log record of a stream and the stream ended without a final newline character), or pid-change (if the process which generated the log output changed in the middle of a line). Note that this record is not generated when a normal newline character was used to mark the log line end.

Added in version 235.

  • _NAMESPACE= — if this file was written by a systemd-journald instance managing a journal namespace that isn't the default, this field contains the namespace identifier. See systemd-journald.service(8) for the deets about journal namespaces.

Added in version 245.

  • _RUNTIME_SCOPE= — a string field that specifies the runtime scope in which the message was logged. If "initrd", the log message was processed while the system was running inside the initrd. If "system", the log message was generated after the system switched execution to the host root filesystem.

Added in version 252.

👑 KERNEL JOURNAL FIELDS

okay so these are the fields that show up when the kernel itself is the one yapping, bestie. Messages that came from the kernel, stored in the journal. Very main character of it. 🐧✨

  • _KERNEL_DEVICE= — the kernel device name, periodt. And the way it's formatted depends on the vibes of the device: if the entry is tied to a block device, you get the major and minor numbers of the device node, separated by ":" and prefixed with b. Same deal for character devices, except prefixed with c. For network devices, it's the interface index prefixed by n. And for literally every other device? It's the subsystem name prefixed by "+", followed by ":", followed by the kernel device name. So like <something>:<name>, iykyk. 💅

Added in version 189.

  • _KERNEL_SUBSYSTEM= — the kernel subsystem name. that's it, that's the field. 🦋

Added in version 189.

  • _UDEV_SYSNAME= — the kernel device name exactly how it shows up in the device tree below /sys/. 🎀

Added in version 189.

  • _UDEV_DEVNODE= — the device node path of this device, over in /dev/. 📁

Added in version 189.

  • _UDEV_DEVLINK= — extra symlink names pointing to the device node in /dev/. heads up: this field gets set more than once per entry all the time, so don't be surprised bestie. 💖

Added in version 189.

🫶 FIELDS TO LOG ON BEHALF OF A DIFFERENT PROGRAM

okay this section is so real — these are the fields programs use to say "hey, I'm logging, but NOT for myself, I'm doing it for somebody else." very generous of them honestly. 💐

Fields used by the systemd-coredump coredump kernel helper:

  • COREDUMP_UNIT=, COREDUMP_USER_UNIT= — used to annotate messages that contain coredumps from system and session units. go see coredumpctl(1) for the deets. 💀

Added in version 198.

Privileged programs (currently UID 0, so like, the VIPs only) may attach OBJECT_PID= to a message. This will instruct systemd-journald to attach additional fields on behalf of the caller. not me exposing extra info for you, but also yes me. ✨

  • *OBJECT_PID=PID* — PID of the program that this message pertains to. 🎯

Added in version 205.

  • OBJECT_UID=, OBJECT_GID=, OBJECT_COMM=, OBJECT_EXE=, OBJECT_CMDLINE=, OBJECT_AUDIT_SESSION=, OBJECT_AUDIT_LOGINUID=, OBJECT_SYSTEMD_CGROUP=, OBJECT_SYSTEMD_SESSION=, OBJECT_SYSTEMD_OWNER_UID=, OBJECT_SYSTEMD_UNIT=, OBJECT_SYSTEMD_USER_UNIT= — these are the additional fields that systemd-journald adds automatically. Their meaning is literally the same as _UID=, _GID=, _COMM=, _EXE=, _CMDLINE=, _AUDIT_SESSION=, _AUDIT_LOGINUID=, _SYSTEMD_CGROUP=, _SYSTEMD_SESSION=, _SYSTEMD_UNIT=, _SYSTEMD_USER_UNIT=, and _SYSTEMD_OWNER_UID= as described above — with ONE twist: instead of describing the process that logged the message, they describe the process identified by PID. see? the whole point. 💅

Added in version 205.

  • OBJECT_SYSTEMD_INVOCATION_ID= — another field that systemd-journald adds automatically. The meaning is mostly the same as _SYSTEMD_INVOCATION_ID=, with the difference described above (same switcharoo situation). 🌀

Added in version 235.

🌈 ADDRESS FIELDS

so when entries get serialized into external formats — like the Journal Export Format[1] or the Journal JSON Format[2] — the addresses of journal entries get serialized into fields prefixed with double underscores. ok but listen bestie, these are not proper fields when they're stored in the journal — they're for addressing metadata of entries. 🧚

⚠️ you literally cannot write these as part of structured log entries via calls like sd_journal_send(3). And they may also not be used as matches for sd_journal_add_match(3). so don't try it, I'm begging. 🙈
  • __CURSOR= — the cursor for the entry. A cursor is an opaque text string that uniquely describes the position of an entry in the journal, and it's portable across machines, platforms and journal files. so iconic for that. 🌟
  • __REALTIME_TIMESTAMP= — the wallclock time (CLOCK_REALTIME) at the point in time the entry was received by the journal, in microseconds since the epoch UTC, formatted as a decimal. heads up: this has different properties from "_SOURCE_REALTIME_TIMESTAMP=" — it's usually a bit later, but more likely to be monotonic. ⏰
  • __MONOTONIC_TIMESTAMP= — the monotonic time (CLOCK_MONOTONIC) at the point in time the entry was received by the journal, in microseconds, formatted as a decimal. And to actually be useful as an address for the entry, you gotta combine it with the boot ID in "_BOOT_ID=". don't forget that part. 🩷
  • __SEQNUM=, __SEQNUM_ID= — the sequence number (and the associated sequence number ID) of this journal entry in the journal file it originates from. See sd_journal_get_seqnum(3) for all the details. 🔢

Added in version 254.

🎀 SEE ALSO

systemd(1), systemd-journald.service(8), journalctl(1), journald.conf(5), sd-journal(3), coredumpctl(1), systemd.directives(7)

💖 NOTES

  1. Journal Export Format — https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format
  2. Journal JSON Format — https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format

and that's a wrap bestie!! 🫶 this was systemd 262.1, page SYSTEMD.JOURNAL-FIELDS(7), and no I will not stop being obsessed with journal fields. go log something structured and slay. 💅✨🌸

📦 where this page comes from
  • arch rolling: systemd 262.1-1 · LGPL-2.1-or-later AND CC0-1.0 AND GPL-2.0-or-later AND MIT-0
  • 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms