journalctl Command in Linux With Examples

Service failures are easier to diagnose when you can query the systemd journal by boot, unit, priority, time window, and message text instead of opening several log files by hand. The journalctl command in Linux reads that journal directly, which makes it the normal first stop on systemd-based distributions such as Ubuntu, Fedora, Debian, Arch, and RHEL-family systems.

journalctl is not a generic log viewer for every Linux init system. It queries systemd journal files, so non-systemd installations may use traditional syslog files, OpenRC service logs, or another logging stack. The examples here focus on common systemd hosts and use portable targets such as systemd-logind.service, SSH unit-name checks, and a tagged logger message you can safely reproduce.

Understand the journalctl Command in Linux

journalctl reads entries stored by systemd-journald. A journal entry can include the visible message plus metadata such as boot ID, systemd unit, process ID, executable name, priority, hostname, and syslog identifier. That metadata is what makes journalctl more precise than scrolling through plain text logs.

The basic syntax is:

journalctl [OPTIONS] [MATCHES]

OPTIONS change the time range, boot, unit, priority, output format, pager behavior, or follow mode.
MATCHES filter journal fields, such as _COMM=logger, SYSLOG_IDENTIFIER=app, or _SYSTEMD_UNIT=ssh.service.

The upstream systemd journalctl manual is the reference for the full option set. The systemd journal fields documentation explains the metadata fields used in advanced filters.

journalctl Quick Reference

These command patterns cover the most common journal tasks:

Task	Command Pattern	What It Does
Show recent entries	`journalctl -n 50 --no-pager`	Prints the newest 50 entries without opening a pager.
Read the current boot	`journalctl -b`	Limits output to the current boot.
List stored boots	`journalctl --list-boots`	Shows boot offsets, boot IDs, and recorded time ranges.
Read a service unit	`journalctl -u systemd-logind.service`	Filters entries for one systemd unit.
Show errors and worse	`journalctl -b -p err`	Shows current-boot entries at error priority or higher severity.
Use a time window	`journalctl --since "1 hour ago" --until "now"`	Limits output to a human-readable time range.
Follow live output	`journalctl -f`	Prints new entries as they arrive until you press `Ctrl+C`.
Search messages	`journalctl --grep "timeout\|failed"`	Filters entries whose `MESSAGE` field matches a regular expression.
Read kernel messages	`journalctl -k`	Shows the current boot’s kernel message log.
Check journal size	`journalctl --disk-usage`	Reports how much storage archived and active journals use.

Verify journalctl Availability

On systemd-based systems, journalctl normally comes from the systemd package rather than a separate package named journalctl. Confirm the command path first:

command -v journalctl

Typical output is:

/usr/bin/journalctl

Check the installed systemd version when option behavior matters:

journalctl --version | head -n 1

The first line starts with the systemd version. The exact build depends on your distribution and release, so check the installed help output before relying on newer options on older long-term or enterprise systems.

View Journal Entries with journalctl

Show Recent Journal Entries

A plain journalctl command can open a long journal in a pager. For incident triage, start with a bounded entry count and disable the pager so the output returns directly to the terminal:

journalctl -n 50 --no-pager

-n 50 selects the newest 50 entries. Without -r, those selected entries still print in chronological order, so the newest selected line appears at the bottom.

Use reverse order when the newest line should appear first:

journalctl -r -n 20 --no-pager

The -r option is useful for quick scanning, but chronological order is usually better when you need to understand what happened before and after an event.

Read Logs from the Current Boot

Limit output to the current boot when old entries would only add noise:

journalctl -b -n 100 --no-pager

Use stored boot offsets to inspect previous boots. First list the boots the journal still has:

journalctl --list-boots

The current boot is offset 0, the previous boot is -1, and older stored boots continue as -2, -3, and so on. Read the previous boot with:

journalctl -b -1 --no-pager

If the machine rebooted after a crash, -b -1 often gives you the last useful messages before the restart. It cannot recover older boots that were never stored or have already been vacuumed.

Use Time Windows with Since and Until

Time filters keep journal output focused on the period when a problem happened. Relative times are convenient for recent checks:

journalctl --since "1 hour ago" --until "now" --no-pager

Use exact timestamps when you are comparing events against monitoring alerts, package transactions, or a reported user incident:

journalctl --since "2026-05-27 09:00:00" --until "2026-05-27 10:00:00" --no-pager

Combine time filters with -b, -u, -p, or --grep when the time window still contains too much data.

Filter journalctl Output by Unit, Priority, and Message

Filter Logs by systemd Unit

The -u option filters entries by systemd unit. systemd-logind.service is a useful portable example because it exists on normal systemd hosts:

journalctl -u systemd-logind.service -n 20 --no-pager

For SSH logs, unit names differ by distribution. Ubuntu and Debian commonly expose ssh.service, while Fedora, Arch, Rocky Linux, AlmaLinux, and many RHEL-family systems use sshd.service. Query both names when writing a portable one-off check:

journalctl -u ssh.service -u sshd.service -n 50 --no-pager

If you are unsure which unit exists, ask systemd for matching unit files before reading logs:

systemctl list-unit-files "ssh*.service" --no-pager

Use the exact unit name that owns the service state. Carry that same name through systemctl status, journalctl -u, restarts, and troubleshooting so you do not mix logs from the wrong service.

Filter Logs by Priority

Journal priorities follow the syslog severity scale. Lower numbers are more severe: emerg, alert, crit, err, warning, notice, info, and debug.

Show errors and higher-severity entries from the current boot:

journalctl -b -p err --no-pager

Use a range when you want to include warnings but exclude routine informational messages:

journalctl -b -p warning..alert --no-pager

Priority filters are strongest when paired with a unit or time window. For example, read recent SSH errors from either common SSH unit name:

journalctl -u ssh.service -u sshd.service -p err -n 20 --no-pager

Search Journal Messages with grep Matching

--grep searches the MESSAGE field inside journal entries. Create a small tagged entry with logger when you want to confirm identifier and message filters on a system you control:

logger -t lc-journalctl-demo "journalctl filter example"

Read the newest matching tagged entry and print only the message text:

journalctl -t lc-journalctl-demo --grep "filter example" -n 1 --no-pager -o cat

Expected output:

journalctl filter example

The -t option matches SYSLOG_IDENTIFIER, while --grep matches the message text. Use grep command examples for plain text files and pipelines; prefer journalctl --grep when the source is already the systemd journal.

Force case-insensitive message matching when capitalization varies:

journalctl --grep "timeout" --case-sensitive=false --no-pager

Match Journal Metadata Fields Directly

Field matches let you query journal metadata without piping through another tool. For example, find the newest entry created by the logger command:

journalctl _COMM=logger -n 1 --no-pager -o cat

You can also match the syslog identifier directly:

journalctl SYSLOG_IDENTIFIER=lc-journalctl-demo -n 5 --no-pager

Field names are case-sensitive. Combine different fields to narrow the result, and use repeated matches of the same field when you need alternatives.

Read Kernel and User Journals

Kernel messages often explain driver, storage, CPU, and hardware-related events. Read the current boot’s kernel journal with:

journalctl -k -n 50 --no-pager

User services use a separate journal view. Check recent entries from your user journal with:

journalctl --user -n 50 --no-pager

For a specific user service, use --user-unit instead of the system-level -u filter:

journalctl --user-unit pipewire.service -n 50 --no-pager

Do not mix system units and user units in the same troubleshooting path. A system service belongs to journalctl -u; a user service belongs to journalctl --user-unit.

Follow Logs and Change journalctl Output

Follow Live Journal Entries

Use follow mode while restarting a service or reproducing an error. Press Ctrl+C to stop:

journalctl -f

Follow one service when the full system journal is too noisy:

journalctl -u systemd-logind.service -f

For traditional text log files, the tail command examples cover tail -f and rotation-safe tail -F. Use journalctl -f when the service writes to the journal instead of a normal file under /var/log.

Choose Output Formats

Output modes change how much structure journalctl prints. ISO-style timestamps are useful in incident notes:

journalctl -n 20 --no-pager -o short-iso

Print only message text when a surrounding filter already explains the source:

journalctl -t lc-journalctl-demo -n 5 --no-pager -o cat

Use JSON when another program needs structured fields:

journalctl -u systemd-logind.service -n 5 --no-pager -o json-pretty

Restrict fields in JSON-style output when you only need a few values:

journalctl -t lc-journalctl-demo -n 1 --no-pager -o json-pretty --output-fields=MESSAGE,SYSLOG_IDENTIFIER,_COMM

JSON output can still include cursor and timestamp fields that identify the entry. Treat journal exports as operational data and avoid pasting private hostnames, tokens, account names, or one-time URLs into public tickets.

Use Pager Controls for Long Output

journalctl may open a pager for long output. Use --no-pager for scripts, automation, and copyable snippets:

journalctl -b -n 100 --no-pager

When you do want the pager, -e jumps to the end immediately and -x adds catalog explanations where systemd has one:

sudo journalctl -xeu systemd-logind.service

Use -l when long lines are truncated in the pager or terminal:

journalctl -u systemd-logind.service -n 20 -l --no-pager

Inspect Journal Size and Integrity

Check Journal Disk Usage

Check journal storage before pruning logs or blaming another directory for disk pressure:

journalctl --disk-usage

Example output looks like:

Archived and active journals take up 40M in the file system.

For broader disk triage, use du disk usage analysis to compare journal storage with caches, application data, and other large directories.

Vacuum Old Journal Files

Vacuum commands delete archived journal files. They are useful only after you decide how much history the host should keep. They do not recover disk space from unrelated logs, and they cannot shrink below what active journal files still require.

Vacuuming removes journal history. Keep enough logs for incident response, compliance, or rollback analysis before reducing journal retention.

Keep only archived journal files newer than 14 days:

sudo journalctl --vacuum-time=14d

Limit archived journal storage to about 1 GiB:

sudo journalctl --vacuum-size=1G

Limit the number of archived journal files:

sudo journalctl --vacuum-files=10

Set long-term retention with journald.conf rather than relying on manual vacuum commands. Manual vacuuming is a one-time cleanup; journald configuration controls future retention policy.

Verify Journal File Consistency

Run the consistency verifier when journal files appear corrupt, queries fail unexpectedly, or storage problems affected the host:

journalctl --verify --no-pager

Healthy files print PASS lines and return a zero exit status. If verification fails, preserve the failing output before vacuuming or deleting anything so you do not erase the evidence needed for root-cause analysis.

Troubleshoot Common journalctl Problems

Limited Logs or Permission Problems

A regular user may see only user-owned entries, depending on distro policy and group membership. Use sudo for one-off system troubleshooting:

sudo journalctl -b -n 100 --no-pager

For repeated read access, check the journal-related groups before adding anyone:

getent group systemd-journal adm

Many systemd distributions use systemd-journal for journal reads. Debian and Ubuntu systems may also grant broad log access through adm. If your policy allows it, add the account to the narrowest appropriate group and start a fresh login session:

sudo usermod -aG systemd-journal "$USER"

Verify the new session sees the group before retrying without sudo:

groups

Do not add broad log access to shared or low-trust accounts. System journals can contain command arguments, paths, account names, service errors, and other operational details.

No Entries for a Service Unit

A missing or wrong unit name usually returns a quiet result instead of a hard error:

-- No entries --

Check whether the unit name exists, then retry with the exact name:

systemctl list-unit-files "ssh*.service" --no-pager
journalctl -u ssh.service -u sshd.service -n 50 --no-pager

If the unit exists but still shows no entries, widen the query in steps: remove the priority filter, remove the time window, then check the current boot with journalctl -b -u unit-name.service.

No Previous Boot Logs

If you ask for a boot offset the journal does not have, journalctl exits with an error like:

No journal boot entry found for the specified boot (-999).

Check the stored boot list:

journalctl --list-boots

If only the current boot appears, the host may be using volatile journal storage, old files may have been vacuumed, or the system may not have rebooted since persistent storage was enabled. Persistent journaling changes future retention; it cannot recreate logs that were never saved.

Pager Output or Truncated Lines Get in the Way

Pager behavior is useful interactively but awkward in scripts and copied diagnostics. Add --no-pager when output should return directly:

journalctl -u systemd-logind.service -n 50 --no-pager

If messages are shortened, add -l for full lines:

journalctl -u systemd-logind.service -n 50 -l --no-pager

When a command still produces too much output, narrow it with -b, -u, --since, --until, -p, or --grep instead of copying a huge log dump.

Conclusion

journalctl is ready for systemd log triage once you can limit by boot, time, unit, priority, identifier, and output format. Start with bounded current-boot queries, add service or priority filters when the journal is noisy, and use disk-usage or verification checks only when the journal storage itself becomes part of the problem.