SYSTEMD-JOURNALD@.SOCKET(8)

✨ NAME ✨

systemd-journald.service, systemd-journald.socket, systemd-journald-dev-log.socket, systemd-journald-audit.socket, systemd-journald@.service, systemd-journald@.socket, systemd-journald-varlink@.socket, systemd-journald — the Journal service 💖

(that's the section 8 page, bestie — say hi to your logs for me 🫶)

---

🌸 SYNOPSIS 🌸

systemd-journald.service
systemd-journald.socket
systemd-journald-dev-log.socket
systemd-journald-audit.socket
systemd-journald@.service
systemd-journald@.socket
systemd-journald-varlink@.socket
/usr/lib/systemd/systemd-journald

---

💅 DESCRIPTION 💅

okay so. systemd-journald is a system service that collects and stores logging data. It builds and maintains structured, indexed journals out of all the logging tea it receives, and the tea comes from a whole bunch of sources:

• Kernel log messages, via kmsg 👑
• Simple system log messages, via the libc syslog(3) call
• Structured system log messages via the native Journal API — peep sd_journal_print(3) and Native Journal Protocol[1]
• Standard output and standard error of service units. more deets further down, keep scrolling bestie
• Audit records, originating from the kernel audit subsystem 🔍

The daemon will implicitly collect a ton of metadata fields for each log message, and it does it in a secure and unfakeable way. See systemd.journal-fields(7) if you wanna know about all that collected metadata.

Log data collected by the journal is mostly text-based, but it can also carry binary data when that's needed. Individual fields making up a log record stored in the journal may be up to 2⁶⁴-1 bytes in size. yes. that many. no cap.

So where does it all live? The journal service stores log data either persistently below /var/log/journal or in a volatile way below /run/log/journal/ — and in that second case it's gone at reboot, poof, lost 😭. By default, log data is stored persistently if /var/log/journal/ exists during boot, with an implicit fallback to volatile storage otherwise. Wanna control it yourself? Use Storage= in journald.conf(5) to configure where log data is placed, independently of whether /var/log/journal/ exists.

Note that journald will initially use volatile storage, until a call to journalctl --flush (or sending SIGUSR1 to journald) causes it to switch to persistent logging (under the conditions mentioned above). This is done automatically on boot via "systemd-journal-flush.service".

On systems where /var/log/journal/ does not exist yet but where you do want persistent logging (and the default journald.conf is used), it's literally enough to create the directory and make sure it has the correct access modes and ownership:

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal

See journald.conf(5) for info about the configuration of this service. 🎀

---

🌈 STREAM LOGGING 🌈

The systemd service manager invokes all service processes with standard output and standard error connected to the journal by default. You can change that behaviour with the StandardOutput=/StandardError= unit file settings — see systemd.exec(5) for details. The journal takes the log byte stream it gets this way and turns it into individual log records, splitting the stream at newline ("\n", ASCII 10) and NUL bytes. clean. precise. iconic.

If systemd-journald.service is stopped, the stream connections associated with all services are terminated. Further writes to those streams by the service will result in EPIPE errors. So if you're a program logging to standard output/error, the recommended move is to ignore such errors and react gracefully. And heads up: if the SIGPIPE UNIX signal handler is not blocked or turned off, those write attempts will also result in such process signals being generated — see signal(7). To mitigate this, the systemd service manager explicitly turns off the SIGPIPE signal for all invoked processes by default (this may be changed for each unit individually via the IgnoreSIGPIPE= option, see systemd.exec(5) for details). After the standard output/standard error streams have been terminated they may not be recovered until the services they're associated with are restarted. 😬

Note that during normal operation, systemd-journald.service stores copies of the file descriptors for those streams in the service manager. If systemd-journald.service is restarted using systemctl restart or equivalent operation instead of a pair of separate systemctl stop and systemctl start commands (or equivalent operations), these stream connections are not terminated and survive the restart. It is thus safe to restart systemd-journald.service, but stopping it is not recommended. 💀

Also important: the log record metadata for records transferred via such standard output/error streams reflects the metadata of the peer the stream was originally created for. If the stream connection is passed on to other processes (like further child processes forked off the main service process), the log records will not reflect their metadata — they'll keep describing the original process. This is different from the other logging transports listed above, which are inherently record based and where the metadata is always associated with the individual record. iykyk.

In addition to the implicit standard output/error logging of services, stream logging is also available via the systemd-cat(1) command line tool.

Currently, the number of parallel log streams systemd-journald will accept is limited to 4096. When this limit is reached, further log streams may be established but will receive EPIPE right from the beginning. rude, honestly.

---

🦋 JOURNAL NAMESPACES 🦋

Journal 'namespaces' are two things at once, bestie: a mechanism for logically isolating the log stream of projects consisting of one or more services from the rest of the system, and a mechanism for improving performance. Multiple journal namespaces may exist simultaneously, each defining its own, independent log stream managed by its own instance of systemd-journald. Namespaces are independent of each other, both in the data store and in the IPC interface.

By default, only a single "default namespace exists, managed by systemd-journald.service (and its associated socket units). Additional namespaces are created by starting an instance of the systemd-journald@.service service template. The instance name is the namespace identifier — a short string used for referencing the journal namespace. Service units may be assigned to a specific journal namespace through the LogNamespace= unit file setting, see systemd.exec(5) for details. And the --namespace= switch of journalctl(1) may be used to view the log stream of a specific namespace. If you don't use the switch, you get the log stream of the default namespace — meaning log data from other namespaces is not visible. 🙈

Services associated with a specific log namespace may log via syslog(3), the native logging protocol of the journal, and via stdout/stderr; the logging from all three transports is associated with the namespace. ✨

By default, only the default namespace will collect kernel and audit log messages.

The systemd-journald instance of the default namespace is configured through /etc/systemd/journald.conf (see below), while the other instances are configured through /etc/systemd/journald@NAMESPACE.conf. The journal log data for the default namespace is placed in /var/log/journal/MACHINE_ID (see below) while the data for the other namespaces is located in /var/log/journal/MACHINE_ID.NAMESPACE.

---

🎀 SIGNALS 🎀

SIGUSR1

Request that journal data from /run/ is flushed to /var/ in order to make it persistent (if this is enabled). This must be used after /var/ is mounted, as otherwise log data from /run/ is never flushed to /var/ regardless of the configuration. Use the journalctl --flush command to request flushing of the journal files, and wait for the operation to complete. See journalctl(1) for details.

Added in version 186.

SIGUSR2

Request immediate rotation of the journal files. Use the journalctl --rotate command to request journal file rotation, and wait for the operation to complete. 🔄

Added in version 186.

SIGRTMIN+1

Request that all unwritten log data is written to disk. Use the journalctl --sync command to trigger journal synchronization, and wait for the operation to complete.

Added in version 228.

SIGHUP

Upon reception of the SIGHUP process signal, systemd-journald will reload its configuration values and update the kernel log buffer and journals to reflect the new configuration. If ReadKmsg= has changed, the kernel log buffer will be flushed and updated as part of the reload. The active journal (e.g., persistent, volatile) will continue to be used with the updated configuration. However, if the storage mode has changed from persistent to volatile and the current journal in use is the persistent journal, then the active journal will be switched to the volatile journal. 🫶

Added in version 258.

---

💜 CREDENTIALS 💜

systemd-journald supports the service credentials logic as implemented by ImportCredential=/LoadCredential=/SetCredential= (see systemd.exec(5) for details). The following credentials are used when passed in:

journal.forward_to_socket

May contain a socket address to which logs should be forwarded. See ForwardToSocket= in journald.conf(5).

Added in version 256.

journal.storage

May be used to specify where journal files should be stored. See Storage= in journald.conf(5).

Added in version 256.

---

⭐ KERNEL COMMAND LINE ⭐

A few configuration parameters from journald.conf may be overridden on the kernel command line:

systemd.journald.forward_to_syslog=, systemd.journald.forward_to_kmsg=, systemd.journald.forward_to_console=, systemd.journald.forward_to_wall=

Enables/disables forwarding of collected log messages to syslog, the kernel log buffer, the system console or wall.

See journald.conf(5) for information about these settings.

Added in version 186.

systemd.journald.max_level_store=, systemd.journald.max_level_syslog=, systemd.journald.max_level_kmsg=, systemd.journald.max_level_console=, systemd.journald.max_level_wall=, systemd.journald.max_level_socket=

Controls the maximum log level of messages that are stored in the journal, forwarded to syslog(3), kmsg, the console, wall(1), or a socket. This kernel command line options override the settings of the same names in the journald.conf(5) file.

Added in version 232.

Note that these kernel command line options are only honoured by the default namespace, see above. 👑

---

(part 1 done bestie, but we're not done-done — more of this page is coming, don't go anywhere 🌸)

🔐 ACCESS CONTROL 🔐

okay so bestie, here's the tea on who can read the journal ☕

Journal files are, by default, owned and readable by the "systemd-journal" system group — but they are not writable. so if you add a user to that group, boom, they can read the journal files. that's the whole vibe. 💅

By default, every user whose UID is outside the range of system users, dynamic service users, and the nobody user gets their own little set of journal files in /var/log/journal/. 🎀 wanna know more about UID ranges? go peek at Users, Groups, UIDs and GIDs on systemd systems[2]. but here's the thing — those journal files are not owned by the user, and that's on purpose: it's so the user can't just write to them directly. instead, file system ACLs do the work, making sure the user gets read access only. no sneaky writes, periodt. ✨

Additional users and groups can be granted access to journal files via file system access control lists (ACL). Distributions and admins might choose to grant read access to all members of the "wheel" and "adm" system groups with a command like this one:

# setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/

heads up bestie 💖 that command updates the ACLs both for the journal files that already exist and for the future journal files that get created in the /var/log/journal/ directory. two birds, one iconic command. 🦋

---

📁 FILES 📁

• /etc/systemd/journald.conf — this is where you configure how systemd-journald behaves. go read journald.conf(5) for the deets. (Added in version 206.)
• /run/log/journal/machine-id/*.journal, /run/log/journal/machine-id/*.journal~, /var/log/journal/machine-id/*.journal, /var/log/journal/machine-id/*.journal~ — systemd-journald writes entries into files in /run/log/journal/machine-id/ or /var/log/journal/machine-id/, and those files carry the ".journal" suffix. now, if the daemon gets stopped uncleanly, or if the files turn out to be corrupted, they get renamed with the ".journal~" suffix and systemd-journald just starts writing to a brand new file. 💀

/run/ is the one that gets used when /var/log/journal isn't available, or when Storage=volatile is set in the journald.conf(5) configuration file.

When systemd-journald stops writing to a journal file, that file gets renamed to "original-name@suffix.journal" (or "original-name@suffix.journal~"). those files are what we call "archived" and they will not be written to ever again. retired. main character no more. 👑

In general, it is safe to read or copy any journal file — active or archived, no stress. journalctl(1) and the functions in the sd-journal(3) library should be able to read all entries that have been fully written. 🫶

systemd-journald will automatically remove the oldest archived journal files to keep disk use in check. see SystemMaxUse= and the related settings in journald.conf(5). (Added in version 206.)

• /dev/kmsg, /dev/log, /run/systemd/journal/dev-log, /run/systemd/journal/socket, /run/systemd/journal/stdout — these are the sockets and other file node paths that systemd-journald will listen on, and you can see them right there in the file system. 👀 on top of these, systemd-journald can also listen for audit events using netlink(7) — whether it does depends on if "systemd-journald-audit.socket" is enabled or not. (Added in version 228.)

If journal namespacing is being used, these paths get slightly altered to include a namespace identifier — see above, bestie. 🌈

---

👀 SEE ALSO 👀

systemd(1), journalctl(1), journald.conf(5), systemd.journal-fields(7), sd-journal(3), systemd-coredump(8), setfacl(1), sd_journal_print(3), pydoc systemd.journal

---

📝 NOTES 📝

1. Native Journal Protocol https://systemd.io/JOURNAL_NATIVE_PROTOCOL
2. Users, Groups, UIDs and GIDs on systemd systems https://systemd.io/UIDS-GIDS

---

aaaand that's the whole page, bestie!! 🎉 you just read the entire SYSTEMD-JOURNALD.SERVICE(8) manpage and honestly? iconic behavior. this was systemd 262.1, straight from the SYSTEMD-JOURNALD.SERVICE(8) crew — go forth and read your logs like the Unix queen you are 👑💖✨