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
journalctl [options]
It prints what systemd collected, oldest 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.
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.
-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...
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)
-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.
journalctl is what you type to find out why a service is not behaving.
| Situation | What to type |
|---|---|
| Read why a start failed | journalctl -u nginx -n 50 |
| Watch a deploy happen | journalctl -u myapp -f |
| See what every service just did | journalctl -n 20 |
| Search for a keyword | journalctl | grep Aborted |
| Read newest first | journalctl -u nginx -r |
Read the state with systemctl status, read the reason here.
That order is the shape of most server investigations.
-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.
webterm.appthis site
Advanced Terminal Commands
Learn commands for specific situations
learn.webterm.appa separate site

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