DEV Community

dpm_bush
dpm_bush

Posted on Originally published at sshflow.com

journalctl: Find the Logs Behind a Linux Service Failure

#productivity #tutorial #devops #beginners

When a Linux service fails, systemctl status gives you a quick snapshot—but the journal is where you can investigate what happened before and after the failure. journalctl lets you narrow logs by service, time, boot, and severity, so you can get useful context without scrolling through everything.

Start with the service and the time window

For a first look at a service’s logs, specify its systemd unit with -u:

journalctl -u nginx
Enter fullscreen mode Exit fullscreen mode

The unit name works with or without .service. You can also query multiple units at once; entries appear in chronological order across the matched services:

journalctl -u nginx -u php-fpm
Enter fullscreen mode Exit fullscreen mode

That can help when one service depends on another. For example, the application reporting a problem may not be the service that caused it. If you’re checking the unit’s overall state as well as its logs, learn how to read the important lines in systemctl status.

When you know roughly when the issue started, add a time filter:

journalctl -u nginx --since "1 hour ago"
journalctl -u nginx --since "2026-08-29 09:00:00" --until "2026-08-29 10:00:00"
Enter fullscreen mode Exit fullscreen mode

You can use phrases such as today as well as explicit timestamps. Times without a timezone are interpreted in the system’s local time. If you’re comparing logs across servers or with a monitoring dashboard, --utc can help keep the time basis consistent.

Get recent context, then watch live

To print a fixed number of recent entries and exit, use -n:

journalctl -u nginx -n 50
Enter fullscreen mode Exit fullscreen mode

To keep watching for new entries, use -f:

journalctl -u nginx -f
Enter fullscreen mode Exit fullscreen mode

Combine them when you want recent context followed by live output:

journalctl -u nginx -n 50 -f
Enter fullscreen mode Exit fullscreen mode

Press Ctrl+C to stop following. Without a number, -n defaults to 10 entries; -f also shows the last 10 before streaming new ones. This is handy when you reproduce a failure and want to see what the service logs at that moment.

Check errors without losing the surrounding story

The -p option filters by priority. A single priority shows messages at that level and more severe levels:

journalctl -u nginx -p err
Enter fullscreen mode Exit fullscreen mode

That includes errors and more severe entries, but excludes warnings and routine informational messages. You can use names such as err and warning, or their numeric equivalents. A range lets you specify just the levels you want:

journalctl -u nginx -p 0..3
Enter fullscreen mode Exit fullscreen mode

Filtering can cut down noise, but don’t assume every serious problem will be logged as an error. Applications choose the priority for their messages, so it can be useful to inspect the surrounding entries too. To search message text, -g accepts a regular expression:

journalctl -u nginx -g "connection refused"
Enter fullscreen mode Exit fullscreen mode

For a quick look at the newest entries with systemd’s catalog explanations where available, use:

journalctl -xeu nginx
Enter fullscreen mode Exit fullscreen mode

Here, -e jumps to the end of the output in the pager, while -x adds explanatory catalog text for entries that have it. It does not provide extra explanation for every application message.

Look across reboots

A server may have restarted since the incident. Use -b to limit output to the current boot, or -b -1 for the previous one:

journalctl -b
journalctl -b -1
Enter fullscreen mode Exit fullscreen mode

To see which boots are available, run:

journalctl --list-boots
Enter fullscreen mode Exit fullscreen mode

The list uses 0 for the current boot, -1 for the previous boot, and lower numbers for older boots still retained in the journal. If only the current boot appears, the system may be using volatile journal storage, where logs from earlier boots aren’t retained. Add -k to show kernel messages, for example:

journalctl -k -b
Enter fullscreen mode Exit fullscreen mode

Check journal storage before cleaning it up

The journal can use disk space, so check its current usage before changing retention:

journalctl --disk-usage
Enter fullscreen mode Exit fullscreen mode

Vacuum commands permanently delete archived journal files. They don’t remove the active journal file, but the archived entries they delete cannot be recovered. For example, these commands keep archived data within a size, age, or file-count limit:

sudo journalctl --vacuum-size=500M
sudo journalctl --vacuum-time=2weeks
sudo journalctl --vacuum-files=100
Enter fullscreen mode Exit fullscreen mode

Use a vacuum command only when you intend to remove older archived logs. Journal retention also depends on configuration, including storage mode and size limits, so logs may disappear sooner than an age setting alone suggests.

A simple troubleshooting sequence

When a service fails, start with its state and recent logs. Then expand the time window or check the previous boot if the failure followed a restart:

systemctl status nginx
journalctl -u nginx -n 50
journalctl -u nginx --since "30 minutes ago"
journalctl -u nginx -b -1
Enter fullscreen mode Exit fullscreen mode

systemctl tells you about the unit’s state; journalctl helps you trace the events behind it. After you’ve identified and addressed the cause, check the safe sequence for restarting a systemd service if a restart is needed.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Top comments (0)