Linux command list

journalctl command: read the logs of a service

__ __ _ _____
\ \ / /__| |_|_ _|__ _ __ _ __ ___
\ \ /\ / / _ \ '_ \| |/ _ \ '__| '_ ` _ \
\ V V / __/ |_) | | __/ | | | | | |
\_/\_/ \___|_.__/|_|\___|_| |_| |_| |_
 
A sandbox for trying journalctl. Nothing here can touch your real files.
user@webterm:~/project$
 

journalctl reads the logs systemd collects. Learn how `-u` narrows to one service, how `-n` shows just the end, and what `-f` does, by running the commands in a real terminal in your browser.

Updated: 2026-09-07

Syntax

journalctl [options]

It prints what systemd collected, oldest first.

Try it first

Narrowing to one service is the starting point.

$ journalctl -u nginx
Mar 23 08:00:01 webterm-server nginx[1001]: Starting A high performance web server and a reverse proxy server...
Mar 23 08:00:02 webterm-server nginx[1001]: nginx/1.18.0
Mar 23 08:00:02 webterm-server nginx[1001]: Started A high performance web server and a reverse proxy server.
Mar 23 09:15:30 webterm-server nginx[1001]: conflicting server name "localhost" on 0.0.0.0:80, ignored
Mar 23 10:30:00 webterm-server nginx[1001]: 1024 worker_connections are enough for most sites

Each line is the time, the host, the process with its PID, and the message. Where systemctl status gives a summary, this is the record itself.

Just the end

Logs are long, and usually only the end matters.

$ journalctl -u nginx -n 2
Mar 23 09:15:30 webterm-server nginx[1001]: conflicting server name "localhost" on 0.0.0.0:80, ignored
Mar 23 10:30:00 webterm-server nginx[1001]: 1024 worker_connections are enough for most sites

Without -u you get every service together.

$ journalctl -n 5
Mar 23 09:15:30 webterm-server nginx[1001]: conflicting server name "localhost" on 0.0.0.0:80, ignored
Mar 23 09:45:12 webterm-server mysql[1201]: Aborted connection 42 to db: 'myapp' user: 'webapp' host: '10.0.0.5' (Got timeout reading communication packets)
Mar 23 10:00:01 webterm-server cron[501]: (root) CMD (/usr/lib/apt/apt.systemd.daily)
Mar 23 10:30:00 webterm-server nginx[1001]: 1024 worker_connections are enough for most sites
Mar 23 10:30:15 webterm-server sshd[456]: Received disconnect from 192.168.1.10 port 52341:11: disconnected by user

That is the quickest way to see what every service did just before now.

Newest first

-r reverses the order.

$ journalctl -u nginx -r
Mar 23 10:30:00 webterm-server nginx[1001]: 1024 worker_connections are enough for most sites
Mar 23 09:15:30 webterm-server nginx[1001]: conflicting server name "localhost" on 0.0.0.0:80, ignored
Mar 23 08:00:02 webterm-server nginx[1001]: Started A high performance web server and a reverse proxy server.
Mar 23 08:00:02 webterm-server nginx[1001]: nginx/1.18.0
Mar 23 08:00:01 webterm-server nginx[1001]: Starting A high performance web server and a reverse proxy server...

Searching

For a keyword, pipe into grep.

$ journalctl | grep Aborted
Mar 23 09:45:12 webterm-server mysql[1201]: Aborted connection 42 to db: 'myapp' user: 'webapp' host: '10.0.0.5' (Got timeout reading communication packets)

The process name in the line, here mysql[1201], tells you whose message it is. Then narrow to that service and read around it.

$ journalctl -u mysql
Mar 23 08:00:05 webterm-server mysql[1201]: Starting MySQL Community Server...
Mar 23 08:00:08 webterm-server mysql[1201]: InnoDB: Buffer pool(s) load completed at 080008
Mar 23 08:00:09 webterm-server mysql[1201]: Started MySQL Community Server.
Mar 23 09:45:12 webterm-server mysql[1201]: Aborted connection 42 to db: 'myapp' user: 'webapp' host: '10.0.0.5' (Got timeout reading communication packets)

Following along

-f keeps printing as new lines arrive.

$ journalctl -u nginx -f
Mar 23 08:00:01 webterm-server nginx[1001]: Starting A high performance web server and a reverse proxy server...
Mar 23 08:00:02 webterm-server nginx[1001]: nginx/1.18.0
Mar 23 08:00:02 webterm-server nginx[1001]: Started A high performance web server and a reverse proxy server.
Mar 23 09:15:30 webterm-server nginx[1001]: conflicting server name "localhost" on 0.0.0.0:80, ignored
Mar 23 10:30:00 webterm-server nginx[1001]: 1024 worker_connections are enough for most sites

On a real machine it waits there, adding lines as they happen. You leave it open in one window and act in another. Ctrl+C ends it.

When you actually reach for it

journalctl is what you type to find out why a service is not behaving.

SituationWhat to type
Read why a start failedjournalctl -u nginx -n 50
Watch a deploy happenjournalctl -u myapp -f
See what every service just didjournalctl -n 20
Search for a keywordjournalctl | grep Aborted
Read newest firstjournalctl -u nginx -r

Read the state with systemctl status, read the reason here. That order is the shape of most server investigations.

Things that trip people up

-u takes the same names as systemctl. Both nginx and nginx.service work. A name that has no entries says so.

$ journalctl -u nosuchservice
-- No entries --

Old entries do get deleted. The journal has a size limit and drops the oldest entries. "Yesterday's log is missing" may mean it was rotated away, not that nothing was logged.

Cut it down from the start. Plain journalctl scrolls past you. Reach for -n, a grep, or a pager in the same command rather than afterwards.

Practise it hands-on

webterm.appthis site

  • Advanced Terminal Commands

    Learn commands for specific situations

    Try the tutorial

learn.webterm.appa separate site

>_WEBTERM LEARN

WebTerm Learn: from one command to actually using it

Commands stick when they show up in a real sequence of work, not one at a time. There is a course that builds them up in order.

See the course

Related commands

systemctl / grep / tail / less

Frequently asked questions

How is this different from reading a log file?
On a systemd machine, the output of every service is collected into one journal. journalctl reads it even when there is no file under `/var/log`.
How do I look at one service?
`journalctl -u nginx`. `-u` selects the unit, and `.service` can be left off.
What does -f do?
It keeps printing new lines as they arrive; on a real machine you leave it running and stop it with Ctrl+C. Handy during a deploy or while sending a test request.
When do I use this instead of systemctl status?
`systemctl status` summarises the state, `journalctl -u` is the log itself. For why something is not working, read the log.
Do I need sudo?
On a real machine you often do, to read other users' or system-wide entries. Your own service's log may be readable without it.