Practical journalctl Guide: View and Filter systemd Logs

You’re staring at a broken service, nothing works, and you just need the logs.
If your system uses systemd, journalctl is the main door to those logs.

This guide walks you through using journalctl to view, filter, and understand systemd journal logs so you can actually fix things instead of just guessing.

I’ll keep it practical: short commands, why they matter, and common patterns you’ll actually use when things are on fire.

What journalctl Is And Why You Should Care

On a systemd-based Linux, logs don’t just live in scattered text files.
They’re collected by a system called the journal, managed by the journald daemon.

journalctl is the command-line tool that lets you:
– View logs from kernel, services, and user apps in one place.
– Filter logs by time, boot, service (unit), user, priority, etc.
– Watch logs in real time.
– Output logs in formats (like JSON) that tools can consume.

If you’re debugging a failing service, weird boot issue, or random crash, you’ll be living in journalctl.

Safety note:
– Reading logs is safe.
– Just be careful with commands that rotate or clean logs (not covered deeply here) if you’re on a production machine, and always make sure you know what you’re deleting.

Basic journalctl Usage: Just Show Me The Logs

Let’s start with the simplest thing: see the logs.

journalctl

That dumps everything the journal has.
If your machine has been up for a while, this can be long, so use the usual pager keys:
– Space = next page
– b = previous page
– q = quit

By default, journalctl shows logs in chronological order starting from boot (or from the first log still stored).
If you’re just poking around, this is fine, but for real troubleshooting we need filters.

Filter Logs By Time Or Boot Session

When something breaks, you usually know roughly when it happened.
journalctl can filter by time and by boot, so you’re not scrolling through a week of noise.

Filter by time range

Use --since and --until:

journalctl --since "2024-08-01 10:00" --until "2024-08-01 12:00"

You can also use natural-style time expressions:

journalctl --since "yesterday"
journalctl --since "1 hour ago"
journalctl --since "10 minutes ago" --until "now"

Why this matters: you focus only on the window where the problem occurred.

Filter by boot

systemd tracks logs per boot session.
This is very handy when you reboot a lot during debugging.

See boots:

journalctl --list-boots

Then show logs from a specific boot (for example, the previous one):

journalctl -b -1

Common patterns:

journalctl -b          # current boot
journalctl -b -1       # previous boot
journalctl -b -2       # two boots ago

This is especially useful if something breaks during startup and you’re trying to compare boots.

Filter By Service, User, PID, And Priority

Big logs are useless unless you can zoom in.
journalctl supports filters by systemd unit, user, group, PID, and more.

Logs for a specific service (unit)

If you know the systemd service name, this is your go-to:

journalctl -u your-service-name.service

You can combine it with boot and time filters:

journalctl -u your-service-name.service -b
journalctl -u your-service-name.service --since "1 hour ago"

This is what you’ll use all the time for debugging a single service.

Filter by user or group

You can filter by user ID (UID) or group ID (GID) when you want logs associated with a particular user:

journalctl _UID=1000
journalctl _GID=1000

Replace 1000 with the numeric UID/GID.
This is helpful when an app runs as a specific user.

Filter by process ID (PID)

If you know the PID of a misbehaving process:

journalctl _PID=1234

This shows messages linked to that process.

Filter by priority level

journalctl can filter by log priority.
Typical priorities are (from most to least important):
– 0: emerg
– 1: alert
– 2: crit
– 3: err
– 4: warning
– 5: notice
– 6: info
– 7: debug

To show messages with a specific priority or higher, use -p:

journalctl -p err       # errors and more severe
journalctl -p warning   # warnings and above
journalctl -p info      # info and above

You can combine with service/unit filters:

journalctl -u your-service-name.service -p err

Now you’re only looking at actual bad stuff, not just noise.

Watch Logs In Real Time (Like tail -f)

When you’re testing a change or restarting a service, real-time logs are gold.
journalctl does this with the -f option, similar to tail -f.

Basic follow:

journalctl -f

Follow logs for a single service:

journalctl -u your-service-name.service -f

Combine with other filters if needed:

journalctl -u your-service-name.service -p err -f

This is great when you:
– Restart a service and watch what it logs instantly.
– Reproduce a bug while watching output.

Hit Ctrl + C to stop following.

Change Output Format (Including JSON)

Sometimes you don’t want pretty printed logs.
You want something that scripts or tools can read.

journalctl can output in different formats, including JSON.

Common output tweaks

There are various output modes, but the key one for tooling is JSON.
For example:

journalctl -u your-service-name.service -o json

You can pipe JSON output to other tools in your stack.
This is helpful if you’re building centralized log collection or feeding logs into your own scripts.

If you’re exploring manually you might just stick to the default human-readable format.
JSON becomes more useful once you automate things.

Manage Disk Usage And Persistent Logging

The journal stores logs, and that means disk space.
You’ll want to keep an eye on how much it uses and whether logs survive reboots.

Persistent vs non-persistent logging

The systemd journal can store logs persistently, but that depends on how it’s configured.
If persistent logging isn’t set up, your logs might not survive a reboot.

To avoid surprises on a production system, check how your distro handles persistent logs and configure journal storage appropriately.
That way your troubleshooting logs don’t disappear after a restart.

Managing disk usage (concepts)

You can manage how much space the journal uses through its configuration.
The idea is to strike a balance: enough history to debug problems, but not so much that you fill your disks.

When working on a critical server, be careful before adjusting these settings or clearing logs.
If you’re not sure, test changes on a non-production machine first.

Fix Common journalctl / Journal Issues

Sometimes the problem is that you don’t see the logs you expect.
Or journalctl complains about permissions.

Here are some common pain points and how to think about them.

Missing logs after reboot

If logs seem to vanish when you reboot, your system might not be using persistent journal storage.
That means the journal only keeps logs in memory or in a non-persistent setup.

For critical debugging, you’ll want to ensure your environment is configured for persistent logs.
Otherwise, you lose context every time someone reboots the box.

Permission errors when running journalctl

On many systems, regular users can’t see everything in the journal.
If you’re getting errors or seeing only partial logs, you might need higher privileges.

You can run journalctl with proper permissions (for example via an appropriate role or elevated context) to see full system logs.
Just remember: more access means more responsibility; don’t share full logs carelessly, because they can contain sensitive paths, usernames, or other details.

Logs from multiple services are hard to read

If you’re drowning in messages from different apps, rely on filters:
– Use -u to focus on a single unit.
– Use -p to limit by severity.
– Add --since / --until to shrink the time window.

Example combo:

journalctl -u your-service-name.service -p warning --since "30 minutes ago"

This pattern alone handles a lot of real-world debugging.

Practical journalctl Recipes You’ll Actually Use

Let’s collect the most useful commands in one place so you can copy-paste fast when something is broken.

See logs for a service in this boot

journalctl -u your-service-name.service -b

See logs for a service in the last hour

journalctl -u your-service-name.service --since "1 hour ago"

Watch a service log in real time

journalctl -u your-service-name.service -f

Only show errors (and worse) for a service

journalctl -u your-service-name.service -p err

Show system logs from previous boot

journalctl -b -1

Output service logs as JSON

journalctl -u your-service-name.service -o json

Use these as a base, then layer in time ranges, priorities, and other filters as needed.

If this worked for you, keep CrushEdge handy for the next fix.