Checking Logs the Right Way in Linux

By Bo MorganLinux Basics

 

When something goes wrong on a Linux system, the information you need is almost always in the logs.
The problem for beginners is not that logs are complicated, but that it is unclear where to start and what matters.

This guide walks through the simplest, correct way to check logs on a modern Linux system.
No guessing. No memorizing file paths. Just a calm, step-by-step process you can rely on in real IT situations.

What Logs Are and Why They Matter

Logs are plain text records of what your system and its services are doing.

They tell you:

  • What started

  • What stopped

  • What failed

You do not need to read every log on the system.
You only need to look in the right place.

On modern Linux systems, the primary place to check logs is the system journal.

Viewing System Logs with journalctl

The main tool for reading system logs is journalctl.

It is built in on most modern Linux distributions and collects logs from:

  • The operating system

  • System services like SSH

  • Networking and background services

This is where you should start.

Basic command

journalctl

Example output

Jun 10 08:42:15 server systemd[1]: Started OpenSSH server daemon. 
Jun 10 08:43:02 server sshd[1023]: Accepted password for user from 10.0.0.5 
Jun 10 08:45:11 server systemd[1]: Stopped OpenSSH server daemon.

Each line shows:

  • The date and time

  • The system or service name

  • A short message describing what happened

By default, logs open in a scrollable view.

  • Use the arrow keys to move up and down

  • Press q to quit

Real-world use:
If a service stopped working overnight, this confirms when it stopped and what the system recorded at the time.

Jumping to the Most Recent Logs

Most troubleshooting starts with what just happened.

Instead of scrolling through older entries, you can jump directly to the latest logs.

Command

journalctl -e

This places you at the end of the log output.

The -e option means “go to the end,” keeping your focus on current activity.

Real-world use:
When a user says, “It stopped working five minutes ago,” this is where you look first.

Watching Logs Live as Events Happen

Sometimes you want to see logs update in real time.

This is useful when restarting services or testing changes.

Command

journalctl -f

Example output

Jun 10 09:01:12 server sshd[1221]: Failed password for invalid user admin 
Jun 10 09:01:18 server sshd[1221]: Connection closed

The -f option means “follow.”
New log entries appear as they are written.

Press Ctrl + C to stop.

Real-world use:
Restart a service in one terminal and watch the logs in another to confirm it starts cleanly.

Filtering Logs by Service

Logs become much more useful when you filter them.

Instead of reading everything, you can focus on one service at a time.

Command

journalctl -u ssh

Example output

Jun 10 08:42:15 server systemd[1]: Started OpenSSH server daemon. 
Jun 10 08:45:11 server systemd[1]: Stopped OpenSSH server daemon.

The -u option stands for “unit,” which is systemd’s name for a service.

This shows only logs related to SSH.

Real-world use:
If SSH is failing, this immediately narrows the problem to the correct service.

Limiting Logs by Time

Time filtering keeps logs manageable.

You rarely need logs from days ago to solve today’s problem.

Command

journalctl --since "10 minutes ago"

Only logs from the last 10 minutes are shown.

You can also use:

  • "today"

  • "yesterday"

  • Specific dates

Real-world use:
This is helpful when troubleshooting scheduled jobs or automated tasks to confirm whether they ran.

Common Beginner Mistakes to Avoid

Reading logs with cat
This floods the screen and removes helpful navigation. Use journalctl instead.

Ignoring time context
Always ask when the problem happened. Filter by time before reading.

Restarting services without checking logs
Logs should guide your actions, not come after them.

Practical Example: Troubleshooting an SSH Login Issue

A user reports they cannot connect to a server using SSH.

Step 1: Follow SSH logs

journalctl -u ssh -f

Step 2: Attempt a login from another machine

Example output

Failed password for user from 10.0.0.12

This confirms:

  • SSH is running

  • The connection is reaching the server

  • The failure is authentication, not networking

That immediately narrows the problem and saves time.

A Small Next Step

Once you are comfortable reading logs, the next step is learning how to search them.

For example:

journalctl | grep -i "error"

This helps important messages stand out without reading everything.

Conclusion

Logs are not something to fear.
They are simply messages written by your system.

If you work through these steps a few times, checking logs will start to feel natural and predictable.
This is one of the most important habits you can build as a Linux administrator.