Reading Logs With journalctl in Linux: A Practical Guide

2 Aug 2026

Linux logs are often the first place to look when a service fails, a server behaves unexpectedly, or a system takes too long to boot.

On modern Linux distributions that use systemd, many of those logs are stored in the systemd journal and viewed with the journalctl command. Instead of searching through several text files manually, journalctl lets you filter logs by service, time, boot session, priority, process and other useful fields.

This guide explains how to read logs with journalctl in Linux, including the commands worth learning first, practical troubleshooting examples and common mistakes to avoid.

What Is

journalctl

journalctl is the command-line tool used to read entries stored by systemd-journald.

The journal may include messages from:

The Linux kernel
System services
Background daemons
User services
Applications
Boot processes
Authentication components
Hardware and drivers
Scheduled jobs

On many distributions, it provides a central place to investigate system activity.

A basic command is:

journalctl

This displays journal entries in chronological order, usually starting with the oldest available entry.

On a busy system, that can produce a great deal of output, so filtering is usually more useful.

Why

journalctl

Is Useful

Traditional Linux logging often involves files such as:

/var/log/syslog

/var/log/messages

/var/log/auth.log

/var/log/kern.log

These files may still exist, depending on the distribution and configuration.

The systemd journal adds structured metadata to each message, including:

Timestamp
Service name
Process ID
User ID
Boot ID
Priority
Executable path
Hostname
Unit name

That structure makes precise filtering possible.

For example, instead of searching an entire log file for SSH messages, you can request only the logs for the SSH service.

Check Whether Your System Uses

systemd

Run:

ps -p 1 -o comm=

On a system using systemd, the output should be:

systemd

You can also run:

systemctl --version

If systemctl is available and working, journalctl is usually available too.

Reading the Journal

The simplest command is:

journalctl

The output normally opens in a pager such as less.

Useful pager controls include:

Space Next page

b Previous page

g Beginning

G End

/word Search forward

n Next search match

q Quit

To avoid the pager and print directly to the terminal:

journalctl --no-pager

This is useful in scripts or when piping the output into another command.

Show the Newest Entries First

By default, journalctl shows the oldest entries first.

To reverse the order:

journalctl -r

This places the newest messages at the top.

It is useful when you want to inspect a recent failure quickly without scrolling to the bottom.

Follow Logs in Real Time

To watch new journal entries as they arrive:

journalctl -f

This works similarly to:

tail -f

You can combine it with other filters.

For example, to follow the SSH service:

journalctl -u ssh -f

Or on distributions where the service is named sshd:

journalctl -u sshd -f

Press Ctrl+C to stop following the log.

Show Logs for a Specific Service

Use -u followed by the systemd unit name:

journalctl -u nginx

Examples:

journalctl -u apache2

journalctl -u docker

journalctl -u NetworkManager

journalctl -u ssh

If you are unsure of the exact service name, use:

systemctl list-units --type=service

Or search for a likely name:

systemctl list-units --type=service | grep -i nginx

You can also use the full unit name:

journalctl -u nginx.service

Show Only the Latest Lines

To show the most recent entries:

journalctl -n

By default, this displays a limited number of recent lines.

To specify a number:

journalctl -n 50

For the latest 100 messages from Nginx:

journalctl -u nginx -n 100

This is one of the fastest commands for checking what happened immediately before a service failed.

Show Logs From the Current Boot

Use:

journalctl -b

This filters the journal to the current boot session.

It is useful when the system has been rebooted and you want to ignore older messages.

For a service during the current boot:

journalctl -u docker -b

List Available Boot Sessions

Run:

journalctl --list-boots

Example output may look like:

-2 9c51... Sat 2026-08-01 08:22:14 BST—Sat 2026-08-01 17:40:02 BST

-1 7af4... Sat 2026-08-01 17:42:10 BST—Sun 2026-08-02 09:05:33 BST

0 3b9e... Sun 2026-08-02 09:06:02 BST—Sun 2026-08-02 18:02:00 BST

Here:

0 is the current boot
-1 is the previous boot
-2 is two boots ago

To inspect the previous boot:

journalctl -b -1

This is especially useful after an unexpected restart or crash.

Show Kernel Messages

Use:

journalctl -k

This displays kernel messages for the current boot.

It is similar in purpose to dmesg, but integrates with the journal.

Common uses include investigating:

Driver failures
Disk errors
USB problems
Network interface issues
Filesystem warnings
Memory errors
Hardware detection
Kernel panics

To show kernel messages from the previous boot:

journalctl -k -b -1

Filter Logs by Time

Time filtering is one of the most useful journalctl features.

Since a Specific Time

journalctl --since "2026-08-02 14:00:00"

Until a Specific Time

journalctl --until "2026-08-02 16:00:00"

Between Two Times

journalctl --since "2026-08-02 14:00:00" --until "2026-08-02 16:00:00"

Since Today

journalctl --since today

Since Yesterday

journalctl --since yesterday

Last Hour

journalctl --since "1 hour ago"

Last 15 Minutes

journalctl --since "15 minutes ago"

From Yesterday Until Today

journalctl --since yesterday --until today

You can combine time filters with service filters:

journalctl -u nginx --since "30 minutes ago"

Filter by Priority

Journal messages use syslog priority levels.

Common priorities are:

Priority	Name	Meaning
0	emerg	System is unusable
1	alert	Immediate action required
2	crit	Critical condition
3	err	Error
4	warning	Warning
5	notice	Significant but normal
6	info	Informational
7	debug	Debug information

To show errors and more severe messages:

journalctl -p err

To show warnings and more severe messages:

journalctl -p warning

For the current boot:

journalctl -p err -b

For a specific service:

journalctl -u nginx -p warning

To specify a range:

journalctl -p warning..emerg

This includes warning, error, critical, alert and emergency entries.

Show Only Messages From One Executable

You can filter using the executable path.

Example:

journalctl /usr/sbin/sshd

This can be useful when a program generates messages outside a normal service unit.

To find an executable path:

which sshd

Or:

command -v sshd

Filter by Process ID

To view logs for a specific process ID:

journalctl _PID=1234

This is useful when you know which process produced the issue.

However, process IDs are reused, so combine the filter with a time range when necessary.

Example:

journalctl _PID=1234 --since "10 minutes ago"

Filter by User ID

To view messages associated with a specific user ID:

journalctl _UID=1000

To find a user’s ID:

id -u username

For your current user:

journalctl _UID=$(id -u)

This can help investigate user-session services and applications.

Read User Service Logs

Systemd can run services for individual users.

To view logs from your user session:

journalctl --user

For a specific user service:

journalctl --user -u my-service

To follow it:

journalctl --user -u my-service -f

The user service must normally be part of your current session or accessible to your account.

Show Logs for a Specific Systemd Unit Type

Most examples use services, but systemd also manages:

Timers
Sockets
Mounts
Targets
Paths
Devices

Examples:

journalctl -u backup.timer

journalctl -u docker.socket

journalctl -u mnt-data.mount

This is helpful when a timer does not run or a mount unit fails.

View Logs for Several Units

You can provide -u more than once:

journalctl -u nginx -u php8.3-fpm

This is useful when troubleshooting connected services.

For example, a website problem might involve:

Nginx
PHP-FPM
A database service
A reverse proxy

You could run:

journalctl -u nginx -u php8.3-fpm -u mariadb --since "20 minutes ago"

Search Journal Output

You can pipe output to grep:

journalctl -u nginx | grep -i error

For recent entries:

journalctl -u nginx --since today | grep -i timeout

However, structured filters are usually preferable where available because they are more precise.

To search interactively inside the pager:

Run journalctl.
Press /.
Type the search term.
Press Enter.
Press n for the next result.

Use Case-Insensitive Matching With

grep

For example:

journalctl -u docker --since "1 hour ago" | grep -i fail

The -i option makes the search case-insensitive.

To search for several terms:

journalctl -u nginx | grep -Ei "error|fail|timeout"

Show a Specific Message Field

The journal stores structured fields.

To inspect all fields for matching entries, use verbose output:

journalctl -u ssh -o verbose

You may see fields such as:

_SYSTEMD_UNIT=ssh.service

_PID=812

_UID=0

_COMM=sshd

_EXE=/usr/sbin/sshd

_HOSTNAME=server01

MESSAGE=Accepted publickey for admin

This output is useful when building more advanced filters.

Useful Output Formats

Use -o to choose an output format.

Short

journalctl -o short

Short ISO Timestamps

journalctl -o short-iso

Precise Timestamps

journalctl -o short-precise

Verbose Metadata

journalctl -o verbose

JSON

journalctl -o json

Pretty JSON

journalctl -o json-pretty

Message Only

journalctl -o cat

The cat format is useful when you want only the message text:

journalctl -u nginx -o cat

Export Logs for Analysis

To save logs into a text file:

journalctl -u nginx --since today > nginx-today.log

For errors from the current boot:

journalctl -p err -b > current-boot-errors.log

To append rather than overwrite:

journalctl -u nginx >> nginx-history.log

Be careful when exporting logs because they may contain:

Usernames
IP addresses
File paths
Email addresses
Authentication events
Tokens
Application data

Store exported logs securely.

Check a Failed Service

When a service fails, begin with:

systemctl status service-name

For example:

systemctl status nginx

This shows the current status and a small number of recent log lines.

Then use:

journalctl -u nginx -n 100

Or:

journalctl -u nginx --since "10 minutes ago"

For only errors:

journalctl -u nginx -p err

A practical sequence is:

systemctl status nginx

journalctl -u nginx -n 100 --no-pager

nginx -t

The final command checks the Nginx configuration separately.

Troubleshooting SSH Login Problems

Service names vary.

Try:

journalctl -u ssh

Or:

journalctl -u sshd

To view recent authentication-related messages:

journalctl -u ssh --since "30 minutes ago"

To follow new attempts:

journalctl -u ssh -f

Look for messages involving:

Failed passwords
Invalid users
Public-key failures
Permission problems
Configuration errors
Connection closures
Authentication limits

Be cautious when sharing SSH logs because they may expose usernames and IP addresses.

Troubleshooting a Web Server

For Nginx:

journalctl -u nginx --since "1 hour ago"

For Apache on Debian or Ubuntu:

journalctl -u apache2 --since "1 hour ago"

For Apache on some Red Hat-based systems:

journalctl -u httpd --since "1 hour ago"

Remember that web servers may also write detailed access and error logs to files such as:

/var/log/nginx/access.log

/var/log/nginx/error.log

/var/log/apache2/error.log

journalctl is useful for service startup and system-level failures, while application-specific log files may contain more request detail.

Troubleshooting Docker

View Docker daemon logs:

journalctl -u docker

Recent errors:

journalctl -u docker -p err --since "30 minutes ago"

Follow the daemon in real time:

journalctl -u docker -f

This is different from container logs.

For a specific container, use:

docker logs container-name

Or:

docker logs -f container-name

The journal normally shows the Docker service itself unless the logging configuration sends container output there.

Troubleshooting Network Problems

Depending on the distribution and configuration, useful units include:

journalctl -u NetworkManager

journalctl -u systemd-networkd

journalctl -u networking

For recent kernel network messages:

journalctl -k --since "15 minutes ago"

Look for:

Link up or down events
DHCP failures
DNS errors
Driver problems
Authentication failures
Interface renaming
Routing issues

Troubleshooting DNS

For systems using systemd-resolved:

journalctl -u systemd-resolved