How to Read Log Files - Introduction to System Log Analysis
What you'll be able to do
- Pick the right log file under /var/log for the symptom at hand
- Use tail, less, and grep for the job each one fits
- Read the source and time of an event from one syslog line
Prerequisites (read these first)
What You'll Learn
- You understand how the
/var/log/directory is organized. - You can use
tail -f,grep, andlessto read logs efficiently. - You know the roles of the key log files:
syslog,auth.log,kern.log. - You can parse the syslog format (timestamp, process name, PID, message).
- You can apply practical log investigation patterns in real troubleshooting.
Quick Summary (Log Investigation Workflow)
- Run
ls /var/log/to identify the target file - Use
tail -n 100to start from the end;tail -ffor live monitoring - Narrow down with
grepusing error keywords - Use
lessto scroll through context around findings
Every command in this article only reads
ls / tail / less / cat / grep display file contents and never rewrite them.
They are safe to run on a production server.
Deleting or truncating a log file is a different story. Those dangers are called out inline below.
What Is /var/log?
Conclusion: Linux system logs collect under /var/log, so troubleshooting starts there.
Nearly all Linux system logs are stored under /var/log/. This directory holds records written by the kernel, authentication subsystem, and applications — making it the starting point for any troubleshooting session.
Settle the terms first.
| Term | One-line meaning | Other names you'll see |
|---|---|---|
| log | A record of what a program did and when | Also "log file" or "history" |
| daemon | A program that keeps running in the background with no UI | Also "resident process" or "service" |
| syslog | The mechanism that collects logs centrally, and its line format | Distinct from the file /var/log/syslog |
| rsyslog | The daemon that plays the syslog role on current Ubuntu | syslog-ng is an alternative implementation |
| PID | The number the OS assigns to a running process | Also "process ID" |
| log rotation | Automatic splitting and compressing so logs don't grow forever | Rotated as .1, older generations as .2.gz |
ls /var/log/
auth.log dpkg.log kern.log syslog ubuntu-advantage.log boot.log faillog lastlog ufw.log wtmp
Log writers fall into two categories: the syslog daemon (rsyslog or syslog-ng) and applications that write their own log files directly.
What Are the Common Log Files and Their Roles?
Conclusion: Files are split by purpose, so decide which one the symptom points to first.
Files under /var/log/ are organized by purpose. Knowing which file covers which area lets you jump straight to the relevant log rather than searching blindly.
| File | Contents | Use Case |
|---|---|---|
syslog |
General system messages | Unexplained system events |
auth.log |
Auth, sudo, SSH | Failed logins, privilege escalation |
kern.log |
Kernel messages | Hardware errors, OOM kills |
dpkg.log |
Package management | Install/update history |
ufw.log |
UFW firewall | Blocked connections |
boot.log |
Boot-time messages | Boot failure diagnosis |
Files ending in .1 or .gz are older data set aside by rotation. Chasing an event from a few days ago means reading those too.
ls /var/log/syslog*
/var/log/syslog /var/log/syslog.1 /var/log/syslog.2.gz
Compressed files can be read with zgrep / zless without unpacking them.
zgrep -i "error" /var/log/syslog.2.gz
On Ubuntu 20.04+, syslog may not exist in some configurations. Use journalctl to view system logs in that case.
What Are the Basic Commands for Reading Logs?
Conclusion: Use tail for the end, less for context, and cat only for short files.
Three commands cover most log-reading scenarios: tail, less, and cat. Choose based on whether you need the end of the file, interactive scrolling, or a full dump.
tail — Read from the end
# Show last 50 lines tail -n 50 /var/log/syslog # Follow in real time (Ctrl+C to stop) tail -f /var/log/syslog
-f (follow) keeps the output open and streams new lines as they are appended — essential when monitoring a live incident.
With -f the prompt never returns; press Ctrl+C to quit. You are only reading, so quitting affects neither the log nor the service.
less — Scroll interactively
less /var/log/auth.log
Key bindings inside less:
G: Jump to endg: Jump to beginning/keyword: Search forwardn: Next matchq: Quit
cat — Dump the entire file (for short files only)
cat /var/log/boot.log
For large logs, cat produces a wall of output. Prefer less or tail unless the file is short.
Never delete log files to free up disk space
When a disk fills up, rm /var/log/syslog is tempting. It is dangerous for two reasons.
- The writing process still holds the file open, so deleting it frees no space at all.
- A deleted log cannot be recovered, and the evidence for the incident is gone.
To reclaim space, first find out what is using it. Both commands below only display; neither deletes anything.
du -sh /var/log/* | sort -hr | head sudo lsof +L1
The lasting fix is a logrotate configuration. If you must clear a file by hand, use truncate -s 0 <file> (which empties the contents) instead of rm, and read the target filename aloud before you run it.
How to Filter Logs with grep
Conclusion: Narrow long logs with grep, then add -i and -A / -B to keep the context.
grep turns a wall of log text into targeted results. It works best piped with tail or as a direct filter on a log file.
Extract error lines
grep -i "error" /var/log/syslog
-i makes the match case-insensitive.
Match multiple keywords
grep -E "error|warn|failed" /var/log/syslog
-E selects extended regular expressions, which is what makes | (or) available.
Real-time grep
tail -f /var/log/syslog | grep "error"
Filter by date
grep "May 31" /var/log/auth.log
Show surrounding context
grep -A 5 -B 5 "Failed password" /var/log/auth.log
-A 5 shows 5 lines after each match; -B 5 shows 5 lines before.
Some log files require sudo to read. If you see Permission denied, prefix the command with sudo: sudo less /var/log/kern.log.
How to Parse the Syslog Format
Conclusion: The syslog layout is fixed: read time, host, process, and PID in order.
Syslog-format entries follow a consistent structure. Recognizing each field speeds up analysis significantly.
May 31 10:23:45 myserver sshd[12345]: Failed password for root from 192.168.1.100 port 22 ssh2
| Field | Value | Meaning |
|---|---|---|
| Timestamp | May 31 10:23:45 |
When the event was recorded |
| Hostname | myserver |
Host that generated the message |
| Process name | sshd |
Process that wrote the log entry |
| PID | [12345] |
Process ID (useful for correlation) |
| Message | Failed password... |
The actual log content |
Once you have the PID, you can follow only the lines that one process wrote.
grep "sshd\[12345\]" /var/log/auth.log
Log timestamps reflect the server's local time. If the server is set to UTC, displayed times may differ from your local time zone.
Check the current setting with timedatectl (another display-only command).
Common Log Investigation Patterns
Conclusion: Each symptom maps to a known file and search term, so memorize the pairs.
These patterns cover the most frequent troubleshooting scenarios encountered in production environments.
| Symptom | File to read | Term to search |
|---|---|---|
| Cannot log in over SSH | auth.log |
Failed password |
| Need to know who ran what | auth.log |
COMMAND |
| Server unstable or crashing | kern.log |
error / oops / panic |
| Broke right after an update | dpkg.log |
install |
| Boot failed | boot.log |
(read it all with less) |
Check for SSH login failures
sudo grep "Failed password" /var/log/auth.log | tail -20
Review sudo command history
sudo grep "sudo" /var/log/auth.log | grep "COMMAND"
Check for kernel errors
sudo grep -iE "error|oops|panic" /var/log/kern.log | tail -30
List package installation history
grep " install " /var/log/dpkg.log
Review boot-time errors
sudo less /var/log/boot.log
journalctl vs. Log Files — When to Use Which?
Conclusion: Read systemd-managed logs with journalctl and file-based logs from /var/log.
Since Ubuntu 16.04, systemd introduced journalctl as the primary log viewer for services. /var/log/ files and the systemd journal coexist; knowing which to use prevents wasted time.
| Scenario | Tool to Use |
|---|---|
| systemd service logs | journalctl -u nginx |
| Kernel messages | journalctl -k |
| Boot-time messages | journalctl -b |
| Legacy app writing to its own file | tail -f /var/log/app.log |
/var/log/auth.log contents |
Either works |
# Follow all logs in real time journalctl -f # Follow a specific service journalctl -u nginx -f
journalctl reads from the systemd journal binary store, not from /var/log/ text files. Depending on rsyslog configuration, both may receive the same events — or they may contain different subsets.
Investigation Checklist
Conclusion: With time, source, and reproducibility pinned down, the investigation moves on.
- [ ] You identified when the event happened and read the logs around that time
- [ ] The file you read matches the symptom (
auth.logfor authentication, and so on) - [ ] You checked rotated files (
.1/.gz) when the window required it - [ ] You confirmed the time zone behind the timestamps
- [ ] You finished the investigation without deleting or truncating any log