JOURNALCTL(1)

📦

version 262.1 · 16 versions

👑 journalctl — the manual page, but make it slay

okay bestie, welcome to journalctl(1) 💅 this is the tool that reads your logs out of the systemd journal, and honestly? she's iconic. let's get into it.

✨ NAME ✨

journalctl — print log entries from the systemd journal 🫶

🌸 SYNOPSIS 🌸

journalctl [OPTIONS...] [MATCHES...]

💖 DESCRIPTION 💖

journalctl is your girl for printing out the log entries that got stored in the journal by systemd-journald.service(8) and systemd-journal-remote.service(8). that's literally her whole job. no cap.

if you call her with zero parameters, she shows you the contents of the journal that the calling user can actually access, and she starts with the oldest entry collected. oldest first, bestie. we go in order. 🦋

if you pass one or more match arguments, the output gets filtered accordingly. a match looks like "FIELD=VALUE", like for example "_SYSTEMD_UNIT=httpd.service", and it refers to the components of a structured journal entry. want the whole list of well-known fields? that's in systemd.journal-fields(7). go look, i'll wait. 💜

here's the tea on how multiple matches combine, because this trips people up:

if multiple matches are specified matching different fields, the log entries get filtered by both — so the output only shows entries that match all of the specified matches of this kind (logical AND, basically).
if two matches apply to the same field, they're automatically matched as alternatives — so the output shows entries matching any of the specified matches for that same field (logical OR).
finally, the character "+" may appear as a separate word between other terms on the command line. this causes all matches before and after to be combined in a disjunction (i.e. logical OR). ✨

you can also filter entries by handing over an absolute file path as an argument. the file path may be a file or a symbolic link, and the file must exist at the time of the query (no time traveling, babe). here's what happens depending on what that path points at:

if the file path refers to an executable binary, an "_EXE=" match for the canonicalized binary path gets added to the query.
if the file path refers to an executable script, a "_COMM=" match for the script name gets added to the query.
if the file path refers to a device node, "_KERNEL_DEVICE=" matches get added to the query for the kernel name of the device and for each of its ancestor devices.

symbolic links are dereferenced, kernel names are synthesized, and parent devices are identified from the environment at the time of the query. in general, a device node is the best proxy for an actual device, because log entries don't usually contain fields that identify an actual device. 😭

⚠️ for the resulting log entries to be correct for the actual device, the relevant parts of the environment at the time the entry was logged — in particular the actual device corresponding to the device node — must have been the same as those at the time of the query. and because device nodes generally change their corresponding devices across reboots, specifying a device node path causes the resulting entries to be restricted to those from the current boot. so like, keep that in mind fr fr.

you can pile on additional constraints using options like --boot, --unit=, etc., to further limit what entries will be shown. and yes, that's logical AND on top of everything else. 🎀

output is interleaved from all accessible journal files — whether they're rotated or currently being written, and regardless of whether they belong to the system itself or are accessible user journals. want to know which files are actually being shown? use the --header option. she'll spill. 👑

the set of journal files that get used can be modified with the --user, --system, --directory=, and --file= options — see below, bestie, they're all right there. ⭐

permissions check 🔐 — all users are granted access to their private per-user journals. but by default, only root and users who are members of a few special groups are granted access to the system journal and the journals of other users. members of the groups "systemd-journal", "adm", and "wheel" can read all journal files. note that the two latter groups traditionally have additional privileges specified by the distribution. members of the "wheel" group can often perform administrative tasks. so like, if you can't see something, it's probably a group thing. 😭

the output is paged through less by default, and long lines are "truncated" to screen width. the hidden part can be viewed by using the left-arrow and right-arrow keys. paging can be disabled — see the --no-pager option and the "Environment" section below. 🌈

when outputting to a tty, lines are colored according to priority:

lines of level ERROR and higher are colored red 🔥
lines of level WARNING are colored yellow
lines of level NOTICE are highlighted
lines of level INFO are displayed normally
lines of level DEBUG are colored grey

and if you ever want to write entries to the journal, a few methods exist. in general, output from systemd units is automatically connected to the journal — see systemd-journald.service(8). plus, systemd-cat(1) may be used to send messages to the journal directly. 💅

🎀 SOURCE OPTIONS 🎀

these options control where to read journal records from. pick your source, bestie:

--system, --user — show messages from system services and the kernel (with --system). show messages from service of current user (with --user). if neither is specified, show all messages that the user can see. 👀

the --user option affects how --unit= arguments are treated — see --unit=.

note that --user only works if persistent logging is enabled, via the Storage= setting in journald.conf(5). no persistent logs, no vibes. 😭

Added in version 205.

-M, --machine= — show messages from a running, local container. specify a container name to connect to. 🫶

Added in version 209.

-m, --merge — show entries interleaved from all available journals, including remote ones. ✨

Added in version 190.

-D DIR, --directory=DIR — takes a directory path as argument. if specified, journalctl will operate on the specified journal directory DIR instead of the default runtime and system journal paths. 🦋

Added in version 187.

-i GLOB, --file=GLOB — takes a file glob as an argument. if specified, journalctl will operate on the specified journal files matching GLOB instead of the default runtime and system journal paths. may be specified multiple times, in which case files will be suitably interleaved. 🌸

Added in version 205.

--root=ROOT — takes a directory path as an argument. if specified, journalctl will operate on journal directories and catalog file hierarchy underneath the specified directory instead of the root directory — e.g. --update-catalog will create ROOT/var/lib/systemd/catalog/database, and journal files under ROOT/run/journal/ or ROOT/var/log/journal/ will be displayed. 💜

Added in version 201.

--image=IMAGE — takes a path to a disk image file or block device node. if specified, journalctl will operate on the file system in the indicated disk image. this option is similar to --root=, but operates on file systems stored in disk images or block devices, which gives you an easy way to extract log data from disk images. the disk image should either contain just a file system or a set of file systems within a GPT partition table, following the UAPI.2 Discoverable Partitions Specification [1]. for further information on supported disk images, see systemd-nspawn(1)'s switch of the same name. 🔥

Added in version 247.

--image-policy=policy — takes an image policy string as argument, as per systemd.image-policy(7). the policy is enforced when operating on the disk image specified via --image=, see above. if not specified, defaults to the "*" policy, i.e. all recognized file systems in the image are used. ⭐
--namespace=NAMESPACE — takes a journal namespace identifier string as argument. if not specified, the data collected by the default namespace is shown. if specified, shows the log data of the specified namespace instead. 🧚

the special cases, because they're giving main character energy:

if the namespace is specified as "*", data from all namespaces is shown, interleaved.
if the namespace identifier is prefixed with "+", data from the specified namespace and the default namespace is shown, interleaved — but no other.

for details about journal namespaces see systemd-journald.service(8).

Added in version 245.

[1] UAPI.2 Discoverable Partitions Specification 💖

(more parts coming, bestie — don't go anywhere)

💖 FILTERING OPTIONS 💖

okay bestie, this is the part where you get to be picky. these options control how journal records get filtered, aka how you tell journalctl "no babe, not ALL of it, just this bit" ✨

-S, --since=, -U, --until= — start showing entries on or newer than the date you pass, or on or older than it, respectively 🫶. date specs should look like "2012-10-30 18:17:16". omit the time part and "00:00:00" gets assumed. omit only the seconds and ":00" gets assumed. omit the date and it assumes today. you can also just say "yesterday", "today" or "tomorrow" — those mean 00:00:00 of the day before today, today, or the day after today, respectively. "now" is literally rn. and finally you can do relative times prefixed with - or +, meaning before or after the current time. for the full tea on time and date specs, see systemd.time(7). also heads up: --output=short-full prints timestamps that follow precisely this format 👑

Added in version 195.

-c, --cursor= — start showing entries from the location in the journal that the cursor you pass points at 📍

Added in version 193.

--after-cursor= — same vibe but it starts after that location instead of at it. the cursor shows up when you use the --show-cursor option 🎀

Added in version 206.

--cursor-file=FILE — if FILE exists and has a cursor in it, start showing entries after that spot. otherwise just show entries according to whatever other options you gave. then at the end, it writes the cursor of the last entry back into FILE. this is THE trick for continuously reading the journal by calling journalctl over and over sequentially 🔁

Added in version 242.

-b [[ID][±offset]|all], --boot[=[ID][±offset]|all] — show messages from a specific boot. this adds a match for "_BOOT_ID=" 🥾

the argument can be empty, in which case you get logs for the current boot.

if you skip the boot ID, a positive offset looks up boots starting from the beginning of the journal, and an equal-or-less-than zero offset looks up boots starting from the end of the journal. so 1 = the first boot found in the journal in chronological order, 2 = the second and so on. meanwhile -0 = the last boot, -1 = the boot before last, etc. an empty offset is equivalent to -0, except when the current boot isn't the last boot (like when --directory= was specified to peek at logs from a different machine 👀).

if you give the 32-character ID, it may optionally be followed by an offset that identifies the boot relative to the one given by boot ID. negative values = earlier boots, positive values = later boots. if offset isn't specified, zero is assumed and you get the logs for the boot given by ID.

the special argument all can be used to negate the effect of an earlier use of -b 🙅

Added in version 186.

-u, --unit=UNIT|PATTERN — show messages for the specified systemd unit UNIT (like a service unit), or for any of the units matched by PATTERN. if you give a pattern, a list of unit names found in the journal gets compared against it and everything that matches gets used 🔍. for each unit name, a match is added for messages from the unit ("_SYSTEMD_UNIT=UNIT"), plus extra matches for messages from systemd and messages about coredumps for that unit. a match is also added for "_SYSTEMD_SLICE=UNIT", so if the UNIT you gave is a systemd.slice(5) unit, all the logs of children of the slice get shown 🌈

with --user, all --unit= arguments get converted to match user messages as if you'd specified them with --user-unit=.

this parameter can be specified multiple times 💅

Added in version 195.

--user-unit= — show messages for the specified user session unit. this adds a match for messages from the unit ("_SYSTEMD_USER_UNIT=" and "_UID=") plus extra matches for messages from session systemd and messages about coredumps for that unit. a match is also added for "_SYSTEMD_USER_SLICE=UNIT", so if the UNIT you gave is a systemd.slice(5) unit, all the logs of children of the unit get shown 🌸

this parameter can be specified multiple times 💅

Added in version 198.

-I, --invocation=ID[±offset]|offset — show messages from a specific invocation of a unit. this adds a match for "_SYSTEMD_INVOCATION_ID=", "OBJECT_SYSTEMD_INVOCATION_ID=", "INVOCATION_ID=", "USER_INVOCATION_ID=" 🎯

a positive offset looks up the invocations of a systemd unit from the beginning of the journal, and zero or a negative offset looks up invocations starting from the end of the journal. so 1 = the first invocation found in the journal in chronological order, 2 = the second and so on. while 0 = the latest invocation, -1 = the invocation before the latest, etc.

if you give the 32-character ID, it may optionally be followed by ±offset which identifies the invocation relative to the one given by invocation ID. negative values = earlier invocations, positive values = later invocations. if ±offset isn't specified, zero is assumed and you get the logs for the invocation given by ID.

-I is equivalent to --invocation=0, and logs for the latest invocation get shown ✨

when an offset is specified, a unit name must be specified with the -u/--unit= or --user-unit= option ⚠️

when specified with -b/--boot=, then invocations are searched within the specified boot.

Added in version 257.

-t, --identifier=SYSLOG_IDENTIFIER — show messages for the specified syslog identifier SYSLOG_IDENTIFIER 🏷️

this parameter can be specified multiple times 💅

Added in version 217.

-T, --exclude-identifier=SYSLOG_IDENTIFIER — exclude messages for the specified syslog identifier SYSLOG_IDENTIFIER 🚫

this parameter can be specified multiple times 💅

Added in version 256.

-p, --priority= — filter output by message priorities or priority ranges. takes either a single numeric or textual log level (i.e. between 0/"emerg" and 7/"debug"), or a range of numeric/text log levels in the form FROM..TO 📊. the log levels are the usual syslog log levels as documented in syslog(3), i.e. "emerg" (0), "alert" (1), "crit" (2), "err" (3), "warning" (4), "notice" (5), "info" (6), "debug" (7). if you give a single log level, all messages with that log level or a lower (hence more important) log level get shown. if you give a range, all messages within the range get shown, including both the start and the end value of the range. this adds "PRIORITY=" matches for the priorities you specified 💖

Added in version 188.

--facility= — filter output by syslog facility. takes a comma-separated list of numbers or facility names. the names are the usual syslog facilities as documented in syslog(3) 📋. --facility=help can be used to display a list of known facility names and exit.

Added in version 245.

-g, --grep= — filter output to entries where the MESSAGE= field matches the regular expression you pass 🔎. PERL-compatible regular expressions are used, see pcre2pattern(3) for a detailed description of the syntax.

if the pattern is all lowercase, matching is case insensitive. otherwise matching is case sensitive. this can be overridden with the --case-sensitive option, see below 👇

when used with --lines= (not prefixed with "+"), --reverse is implied.

Added in version 237.

--case-sensitive[=BOOLEAN] — make pattern matching case sensitive or case insensitive 🅰️🅱️

Added in version 237.

-k, --dmesg — show only kernel messages 🐧. this adds the match "_TRANSPORT=kernel". this implies --boot=0 unless explicitly specified otherwise.

Added in version 205.

✨ OUTPUT OPTIONS ✨

okay bestie, these ones control how your journal records actually get printed. the whole aesthetic of your logs, basically 💅

-o, --output= — controls the formatting of the journal entries that get shown. it takes one of these, and each one is a whole vibe:
- short — the default, and it generates output that's mostly identical to the formatting of classic syslog files, showing one line per journal entry.

Added in version 206. 💖

short-full — very similar, but it shows timestamps in the exact format that --since= and --until= accept. and unlike the timestamp info in short mode, this one includes weekday, year and timezone info in the output, and it's locale-independent.

Added in version 232.

short-iso — very similar, but shows timestamps in the RFC 3339[2] profile of ISO 8601.

Added in version 206.

short-iso-precise — same as short-iso but with full microsecond precision. ✨

Added in version 234.

short-precise — very similar, but shows classic syslog timestamps with full microsecond precision.

Added in version 207.

short-monotonic — very similar, but shows monotonic timestamps instead of wallclock timestamps. time is fake, monotonic is forever 🕰️

Added in version 206.

short-delta — same as short-monotonic but it also includes the time difference to the previous entry. maybe-unreliable time differences get marked with a "*".

Added in version 252.

short-unix — very similar, but shows seconds passed since January 1st 1970 UTC instead of wallclock timestamps ("UNIX time"). the time is shown with microsecond accuracy.

Added in version 230.

verbose — shows the full-structured entry items with all fields. every single one. no secrets here 👀

Added in version 206.

export — serializes the journal into a binary (but mostly text-based) stream, suitable for backups and network transfer (see Journal Export Format[3] for more info). to import that binary stream back into native journald format, use systemd-journal-remote(8).

Added in version 206.

json — formats entries as JSON objects, separated by newline characters (see Journal JSON Format[4] for more info). field values are generally encoded as JSON strings, with three exceptions:
1. fields larger than 4096 bytes are encoded as null values. (this may be turned off by passing --all, but be aware that this may allocate overly long JSON objects.)
2. journal entries permit non-unique fields within the same log entry, and JSON does not allow non-unique fields within objects. so if a non-unique field is encountered, a JSON array is used as the field value, listing all field values as elements.
3. fields containing non-printable or non-UTF8 bytes are encoded as arrays containing the raw bytes, each individually formatted as unsigned numbers.

note that this encoding is reversible (with the exception of the size limit).

Added in version 206.

json-pretty — formats entries as JSON data structures, but spreads them over multiple lines so actual humans can read them. considerate king behavior 👑

Added in version 206.

json-sse — formats entries as JSON data structures, but wraps them in a format suitable for Server-Sent Events[5].

Added in version 206.

json-seq — formats entries as JSON data structures, but prefixes them with an ASCII Record Separator character (0x1E) and suffixes them with an ASCII Line Feed character (0x0A), in accordance with JavaScript Object Notation (JSON) Text Sequences[6] ("application/json-seq").

Added in version 240.

cat — generates a very terse output, only showing the actual message of each journal entry with no metadata, not even a timestamp. if you combine it with the --output-fields= option, it'll output the listed fields for each log record instead of the message.

Added in version 206.

with-unit — similar to short-full, but it prefixes the unit and user unit names instead of the traditional syslog identifier. super useful when you're using templated instances, because it'll include the arguments in the unit names.

Added in version 239.

--truncate-newline — truncates each log message at the first newline character on output, so only the first line of each message gets displayed. one line only, no rambling 🫶

Added in version 254.

--output-fields= — a comma separated list of the fields that should be included in the output. this only has an effect for the output modes that would normally show all fields (verbose, export, json, json-pretty, json-sse and json-seq), plus on cat. for the former group, the "__CURSOR", "__REALTIME_TIMESTAMP", "__MONOTONIC_TIMESTAMP", and "_BOOT_ID" fields are always printed.

Added in version 236.

-n, --lines= — shows the most recent journal events and limits how many events are shown. the argument is a positive integer, or "all" to disable the limit entirely. also, if the number is prefixed with "+", the oldest journal events are used instead. the default value is 10 if no argument is given.

if --follow is used, this option is implied. when it's not prefixed with "+" and it's used with --grep=, --reverse is implied.

-r, --reverse — reverses the output so the newest entries show up first. chronological? never heard of her 💀

Added in version 198.

--show-cursor — the cursor gets shown after the last entry, after two dashes, like this:

-- cursor: s=0639...

the format of the cursor is private and subject to change. so don't go building anything on top of it, bestie 🙈

Added in version 209.

--utc — expresses time in Coordinated Universal Time (UTC). 🌍

Added in version 217.

-x, --catalog — augments log lines with explanation texts from the message catalog. this adds explanatory help texts to log messages in the output wherever they're available. these short help texts explain the context of an error or log event, possible solutions, plus pointers to support forums, developer documentation, and any other relevant manuals. note that help texts are not available for all messages, only for selected ones. for more info on the message catalog, see Journal Message Catalogs[7].

Note: when you're attaching journalctl output to bug reports, please do not use -x.

Added in version 196.

-W, --no-hostname — don't show the hostname field of log messages. this switch only has an effect on the short family of output modes (see above).

Note: this option does not remove occurrences of the hostname from log entries themselves, so it does not prevent the hostname from being visible in the logs. it's giving hiding-from-the-wrong-thing 😭

Added in version 230.

--no-full, --full, -l — ellipsizes fields when they don't fit in the available columns. the default is to show full fields, letting them wrap or get truncated by the pager, if one is used.

the old options -l/--full are not useful anymore, except to undo --no-full. periodt.

Added in version 196.

-a, --all — shows all fields in full, even if they include unprintable characters or are very long. by default, fields with unprintable characters get abbreviated as "blob data". (note that the pager may escape unprintable characters again.)
-f, --follow — shows only the most recent journal entries, and then continuously prints new entries as they're appended to the journal, until Ctrl+C is hit (or the tool is otherwise terminated). main character energy, just watching the logs scroll forever 🦋

journalctl will send an sd_notify(3) "READY=1" message once it has initialized and successfully established its watch on the journal.

--no-tail — shows all stored output lines, even in follow mode. undoes the effect of --lines=.
-q, --quiet — suppresses all informational messages (i.e. "-- Journal begins at ...", "-- Reboot --"), plus any warning messages regarding inaccessible system journals when run as a normal user. shhh. silence. peace. 🎀
--synchronize-on-exit= — takes a boolean argument. if true, and you're operating in --follow mode, a journal synchronization request (equivalent to journalctl --sync) is issued when SIGTERM/SIGINT is received, and log output continues until this request completes. this is useful for synchronizing journal log output to the runtime of services or external events, ensuring that any log data enqueued to the logging subsystem by the time SIGTERM/SIGINT is issued is guaranteed to be processed and displayed by the time log output ends. defaults to false.

Added in version 258.

these ones control page support, aka who gets to page your output:

--no-pager — do not pipe output into a pager.
-e, --pager-end — immediately jumps to the end of the journal inside the implied pager tool. this implies --lines=1000 and --boot=0 unless you explicitly specify otherwise, to guarantee that the pager won't buffer logs of unbounded size. note that this option is only supported for the less(1) pager.

Added in version 198.

🔐 FORWARD SECURE SEALING (FSS) OPTIONS 🔐

these ones may be used together with the --setup-keys command described below:

--interval= — specifies the change interval for the sealing key when generating an FSS key pair with --setup-keys. shorter intervals increase CPU consumption but shorten the time range of undetectable journal alterations. defaults to 15min. ⏳

Note, --output=json-sse and --output=json-seq are silently migrated to --output=json.

Added in version 189.

--verify-key= — specifies the FSS verification key to use for the --verify operation.

Added in version 189.

--force — when --setup-keys is passed and Forward Secure Sealing (FSS) has already been configured, this recreates the FSS keys.

Added in version 206.

👑 COMMANDS 👑 (the main character section, honestly)

okay so these are the commands, bestie. and listen — if you don't specify any of them, the default is just to display journal records. no thoughts, just logs. 💅

-N, --fields — prints every single field name that's currently being used across all the entries in the journal. all of them. the whole roster. 🌈

Added in version 229.

-F, --field= — you give it a field, and it prints all the possible data values that field can take across all entries. like, every value it's ever shown up with. so useful fr fr. 🔍

Added in version 195.

--list-boots — shows you a cute tabular list of boot numbers (relative to the current boot, iykyk), their IDs, and the timestamps of the first and last message for each boot. 🥾
- if you pair it with -n/--lines=[+]N, you only get the first N entries (when the number has a + in front) or the last N entries (no prefix).
- if you add -r/--reverse, the list comes out in reverse order. icon behavior.

Added in version 209.

--list-invocations — lists the invocation IDs of a unit. heads up: this one requires a unit name via -u/--unit= or --user-unit=, no skipping that step. 🚨 it shows a tabular list of invocation numbers (relative to the current or latest invocation), their IDs, and the timestamps of the first and last message for that invocation.
- when -b/-boot is specified, invocations in the boot get shown.
- with -n/--lines=[+]N, only the first N entries (when the number is prefixed with +) or the last N entries (no prefix) show up.
- with -r/--reverse, the list flips into reverse order.

Added in version 257.

--disk-usage — shows the current disk usage of all journal files. it's the sum of the disk usage of all archived AND active journal files. yes bestie, both. 💾

Added in version 190.

--vacuum-size=, --vacuum-time=, --vacuum-files= — the cleanup crew. 🧹✨
- --vacuum-size= removes the oldest archived journal files until the disk space they use falls below the size you gave it. it takes the usual "K", "M", "G" and "T" suffixes (base of 1024, no cap).
- --vacuum-time= removes archived journal files that are older than the timespan you specify. it accepts the usual "s" (which is the default), "m", "h", "days", "weeks", "months", and "years" suffixes — peep systemd.time(7) for the deets.
- --vacuum-files= leaves only the number of separate journal files you asked for. that's it, that's the whole job.

⚠️ okay important note: running --vacuum-size= has only an indirect effect on the output shown by --disk-usage, because --disk-usage includes active journal files, while the vacuuming operation only operates on archived journal files. and similarly, --vacuum-files= might not actually reduce the number of journal files below the number you specified, since it will not remove active journal files. 💀 so don't come for me when the number doesn't match.

--vacuum-size=, --vacuum-time= and --vacuum-files= can be combined in a single invocation to enforce any combination of a size, a time and a number-of-files limit on the archived journal files. and if you set any of these three parameters to zero, that's equivalent to not enforcing that specific limit at all — so it's redundant, bestie, just don't. 🙈

these three switches can also be combined with --rotate into one command. when you do that, all active files get rotated first, and then the vacuuming operation you asked for runs right after. the rotation means all currently active files become archived (and potentially new, empty journal files get opened as replacements), so the vacuuming operation hits the hardest — because now it can take all the log data written so far into account. 🔥

Added in version 218.

--verify — checks the journal file for internal consistency. and if the file was generated with FSS enabled and the FSS verification key was specified with --verify-key=, then the authenticity of the journal file gets verified too. 🔐

Added in version 189.

--sync — asks the journal daemon to write all the yet-unwritten journal data to the backing file system and synchronize all journals. this call does not return until the synchronization operation is complete, so like, you're gonna wait, bestie. but the payoff: it guarantees that any log messages written before its invocation are safely stored on disk by the time it returns. 💾✨

Added in version 228.

--relinquish-var — asks the journal daemon for the reverse operation to --flush. if requested, the daemon writes further log data to /run/log/journal/ and stops writing to /var/log/journal/. and then a subsequent call to --flush causes the log output to switch back to /var/log/journal/, see above. 🔄

Added in version 243.

--smart-relinquish-var — similar to --relinquish-var, BUT it executes no operation if the root file system and /var/log/journal/ reside on the same mount point. 🧠 this one is used during system shutdown, so that the journal daemon stops writing data to /var/log/journal/ in case that directory is located on a mount point that needs to be unmounted. smart, see, that's the whole point.

Added in version 243.

--flush — asks the journal daemon to flush any log data stored in /run/log/journal/ into /var/log/journal/, if persistent storage is enabled. this call does not return until the operation is complete. 📦➡️📁

note that this call is idempotent: the data is only flushed from /run/log/journal/ into /var/log/journal/ once during system runtime (but see --relinquish-var below), and this command exits cleanly without executing any operation if that already happened. and this command effectively guarantees that all data is flushed to /var/log/journal/ at the time it returns. periodt. 💅

Added in version 217.

--rotate — asks the journal daemon to rotate journal files. this call does not return until the rotation operation is complete. 🔄 journal file rotation has the effect that all currently active journal files are marked as archived and renamed, so that they're never written to in the future, and then new (empty) journal files are created in their place. fresh start, new me energy. ✨

this operation may be combined with --vacuum-size=, --vacuum-time= and --vacuum-file= into a single command, see above. 👆

Added in version 227.

--header — instead of showing journal contents, this shows the internal header information of the journal fields accessed. 🧾

this option is particularly useful when you're trying to identify out-of-order journal entries — which happens for example when the machine gets booted with the wrong system time. 🕰️😭 yes, that's a real thing that happens.

Added in version 187.

--list-catalog [128-bit-ID...] — lists the contents of the message catalog as a table of message IDs, plus their short description strings. 📚

if any *128-bit-ID*s are specified, only those entries are shown.

Added in version 196.

--dump-catalog [128-bit-ID...] — shows the contents of the message catalog, with entries separated by a line consisting of two dashes and the ID (the format is the same as .catalog files). 🗂️

if any *128-bit-ID*s are specified, only those entries are shown.

Added in version 199.

--update-catalog — updates the message catalog index. 🔧 you need to run this each time new catalog files are installed, removed, or updated, so it can rebuild the binary catalog index. it's giving maintenance era.

Added in version 196.

--setup-keys — instead of showing journal contents, this generates a brand new key pair for Forward Secure Sealing (FSS). 🔑✨ it'll generate a sealing key and a verification key.

the sealing key is stored in the journal data directory and shall remain on the host. the verification key should be stored externally. keep them separated bestie, that's the whole vibe. 🫶

refer to the Seal= option in journald.conf(5) for info on Forward Secure Sealing, and for a link to a refereed scholarly paper detailing the cryptographic theory it's based on. yes, an actual paper. we're academic now. 🎓

Added in version 189.

-h, --help — prints a short help text and exits. classic. 👋
--version — prints a short version string and exits. also classic. 🏷️

💫 EXIT STATUS 💫

on success, 0 gets returned. otherwise, a non-zero failure code gets returned. that's it, that's the whole deal. 💖

🌸 ENVIRONMENT 🌸

okay bestie, this is the part where the vibes get environmental 💖 these are all the little variables the shell hands over before anything even starts. Set them, don't set them, whatever — but know what they do, iykyk.

`$SYSTEMD_LOG_LEVEL`

The maximum log level of emitted messages — aka messages with a higher log level (the less important ones, the ones that are literally just noise) get suppressed. It takes a comma-separated list of values. Each value can be either one of (in order of decreasing importance) emerg, alert, crit, err, warning, notice, info, debug, or an integer in the range 0...7. See syslog(3) for more info ✨

Every value may optionally be prefixed with one of console, syslog, kmsg or journal followed by a colon, which sets the maximum log level for that specific log target only (for example, SYSTEMD_LOG_LEVEL=debug,console:info says log at debug level except when logging to the console, which should be at info level). 🎀

no cap: the global maximum log level takes priority over any per-target maximum log levels. periodt.

`$SYSTEMD_LOG_COLOR`

A boolean. If true, messages written to the tty will be colored according to priority. 🌈

This setting is only useful when messages are written directly to the terminal, because journalctl(1) and other tools that display logs will color messages based on the log level on their own. they got it covered 💅

`$SYSTEMD_LOG_TIME`

A boolean. If true, console log messages will be prefixed with a timestamp. ⏰

This setting is only useful when messages are written directly to the terminal or a file, because journalctl(1) and other tools that display logs will attach timestamps based on the entry metadata on their own.

`$SYSTEMD_LOG_LOCATION`

A boolean. If true, messages will be prefixed with a filename and line number in the source code where the message originates. 📍

Note that the log location is often attached as metadata to journal entries anyway. Including it directly in the message text can nevertheless be convenient when debugging programs — lowkey a lifesaver when you're deep in the debugging trenches 😭

`$SYSTEMD_LOG_TID`

A boolean. If true, messages will be prefixed with the current numerical thread ID (TID). 🧵

Note that this information is attached as metadata to journal entries anyway. Including it directly in the message text can nevertheless be convenient when debugging programs.

`$SYSTEMD_LOG_TARGET`

Where the log messages go. Pick one of:

console — log to the attached tty
console-prefixed — log to the attached tty, but with prefixes encoding the log level and "facility", see syslog(3)
kmsg — log to the kernel circular log buffer
journal — log to the journal
journal-or-kmsg — log to the journal if available, and to kmsg otherwise
auto — determine the appropriate log target automatically, the default
null — disable log output

`$SYSTEMD_LOG_RATELIMIT_KMSG`

Whether to ratelimit kmsg or not. Takes a boolean. Defaults to "true". If disabled, systemd will not ratelimit messages written to kmsg. 🚦

`$SYSTEMD_PAGER`, `$PAGER`

Pager to use when --no-pager is not given. $SYSTEMD_PAGER is used if set; otherwise $PAGER is used. If neither $SYSTEMD_PAGER nor $PAGER are set, a set of well-known pager implementations is tried in turn, including less(1) and more(1), until one is found. If no pager implementation is discovered, no pager is invoked. Setting those environment variables to an empty string or the value "cat" is equivalent to passing --no-pager. 🐱

Note: if $SYSTEMD_PAGERSECURE is not set, $SYSTEMD_PAGER and $PAGER can only be used to disable the pager (with "cat" or ""), and are otherwise ignored. yeah. it's like that.

`$SYSTEMD_LESS`

Override the options passed to less (by default "FRSXMK").

Users might want to change two options in particular:

K

This option instructs the pager to exit immediately when Ctrl+C is pressed. To allow less to handle Ctrl+C itself to switch back to the pager command prompt, unset this option.

If the value of $SYSTEMD_LESS does not include "K", and the pager that is invoked is less, Ctrl+C will be ignored by the executable, and needs to be handled by the pager. 🙈

X

This option instructs the pager to not send termcap initialization and deinitialization strings to the terminal. It is set by default to allow command output to remain visible in the terminal even after the pager exits. Nevertheless, this prevents some pager functionality from working, in particular paged output cannot be scrolled with the mouse. 🖱️

Note that setting the regular $LESS environment variable has no effect for less invocations by systemd tools.

See less(1) for more discussion.

`$SYSTEMD_LESSCHARSET`

Override the charset passed to less (by default "utf-8", if the invoking terminal is determined to be UTF-8 compatible). ✨

Note that setting the regular $LESSCHARSET environment variable has no effect for less invocations by systemd tools. yes this is the same trick twice, no I'm not sorry.

`$SYSTEMD_PAGERSECURE`

okay this one is the serious one, bestie, listen up 🫶

Common pager commands like less(1), in addition to "paging" — i.e. scrolling through the output — support opening of or writing to other files and running arbitrary shell commands. When commands are invoked with elevated privileges, for example under sudo(8) or pkexec(1), the pager becomes a security boundary. Care must be taken that only programs with strictly limited functionality are used as pagers, and unintended interactive features like opening or creation of new files or starting of subprocesses are not allowed. "Secure mode" for the pager may be enabled as described below, if the pager supports that (most pagers are not written in a way that takes this into consideration). It is recommended to either explicitly enable "secure mode" or to completely disable the pager using --no-pager or PAGER=cat when allowing untrusted users to execute commands with elevated privileges. 🚨

This option takes a boolean argument. When set to true, the "secure mode" of the pager is enabled. In "secure mode", LESSSECURE=1 will be set when invoking the pager, which instructs the pager to disable commands that open or create new files or start new subprocesses. Currently only less(1) is known to understand this variable and implement "secure mode".

When set to false, no limitation is placed on the pager. Setting SYSTEMD_PAGERSECURE=0 or not removing it from the inherited environment may allow the user to invoke arbitrary commands. 💀

When $SYSTEMD_PAGERSECURE is not set, systemd tools attempt to automatically figure out if "secure mode" should be enabled and whether the pager supports it. "Secure mode" is enabled if the effective UID is not the same as the owner of the login session, see geteuid(2) and sd_pid_get_owner_uid(3), or when running under sudo(8) or similar tools ($SUDO_UID is set [8]). In those cases, SYSTEMD_PAGERSECURE=1 will be set and pagers which are not known to implement "secure mode" will not be used at all. Note that this autodetection only covers the most common mechanisms to elevate privileges and is intended as convenience. It is recommended to explicitly set $SYSTEMD_PAGERSECURE or disable the pager.

Note that if the $SYSTEMD_PAGER or $PAGER variables are to be honoured, other than to disable the pager, $SYSTEMD_PAGERSECURE must be set too. both. it needs both. the way that it needs both 😤

`$SYSTEMD_COLORS`

Takes a boolean argument, or a special value. By default (unset), systemd and related utilities will use colors in their output if possible. If $COLORTERM is set to "truecolor" or "24bit", 24-bit colors will be enabled, 256 colors otherwise, unless $NO_COLOR or $TERM indicates colors are disabled. 🌈

true

Same as unset, except that $NO_COLOR is ignored.

false

The output will be monochrome. sad beige terminal 🥲

`"16"`, `"256"`, `"24bit"`

Always use the base 16 ANSI colors, 256 colors, or 24 bit color, respectively.

`"auto-16"`, `"auto-256"`, `"auto-24bit"`

Use the given quantity of colours, subject to $TERM, and what the console is connected to.

`$SYSTEMD_URLIFY`

The value must be a boolean. Controls whether clickable links should be generated in the output for terminal emulators supporting this. This can be specified to override the decision that systemd makes based on $TERM and other conditions. 🔗

✨ EXAMPLES ✨

real talk, this is the part where it all clicks. no args, no filter, everything comes out:

journalctl

With one match specified, all entries with a field matching the expression are shown:

journalctl _SYSTEMD_UNIT=avahi-daemon.service
journalctl _SYSTEMD_CGROUP=/user.slice/user-42.slice/session-c1.scope

If two different fields are matched, only entries matching both expressions at the same time are shown:

journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097

If two matches refer to the same field, all entries matching either expression are shown:

journalctl _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=dbus.service

If the separator "+" is used, two expressions may be combined in a logical OR. The following will show all messages from the Avahi service process with the PID 28097 plus all messages from the D-Bus service (from any of its processes):

journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097 + _SYSTEMD_UNIT=dbus.service

To show all fields emitted by a unit and about the unit, option -u/--unit= should be used. journalctl -u name expands to a complex filter similar to

_SYSTEMD_UNIT=name.service
  + UNIT=name.service _PID=1
  + OBJECT_SYSTEMD_UNIT=name.service _UID=0
  + COREDUMP_UNIT=name.service _UID=0 MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1

(see systemd.journal-fields(7) for an explanation of those patterns). 🫶

Show all logs generated by the D-Bus executable:

journalctl /usr/bin/dbus-daemon

Show all kernel logs from previous boot:

journalctl -k -b -1

Show a live log display from a system service apache.service:

journalctl -f -u apache

🌈 SEE ALSO 🌈

the whole friend group, go say hi 💖

📎 NOTES 📎

okay bestie, these are the lil footnote-y receipts for everything we referenced up above with those [1], [2] vibes 💖 they're here so you can go read the source material yourself, no cap:

UAPI.2 Discoverable Partitions Specification — the actual spec, go read it: https://uapi-group.org/specifications/specs/discoverable_partitions_specification ✨
RFC 3339 — the date/time format we're all living in, iconic honestly: https://tools.ietf.org/html/rfc3339 🎀
Journal Export Format — where the whole export thing gets defined: https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format 🦋
Journal JSON Format — same page, different anchor, still slaying: https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format 🌸
Server-Sent Events — the MDN explainer, lowkey a great read: https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events 💅
JavaScript Object Notation (JSON) Text Sequences — the RFC for that RS-separated sequence vibe, iykyk: https://tools.ietf.org/html/rfc7464 🔥
Journal Message Catalogs — catalog file lore lives here: https://systemd.io/CATALOG 👑
It is recommended for other tools to set and check $SUDO_UID as appropriate, treating it is a common interface. 🫶

fr fr though, note 8 is the one to remember if you're writing a tool that hangs out with journalctl — $SUDO_UID is the shared handshake, treat it like a common interface and everybody stays friends 💜

and that's a wrap on the whole page, bestie!! 🎉 you made it all the way through, main character energy fr. this was systemd 262.1's take on JOURNALCTL(1) — go forth, read your logs, and may your output never be truncated 🙈💖

📦 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 2026-10-19: a language model's rewrite of the original, under its terms

JOURNALCTL(1)

👑 journalctl — the manual page, but make it slay

✨ NAME ✨

🌸 SYNOPSIS 🌸

💖 DESCRIPTION 💖

🎀 SOURCE OPTIONS 🎀

💖 FILTERING OPTIONS 💖

✨ OUTPUT OPTIONS ✨

📄 PAGER CONTROL OPTIONS 📄

🔐 FORWARD SECURE SEALING (FSS) OPTIONS 🔐

👑 COMMANDS 👑 (the main character section, honestly)

💫 EXIT STATUS 💫

🌸 ENVIRONMENT 🌸

$SYSTEMD_LOG_LEVEL

$SYSTEMD_LOG_COLOR

$SYSTEMD_LOG_TIME

$SYSTEMD_LOG_LOCATION

$SYSTEMD_LOG_TID

$SYSTEMD_LOG_TARGET

$SYSTEMD_LOG_RATELIMIT_KMSG

$SYSTEMD_PAGER, $PAGER

$SYSTEMD_LESS

K

X

$SYSTEMD_LESSCHARSET

$SYSTEMD_PAGERSECURE

$SYSTEMD_COLORS

true

false

"16", "256", "24bit"

"auto-16", "auto-256", "auto-24bit"

$SYSTEMD_URLIFY

✨ EXAMPLES ✨

🌈 SEE ALSO 🌈

📎 NOTES 📎

`$SYSTEMD_LOG_LEVEL`

`$SYSTEMD_LOG_COLOR`

`$SYSTEMD_LOG_TIME`

`$SYSTEMD_LOG_LOCATION`

`$SYSTEMD_LOG_TID`

`$SYSTEMD_LOG_TARGET`

`$SYSTEMD_LOG_RATELIMIT_KMSG`

`$SYSTEMD_PAGER`, `$PAGER`

`$SYSTEMD_LESS`

`$SYSTEMD_LESSCHARSET`

`$SYSTEMD_PAGERSECURE`

`$SYSTEMD_COLORS`

`"16"`, `"256"`, `"24bit"`

`"auto-16"`, `"auto-256"`, `"auto-24bit"`

`$SYSTEMD_URLIFY`