How to Use journalctl: The Linux Log Guru’s Cheat Sheet for 2025

Stop Grepping in the Dark. Your Logs Are Structured Now.

If you’re still using tail -f /var/log/syslog and grep for everything, you’re working too hard.

You’re missing the single biggest upgrade to Linux troubleshooting in the last decade: journalctl.

This isn’t just a new command; it’s a whole new philosophy. systemd’s journal collects logs from every service, the kernel, and applications into one centralized, structured database. And journalctl is your key to querying it.

This guide isn’t a theoretical deep dive. It’s the cheat sheet you’ll keep open in a terminal window. Let’s turn you from a log reader into a log guru.

---

First, The Basics: Your New Swiss Army Knife

Start with these. They’ll replace 90% of your old log habits.

1. View ALL Logs (Epoch Style):bashjournalctl
   • This is your starting point. It dumps everything, oldest to newest. Be prepared for a lot of output. (Press q to quit, arrow keys to scroll).
2. Follow Logs in Real-Time (The tail -f Killer):bashjournalctl -f
   • The -f (follow) flag is magic. It shows the last 10 lines and then waits for new messages, printing them as they come in. Your go-to for live debugging.
3. View Logs from the Current Boot:bashjournalctl -b
   • Only care about what’s happened since you last turned on the machine? This is your command. It filters out all historical noise.

---

Level Up: Filtering Like a Pro

This is where journalctl leaves old-school logs in the dust. You don’t just read; you query.

1. Filter by Service/Unit (-u)

This is the #1 most useful filter. Find logs for exactly the service you care about.

bash

journalctl -u nginx.service
journalctl -u ssh.service --since "10 minutes ago"

• Pro Tip: Use -u with -f to tail a specific service: journalctl -fu nginx.service

2. Filter by Time (--since & --until)

Stop scrolling. Tell it the time window you need.

bash

journalctl --since "2024-01-15 14:30:00"
journalctl --since "yesterday" --until "today"
journalctl --since "1 hour ago"

• The time formats are incredibly flexible. Use man journalctl to see all the options.

3. Filter by Priority (-p)

Only show messages of a certain severity level. crucial for finding errors fast.

bash

journalctl -p err -b

• Priority levels: emerg (0), alert (1), crit (2), err (3), warning (4), notice (5), info (6), debug (7).
• journalctl -p err..warning shows errors, crits, alerts, and emergencies.

4. The Kernel Ring Buffer (-k)

Want just kernel messages? Forget dmesg. This is cleaner.

bash

journalctl -k
journalctl -k --since "10 minutes ago"

---

The Power Moves: Correlation & Export

This is what separates the seniors from the juniors.

1. Show Everything Related to a Process ID:bashjournalctl _PID=1234
   • Found a problematic PID in top? Use this to see everything that process has ever logged.
2. Show Everything for a Specific User:bashjournalctl _UID=1000
   • Great for auditing what a specific user account has been doing.
3. Export to JSON for Scripting:bashjournalctl -u nginx -o json journalctl -u nginx -o json-pretty
   • Need to pipe your logs into an external monitoring tool or script? This is how. The -o (output) flag is key.

---

Your New Troubleshooting Workflow

1. Something breaks.
2. You run journalctl -f in a terminal to watch live.
3. You identify the offending service from the live messages.
4. You drill down: journalctl -u <bad-service>.service --since "10 mins ago" -p err
5. You find the exact error message and fix the problem.

This workflow is faster, more precise, and more powerful than the old way of juggling tail, grep, and less across half a dozen files in /var/log/.

---

Conclusion: Stop Reading, Start Querying

The journalctl command is a superpower. It turns the chaotic firehose of system logs into a structured database you can interrogate with precision.

Don’t try to memorize every flag. Bookmark this page. Start using the basic filters (-u, -f, --since) today. They will immediately make you more productive.

The rest—the PID and user filters, the JSON output—are for when you need to perform a full-scale forensic investigation. And now you have the cheat sheet to do it.

Facing a mysterious service crash? Our guide on [ debugging systemd service failures] shows you how to combine journalctl with systemctl status to diagnose any problem.

---

FAQ Section (Targeting “People Also Ask”)

Q: Where are the journalctl logs stored?
A: By default, they are stored in a binary format in /var/log/journal/. This is different from traditional plain text logs. The binary format allows for more efficient storage and indexing, enabling the powerful querying features of journalctl. You can still export any query to plain text or JSON.

Q: How do I clear journalctl logs?
A: You can free up space by vacuuming old logs. Use sudo journalctl --vacuum-time=2weeks to remove logs older than two weeks, or sudo journalctl --vacuum-size=500M to keep only the most recent 500 megabytes of logs. This is safer than manually deleting files.

Q: What is the difference between journalctl and syslog?
A: journalctl reads from systemd’s journal, a centralized binary log. syslog often refers to the traditional text-based logs in /var/log/ (like syslog, auth.log). Many systems are configured to forward journal messages to a traditional syslog daemon for compatibility, but journalctl provides a more feature-rich interface for querying on the local system.

Q: How can I make journalctl logs persistent across reboots?
A: By default, some systems only store logs in memory (a volatile journal). To make them persistent, ensure the /var/log/journal/ directory exists and has the correct permissions. You can often create it with sudo mkdir -p /var/log/journal and then reboot. The systemd-journald service will then begin storing logs on disk.