How to Check System Logs with `journalctl` on Arch Linux

Monitoring and analyzing system logs is a vital part of maintaining a healthy and secure Arch Linux system. Whether you’re debugging a failed service, tracking system errors, or just curious about what’s going on under the hood, journalctl—the tool provided by systemd—offers a powerful and unified way to interact with system logs.

Unlike traditional logging mechanisms which store logs in plain text files (like /var/log/syslog or /var/log/messages), systemd uses a binary log format that provides richer metadata and faster access. In Arch Linux, which uses systemd by default, journalctl is the go-to utility for accessing these logs.

This guide will walk you through the most common and advanced uses of journalctl, making it easier to understand your system’s behavior and diagnose problems efficiently.

What is journalctl?

journalctl is the primary command-line tool used to query and view the logs collected by the systemd-journald service. These logs cover:

• Kernel messages
• Boot logs
• Application errors
• Systemd service outputs
• User-generated messages via logger

Since Arch Linux is a rolling-release distribution that emphasizes simplicity and transparency, learning journalctl is an essential skill for every Arch user.

Basic Usage

To get started, simply run:

journalctl

This command displays all logs collected by the journal, starting from the oldest. By default, the output is paged using less, so you can scroll through using arrow keys or Page Up/Page Down. You can quit with q.

To view logs in real-time, use:

journalctl -f

This is similar to tail -f /var/log/messages, allowing you to watch logs as they come in—ideal for real-time monitoring of a service.

Filtering by Time

You can specify a time range using --since and --until:

journalctl --since "2025-04-01 12:00:00" --until "2025-04-01 14:00:00"

Or use natural language for relative times:

journalctl --since "1 hour ago"
journalctl --since "yesterday"

These options are extremely useful when you know approximately when a problem occurred and want to narrow down the log output.

Viewing Logs by Boot

Each time the system boots, systemd creates a separate boot entry. You can list all boot sessions with:

journalctl --list-boots

Example output:

-3 9e6b4ab9b82c4d5c8b... 2025-04-10 12:34:56
-2 51c1a2ff6fdb4cbaaa... 2025-04-11 08:12:33
-1 fdb42f9e2c214e3f9a... 2025-04-12 09:55:21
 0 0cfd9e1b67854df0ab... 2025-04-13 10:02:47

To view logs from a specific boot:

journalctl -b -1

This shows logs from the previous boot (-b = current boot, -1 = one before that).

You can also combine it with time filters:

journalctl -b -1 --since "10 minutes ago"

Filtering by Unit (Service)

To isolate logs from a specific service, use the -u flag:

journalctl -u nginx.service

You can view the logs for the current boot or include logs from previous boots with --no-pager and --since:

journalctl -u nginx.service --since "yesterday"

Real-time monitoring for a service:

journalctl -u nginx.service -f

Filtering by Priority (Log Level)

Log messages are categorized by priority levels:

You can filter logs by priority:

journalctl -p err

Or for messages up to a certain priority:

journalctl -p warning

To view only critical system alerts:

journalctl -p crit -b

Viewing Kernel Logs

To isolate kernel messages:

journalctl -k

Or only those generated during this boot:

journalctl -k -b

You can also filter by priority:

journalctl -k -p err

This is handy for identifying hardware issues, kernel panics, or driver problems.

Viewing Logs by User or PID

You can search logs from a specific user:

journalctl _UID=1000

Or a particular process:

journalctl _PID=1234

You can find the PID using ps aux | grep process-name.

This level of filtering is useful for tracking the behavior of background services or user applications.

Combining Filters

journalctl supports combining multiple filters for fine-grained control:

journalctl -u sshd.service -p err --since "1 hour ago"

This command shows only error-level logs from the SSH daemon in the past hour.

Output Formatting Options

By default, journalctl uses a human-readable format. But for scripting or analysis, you can change the format:

journalctl -o json
journalctl -o json-pretty
journalctl -o short
journalctl -o verbose

The json and json-pretty outputs are useful for piping logs into other tools like jq.

Saving Logs to a File

To export logs to a file:

journalctl > full_logs.txt

Or, for a filtered subset:

journalctl -u sshd.service --since yesterday > ssh_logs.txt

This is ideal when you need to share logs with support teams or for offline inspection.

Managing the Journal Size

By default, logs are stored in /var/log/journal/ in binary format. This directory can grow over time. To check its current size:

journalctl --disk-usage

To limit the size of journal logs, edit or create the following config:

/etc/systemd/journald.conf

Set values such as:

SystemMaxUse=500M
SystemKeepFree=100M
SystemMaxFileSize=50M
SystemMaxFiles=10

Then restart the journal daemon:

sudo systemctl restart systemd-journald

You can also clear old logs manually:

sudo journalctl --vacuum-size=200M
sudo journalctl --vacuum-time=7d

Enabling Persistent Logging (if not already)

Arch Linux may default to storing logs in volatile memory (/run/log/journal). To make logs persist across reboots:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-jjournald

Verify with:

ls /var/log/journal

If the directory exists and fills up over time, you now have persistent logging enabled.

Troubleshooting Tips

• No logs found?
  Use sudo when running journalctl. Logs from system services are typically restricted.

• Corrupted journal?
  You may need to delete corrupted logs:

  sudo journalctl --verify
  sudo rm /var/log/journal/*/corrupted-file
  

• Want a GUI?
  Try gnome-logs or KSystemLog if you prefer a graphical interface.

Conclusion

The journalctl tool is an incredibly versatile and essential utility for system administrators, developers, and power users on Arch Linux. It unifies all system messages into a single, searchable, filterable log that you can tailor to your specific needs.

From simple real-time monitoring to deep-dive debugging of failed services, journalctl gives you unmatched visibility into your system. While its syntax might seem complex at first, mastering its capabilities will make you far more effective at managing and troubleshooting your Arch Linux environment.

Whether you’re tracking down that elusive crash, analyzing boot logs, or just getting a feel for how your system runs, journalctl is a tool worth knowing inside and out.