Linux logs are not complicated.
They are just text files that record what your system is doing. When something breaks, slows down, or behaves strangely, logs are usually where the answer lives.
In this guide, you will learn how to find logs, read them safely, search them efficiently, and use them to troubleshoot real problems. Everything here is practical. No theory. Just the commands you need and how to use them with confidence.
All technical steps and examples are pulled directly from the original script
What Are Logs and Where Are They?
Logs are plain text files.
They record system activity. If something fails, the log usually tells you why.
On most Linux systems, logs live in one directory:
/var/log
Let’s move into that directory and see what is there.
cd /var/log
ls
Example output:
alternatives.log
auth.log
boot.log
dpkg.log
kern.log
syslog
What is happening here:
- cd /var/log moves you into the log directory
- ls lists the files inside
Each file tracks something different.
For beginners, the most important file is usually:
syslog
This is the general system log. If you are unsure where to start, start here.
Real-World Use Case
If someone says, “The server was acting strange,” this is the first place you check.
Viewing a Log File Safely
Log files can be very large. You should not open them in a text editor first.
Instead, use a viewer designed for reading large files.
The simplest and safest tool is:
less
To read the syslog file:
less syslog
Example output:
May 28 10:01:22 server1 systemd[1]: Started Session 12 of user bob.
May 28 10:02:01 server1 CRON[1452]: (root) CMD (run-parts /etc/cron.hourly)
May 28 10:03:44 server1 sshd[1623]: Accepted password for bob from 192.168.1.10 port 54231
Each line contains:
- Date and time
- Hostname
- Service name
- Message
You can scroll using the arrow keys.
Press q to quit.
This allows you to inspect logs without modifying them.
Real-World Use Case
If someone says, “I cannot log in,” open syslog and scroll until you see sshd entries. Those lines tell you what happened during the login attempt.
Seeing Only the End of a Log
Most problems just happened. You usually do not need the entire file.
You just need the newest entries.
Use:
tail
To see the last 10 lines:
tail syslog
Example output:
May 28 10:20:01 server1 CRON[2100]: (root) CMD (backup.sh)
May 28 10:21:10 server1 sshd[2150]: Failed password for invalid user test
May 28 10:21:12 server1 sshd[2150]: Connection closed
tail shows the most recent activity at the bottom of the file.
Real-World Use Case
If a user says, “The backup just failed,” run:
tail syslog
The error is usually right there at the bottom.
Watching Logs Live
Sometimes you need to see events as they happen.
For example:
- Restarting a service
- Testing SSH
- Troubleshooting a web server
Use:
tail -f
The -f means follow.
tail -f syslog
Example output:
May 28 10:25:11 server1 sshd[2201]: Accepted password for bob
May 28 10:25:12 server1 sshd[2201]: Session opened
New lines appear automatically as activity happens.
Press Ctrl + C to stop watching.
Real-World Use Case
Restart a service:
sudo systemctl restart nginx
In another terminal:
tail -f syslog
You will immediately see whether it started successfully or produced errors. This is how real troubleshooting works.
Searching Inside Logs
Logs can be very large. Scrolling manually is inefficient.
Instead, search.
The simplest search tool is:
grep
To search for SSH activity:
grep ssh syslog
Example output:
May 28 10:21:10 server1 sshd[2150]: Failed password for invalid user test
May 28 10:25:11 server1 sshd[2201]: Accepted password for bob
grep shows only the lines that contain the word you searched for.
Real-World Use Case
If login attempts are failing:
grep Failed syslog
You instantly see failed logins without scrolling through the entire file.
Common Beginner Mistakes
Permission Denied
You may run:
less syslog
And see:
Permission denied
Some logs require administrative privileges.
Fix it with:
sudo less syslog
You will be prompted for your password.
Editing Logs by Accident
Do not open logs with:
nano syslog
Logs are not meant to be edited. Always view only.
Looking in the Wrong File
If you do not see what you expect:
- Check auth.log for login issues
- Check kern.log for kernel issues
Start with syslog, then narrow down.
Practical IT Scenario
A user says:
“I cannot SSH into the server.”
Step 1 — Watch the log live:
tail -f syslog
Step 2 — Attempt to log in from another machine.
You see:
Failed password for invalid user test
This tells you:
- SSH is running
- The network is working
- The username is incorrect
Now you know the problem is credentials, not connectivity.
Logs remove guessing. They give you evidence.
Optional Next Step: journalctl
On newer systems, logs are managed by systemd.
A simple command to view recent system errors:
journalctl -xe
To view logs for a specific service:
journalctl -u nginx
This narrows logs to just that service.
If you are comfortable with everything above, this is your next step. But master /var/log first.
Conclusion
Logs are just text files recording system activity.
If you practice using:
- less
- tail
- tail -f
- grep
You will be able to troubleshoot most beginner Linux issues with confidence.
Work through these commands a few times. Repetition builds clarity. Once reading logs feels normal, troubleshooting becomes much less intimidating.