How to Use journalctl in Linux: Essential Commands Explained

Linux servers continuously record information about services, system events, authentication attempts, kernel activity, errors, and background processes.

On modern Linux distributions that use systemd, much of this information is stored in the systemd journal. The primary command used to read and filter these records is journalctl.

Administrators commonly use journalctl to:

• Find why a service failed
• Review errors from a specific time period
• Inspect logs from the current or previous boot
• Follow new log messages in real time
• Check authentication and security events
• Investigate unexpected restarts
• Filter warnings and critical errors

This guide explains the most useful journalctl commands for everyday Linux server administration.

What Is journalctl?

journalctl is the command-line utility used to read logs collected by systemd-journald.

The systemd journal may contain messages from:

• Systemd services
• The Linux kernel
• Application standard output
• Application standard error
• Authentication services
• Boot processes
• Scheduled tasks
• Traditional syslog interfaces

Unlike ordinary text logs, journal entries contain structured information such as:

• Timestamp
• Hostname
• Service name
• Process ID
• User ID
• Boot ID
• Message priority
• Executable path

This structured data allows administrators to filter logs more precisely than searching through large text files manually.

The basic command is:

journalctl

On most production servers, use sudo to access complete system logs:

sudo journalctl

Running this command without filters may display a very large amount of information. In practice, administrators usually combine journalctl with options that narrow the output.

How to View Linux System Logs

To display the available system journal, run:

sudo journalctl

The output normally opens inside a pager similar to less.

Useful navigation controls include:

Up/Down arrows    Move one line
Page Up/Page Down Move one page
G                 Jump to the end
g                 Jump to the beginning
/search-term      Search forward
n                 Find the next match
q                 Quit

Displaying the complete journal is useful when exploring a small server, but it is inefficient on systems that generate thousands of entries every hour.

A better approach is to filter by service, time, boot, or severity.

How to View Recent Log Entries

To jump directly to the newest journal entries, use:

sudo journalctl -e

The -e option moves to the end of the journal.

To display the most recent 50 entries:

sudo journalctl -n 50

To display the most recent 200 entries:

sudo journalctl -n 200

This is useful immediately after:

• A service failure
• A configuration change
• A package installation
• A server restart
• A networking problem
• An authentication attempt

For example, after restarting Nginx, you could inspect the latest messages with:

sudo journalctl -n 100

However, filtering by the Nginx service itself is usually more precise.

How to Filter Logs by Service

The -u option filters journal entries by systemd unit.

To view Nginx logs:

sudo journalctl -u nginx

To view Apache logs on Ubuntu or Debian:

sudo journalctl -u apache2

To view Apache logs on AlmaLinux, Rocky Linux, or CentOS:

sudo journalctl -u httpd

To view MySQL logs:

sudo journalctl -u mysql

To view MariaDB logs:

sudo journalctl -u mariadb

To view SSH logs:

sudo journalctl -u ssh

Some distributions use:

sudo journalctl -u sshd

To find the correct service name:

systemctl list-units --type=service --all | grep -i ssh

You can also filter more than one service:

sudo journalctl -u nginx -u php8.3-fpm

This is useful when troubleshooting a web application because Nginx may report an upstream error while PHP-FPM records the underlying problem.

For recent service logs, combine the unit filter with -e:

sudo journalctl -u nginx -e

Or request a fixed number of entries:

sudo journalctl -u nginx -n 100

How to Filter Logs by Time

Time filtering prevents older and unrelated events from cluttering the investigation.

To show logs from the last hour:

sudo journalctl --since "1 hour ago"

To show logs from the last 30 minutes:

sudo journalctl --since "30 minutes ago"

To show logs recorded today:

sudo journalctl --since today

To show logs recorded since yesterday:

sudo journalctl --since yesterday

You can also use exact timestamps:

sudo journalctl --since "2026-06-25 14:00:00"

To define both the start and end of an incident:

sudo journalctl \
  --since "2026-06-25 14:00:00" \
  --until "2026-06-25 14:30:00"

Combine time and service filters:

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

For MySQL events during a specific incident:

sudo journalctl -u mysql \
  --since "2026-06-25 14:00:00" \
  --until "2026-06-25 14:30:00"

When investigating an outage, begin the search several minutes before users noticed the problem.

The first visible error may be the final result of an earlier failure.

For example:

14:03  Database queries begin slowing
14:06  PHP workers become occupied
14:09  Nginx reports upstream timeouts
14:10  Website becomes unavailable

Searching only from 14:10 may hide the original cause.

How to View Logs from the Current or Previous Boot

To display journal entries from the current boot:

sudo journalctl -b

To display entries from the previous boot:

sudo journalctl -b -1

To display entries from two boots ago:

sudo journalctl -b -2

List all boots currently stored in the journal:

sudo journalctl --list-boots

Example output may resemble:

-2  9c26f9...  Mon 2026-06-22 09:12:18 UTC—Mon 2026-06-22 18:41:07 UTC
-1  7e891a...  Tue 2026-06-23 08:05:44 UTC—Wed 2026-06-24 02:16:11 UTC
 0  4a5d93...  Wed 2026-06-24 02:17:02 UTC—Wed 2026-06-24 16:50:26 UTC

Here:

• 0 represents the current boot
• -1 represents the previous boot
• -2 represents two boots ago

Previous-boot logs are especially valuable when investigating:

• Unexpected reboots
• Kernel crashes
• OOM events
• Filesystem failures
• Service failures during startup
• Shutdown problems

To inspect the final messages from the previous boot:

sudo journalctl -b -1 -e

Previous-boot logs are available only when journal retention preserved them.

How to Filter Logs by Priority

Journal messages may use standard severity levels:

emerg
alert
crit
err
warning
notice
info
debug

To show errors and more severe messages:

sudo journalctl -p err

To show warnings and more severe messages:

sudo journalctl -p warning

To show errors from the current boot:

sudo journalctl -b -p err

To show service-specific errors:

sudo journalctl -u nginx -p err

To show warnings from the last hour:

sudo journalctl -p warning --since "1 hour ago"

Priority filtering is useful, but it should not be treated as a complete server-health test.

Some applications record important details as informational messages, while others classify routine events as warnings.

Always inspect the surrounding messages and the affected service’s own application log.

How to Follow Logs in Real Time

To watch new journal entries as they are created:

sudo journalctl -f

This works similarly to:

tail -f

To follow one service:

sudo journalctl -u nginx -f

To follow PHP-FPM:

sudo journalctl -u php8.3-fpm -f

A practical workflow is:

1. Open one terminal and follow the service journal.
2. Reproduce the problem in another terminal or browser.
3. Observe the messages generated at the exact failure time.

For example:

sudo journalctl -u nginx -f

Then, in another terminal:

sudo nginx -t
sudo systemctl reload nginx

Press Ctrl+C to stop following the log.

How to Search journalctl Output

Many versions of journalctl support message searching with -g.

For example:

sudo journalctl -g "connection refused"

Search for out-of-memory messages:

sudo journalctl -g "Out of memory"

A portable alternative is to pipe the output into grep:

sudo journalctl --no-pager | grep -i "connection refused"

Search one service:

sudo journalctl -u nginx --no-pager | grep -i "upstream"

Search a recent time period:

sudo journalctl --since "1 hour ago" --no-pager |
grep -Ei "error|failed|timeout"

Apply journalctl filters before using grep whenever possible.

This is less efficient:

sudo journalctl --no-pager | grep nginx

This is better:

sudo journalctl -u nginx --no-pager

The second command uses structured journal metadata instead of searching every message as ordinary text.

How to Check Failed Services

To list failed systemd units:

systemctl --failed

Example output may show:

UNIT            LOAD   ACTIVE SUB    DESCRIPTION
nginx.service   loaded failed failed A high performance web server

Check the service status:

sudo systemctl status nginx --no-pager -l

Then inspect its journal:

sudo journalctl -u nginx -e

For recent logs:

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

Before restarting a failed service, collect the status and journal output when possible.

Restarting may restore availability, but it may also remove useful evidence about the original failure.

How to Check Journal Disk Usage

To see how much disk space the journal uses:

sudo journalctl --disk-usage

Example:

Archived and active journals take up 1.4G in the file system.

Large journal usage may be caused by:

• Long retention periods
• Debug logging
• Restart loops
• Repeated authentication attempts
• Application errors
• Kernel or driver problems
• Excessively verbose services

To remove archived entries older than 30 days:

sudo journalctl --vacuum-time=30d

To reduce journal usage to approximately 1 GB:

sudo journalctl --vacuum-size=1G

Before deleting logs, identify why they became large.

A rapidly growing journal often indicates an unresolved service problem rather than a simple storage-management issue.

Practical journalctl Troubleshooting Workflow

When a service fails, use this sequence.

1. Check the service state

sudo systemctl status SERVICE_NAME --no-pager -l

2. Review recent service logs

sudo journalctl -u SERVICE_NAME --since "30 minutes ago"

3. Check all failed units

systemctl --failed

4. Inspect current-boot errors

sudo journalctl -b -p err

5. Check kernel messages

sudo journalctl -k --since "30 minutes ago"

6. Check resource conditions

uptime
free -m
df -h
df -i

7. Validate the application configuration

For Nginx:

sudo nginx -t

For Apache:

sudo apachectl configtest

For SSH:

sudo sshd -t

8. Identify related dependencies

For a web application:

sudo systemctl status nginx
sudo systemctl status php8.3-fpm
sudo systemctl status mariadb

9. Apply the fix

Correct the confirmed cause rather than restarting services repeatedly.

10. Verify recovery

sudo systemctl status SERVICE_NAME
sudo journalctl -u SERVICE_NAME --since "5 minutes ago"

Confirm that the service is active and that new errors are no longer appearing.

Common journalctl Mistakes

Running journalctl without filters

The output may contain too much unrelated information. Filter by unit, time, boot, or priority.

Restarting before checking logs

A restart may temporarily hide the original condition. Collect relevant evidence first when possible.

Searching only after the visible outage

Begin several minutes before the reported failure to identify the event that started the chain.

Checking only the application service

Service failures may be caused by kernel OOM events, disk errors, read-only filesystems, or failed dependencies.

Assuming every warning is critical

Interpret messages according to timing, repetition, and operational impact.

Deleting large journals immediately

First identify which service or error is generating the excessive volume.

When Log Problems Require Server Management

Occasional service errors can often be resolved with a configuration correction or controlled restart.

Recurring problems may indicate deeper operational issues, including:

• Repeated service crashes
• Resource exhaustion
• Disk-space failures
• OOM kills
• Failed package upgrades
• Database instability
• Broken dependencies
• Security incidents
• Uncontrolled log growth

OffshoreDedicated.NET provides expert server management for Linux VPS, cloud, and dedicated server environments.

For workloads that repeatedly reach infrastructure limits, consider moving to:

• Offshore VPS servers for isolated virtual resources
• Offshore cloud servers for flexible deployment and scaling
• Offshore dedicated servers for sustained high-resource workloads

The correct solution depends on whether the underlying problem is configuration, application behavior, or insufficient infrastructure.

Frequently Asked Questions

What does journalctl do in Linux?

journalctl reads and filters logs collected by systemd-journald, including service, boot, kernel, authentication, and application events.

How do I see recent Linux errors?

Use:

sudo journalctl -p err --since "1 hour ago"

How do I check logs for one service?

Use:

sudo journalctl -u SERVICE_NAME

For example:

sudo journalctl -u nginx

How do I see logs from the previous boot?

Use:

sudo journalctl -b -1

How do I watch logs live?

Use:

sudo journalctl -f

For one service:

sudo journalctl -u SERVICE_NAME -f

Why does journalctl -b -1 show no logs?

Previous-boot records may not have been stored persistently, or they may have been removed by journal rotation or retention limits.

Can journal logs fill the server disk?

Yes. Check usage with:

sudo journalctl --disk-usage

Investigate excessive log generation before vacuuming old entries.

Recommended Reading:

• How to Investigate a Slow Linux Server (Step-by-Step Debugging Guide)
• How to Diagnose High CPU Usage in Linux (Beyond top)
• How to Diagnose Memory Pressure in Linux (Beyond free -m)
• How to Investigate High Disk I/O in Linux (Deep Dive)
• How to Check Running Processes in Linux (ps, top, kill Explained)

Final Thoughts

journalctl is one of the most important tools for administering modern Linux servers.

The most useful commands are not the ones that display every available message. Effective troubleshooting depends on narrowing the journal by:

• Service
• Time
• Boot
• Priority
• Message content

For most incidents, begin with:

sudo systemctl status SERVICE_NAME
sudo journalctl -u SERVICE_NAME --since "30 minutes ago"
systemctl --failed
sudo journalctl -b -p err

These commands quickly reveal whether a problem involves the service itself, a dependency, the current boot, or a wider system condition.

Mastering journalctl makes it much easier to diagnose service failures before resorting to unnecessary restarts or configuration changes.