Read the logs with journalctl

journalctl is the command that displays all the journals of your Linux system. When a service crashes or something behaves oddly, these logs hold the answer. This guide teaches you the essential filters to target the useful information quickly.

What you will learn

• Read the system journals with journalctl
• Filter by service with -u
• Follow the logs in real time with -f
• Filter by priority (errors, warnings)
• Search a date range with --since and --until

What journald is

journald is the systemd component that captures and stores all the system logs:

• kernel messages,
• service messages (SSH, Nginx, cron…),
• authentication messages,
• system errors.

All these messages are stored in a binary format. The journalctl command reads and filters them.

This binary storage surprises people who come from the text files of /var/log/, and it has a useful counterpart: journald's logs are structured. Each entry carries its metadata, date, PID, emitting service, priority, which makes filtering exact. A grep on free text cannot tell one service from another; journalctl -u can.

Read the journals

Three ways of reading the journals cover almost every need, and they differ by what they leave out. The first leaves out nothing and is for exploring; the second keeps only the latest entries, when you know the event just happened; the third keeps only the current boot, which removes at once all the history before the last reboot.

All the logs

journalctl

The output is shown in a pager (like less). Use:

• Down arrow / Space to move forward
• q to quit
• /pattern to search for a word

The last lines

This is the form to prefer as soon as you know when the event occurred, because it skips the pager and gives you the prompt back immediately. Pick the number according to the service's verbosity: about twenty lines is enough for a start-up, you need more for a service that writes on every request.

To show only the last 20 entries:

journalctl -n 20

The logs of the current boot

journalctl -b

This shows only the messages since the last boot. To see the previous boot:

journalctl -b -1

This command only works if the journal is kept on disk between two boots. Otherwise, journalctl answers that it has no data for that boot: the Troubleshooting section shows how to make the journal persistent.

Filter by service with -u

This is the filter used most day to day. To see only the logs of one service:

journalctl -u sshd

Output (excerpt)

Apr 06 08:00:01 server sshd[850]: Server listening on 0.0.0.0 port 22.
Apr 06 09:15:23 server sshd[1456]: Accepted publickey for bob from 192.168.1.5
Apr 06 09:15:23 server sshd[1456]: pam_unix(sshd:session): session opened for user bob

The unit name depends on the distribution: the SSH server is called sshd on RHEL, but ssh on Debian and Ubuntu, where the command becomes journalctl -u ssh. When in doubt, systemctl list-units --type=service shows the exact name.

To combine it with the last lines of the current boot:

journalctl -u nginx -b -n 30

This command shows the last 30 Nginx messages since the last boot.

Follow the logs in real time with -f

The equivalent of tail -f for systemd journals:

journalctl -f

To follow a specific service:

journalctl -u nginx -f

The most effective way to use this is to open a second terminal with journalctl -u <service> -f, then start or test the service from the first one. The errors show up as they happen, in order, which reading after the fact never gives you as clearly.

Press Ctrl+C to stop following.

Filter by priority with -p

Each journal message has a priority level. From the most critical to the least important:

Level	Name	Description
0	emerg	System unusable
1	alert	Immediate action required
2	crit	Critical error
3	err	Error
4	warning	Warning
5	notice	Normal but significant event
6	info	Information
7	debug	Debug message

Swipe to see more

To show only errors and worse (levels 0 to 3):

journalctl -p err

For warnings and worse:

journalctl -p warning

Note

-p err shows the err, crit, alert and emerg levels. It is a "this level and above" filter.

Filter by date with --since and --until

This is the filter you use after the fact, when someone reports an incident that happened "around 9 this morning". The 2 options work alone or together: --since sets the start, --until the end. They combine with all the other filters, and journalctl -p err --since "1 hour ago" is probably the most rewarding diagnostic command in this guide.

To search the logs of a precise period:

journalctl --since "2026-04-06 08:00" --until "2026-04-06 12:00"

Accepted formats:

Format	Example
Date and time	"2026-04-06 08:00"
Date only	"2026-04-06" (= midnight)
Relative	"1 hour ago"
Relative	"yesterday", "today"

Swipe to see more

Practical examples:

# Errors over the last hour
journalctl -p err --since "1 hour ago"

# Yesterday's SSH logs
journalctl -u sshd --since yesterday --until today

See the disk space used by the logs

journalctl --disk-usage

Output

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

To free space by deleting old logs:

# Keep only the last 7 days
sudo journalctl --vacuum-time=7d

# Or cap at 500 MB
sudo journalctl --vacuum-size=500M

Command summary

These 10 forms can be combined with each other, and that is what makes the tool powerful: -u designates the service, -b the boot, -p the severity, -n the volume, --since the period. So there are not ten commands to memorise, but five filters to assemble according to the question asked.

Command	Role
journalctl	All the journals
journalctl -n 20	The last 20 lines
journalctl -b	Logs of the current boot
journalctl -u service	Logs of one service
journalctl -f	Live follow
journalctl -u service -f	Live follow of one service
journalctl -p err	Errors and worse
journalctl --since "1 hour ago"	Logs of the last hour
journalctl --disk-usage	Disk space used
sudo journalctl --vacuum-time=7d	Delete logs older than 7 days

Swipe to see more

Troubleshooting

The difficulties met with journalctl rarely come from the command itself: they come from the journald configuration, in particular the persistence of the journals between two boots and the size they are allowed to take. Both are set in /etc/systemd/journald.conf.

Symptom	Likely cause	Solution
No journal files were found	Journald is not running or permissions are insufficient	Run sudo journalctl, or add the user to the systemd-journal group (or adm); check that systemd-journald is running
The logs disappear after a reboot	Non-persistent storage (the default on some distributions)	Create the directory: sudo mkdir -p /var/log/journal then sudo systemctl restart systemd-journald
journalctl shows thousands of lines	No filter applied	Use -u, -b, -p or -n to narrow it down
No logs for a service	The service does not write to the journal	Check that the service uses stdout/stderr (or syslog)
The disk is full of logs	Default cap too wide for this disk: up to 10% of the file system, within a 4 GB limit	Set SystemMaxUse=500M in /etc/systemd/journald.conf

Swipe to see more

Key points

• journalctl is the single entry point to read all the system journals.
• -u service filters by service: it is the most useful filter day to day.
• -f follows the logs in real time, ideal for live troubleshooting.
• -p err shows only errors and critical messages.
• --since and --until limit the search to a time range.

Knowledge check

Check that the essentials of this guide stuck. The questions cover only what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →