Log Analysis: Reading System Logs — Windows to Linux Guide

What This Guide Achieves

Goal	Status
Understand where Linux stores logs	Done
Read system logs with journalctl	Done
Identify common log entries and what they mean	Done
Know which logs matter and which to ignore	Done

The Problem (Windows User Perspective)

On Windows, you use Event Viewer to check system logs — but most people never open it. On Linux, logs are text-based and accessible from the terminal. When something goes wrong, logs are the first place to look. The trick is knowing which tool to use and how to filter out the noise.

Where Logs Live

Location	What It Contains	How to Read
journalctl	All system logs (systemd journal)	`journalctl` command
`/var/log/syslog`	General system messages	`cat /var/log/syslog`
`/var/log/auth.log`	Authentication attempts (login, sudo)	`cat /var/log/auth.log`
`/var/log/kern.log`	Kernel messages (hardware, drivers)	`cat /var/log/kern.log`
`/var/log/apt/`	Package manager history	`cat /var/log/apt/history.log`
`/var/log/dpkg.log`	Package install/remove details	`cat /var/log/dpkg.log`
`dmesg`	Kernel ring buffer (boot + hardware)	`dmesg` or `sudo dmesg`

Essential journalctl Commands

View Recent Logs

# Last 50 log entries
journalctl -n 50

# Logs from the current boot
journalctl -b

# Logs from the previous boot (useful after a crash)
journalctl -b -1

Filter by Time

# Logs from the last hour
journalctl --since "1 hour ago"

# Logs from today
journalctl --since today

# Logs from a specific time range
journalctl --since "2026-04-12 10:00" --until "2026-04-12 12:00"

Filter by Priority (Severity)

# Only errors and above
journalctl -p err

# Errors and warnings
journalctl -p warning

# Critical and emergency only
journalctl -p crit

Priority levels (from most to least severe):

Level	Name	What It Means
0	`emerg`	System is unusable
1	`alert`	Immediate action required
2	`crit`	Critical error
3	`err`	Error — something failed
4	`warning`	Warning — not broken, but attention needed
5	`notice`	Normal but significant event
6	`info`	Informational
7	`debug`	Debug-level detail

Filter by Service

# Logs from a specific service
journalctl -u auto-cpufreq
journalctl -u thinkfan
journalctl -u NetworkManager
journalctl -u snapd

# Follow logs in real-time (like tail -f)
journalctl -u thinkfan -f

Useful Combinations

# Errors from current boot
journalctl -b -p err

# Errors from last hour, no paging (output to terminal)
journalctl --since "1 hour ago" -p err --no-pager

# Kernel messages from current boot
journalctl -b -k

# Disk-related messages
journalctl -b | grep -i "disk\|nvme\|sda\|sdb"

Using dmesg (Kernel Messages)

dmesg shows kernel-level messages — hardware detection, driver loading, errors:

# All kernel messages (may need sudo)
sudo dmesg

# Last 30 kernel messages
sudo dmesg | tail -30

# Filter for USB events
sudo dmesg | grep -i usb

# Filter for errors
sudo dmesg --level=err,warn

# Clear kernel message buffer (useful for isolating new events)
sudo dmesg -C
# Then plug in a device or trigger an event
sudo dmesg    # Shows only new messages

Real-World Log Analysis Example

From analyzing an actual Zorin OS 18.1 log file, here’s what different entries mean:

Normal / Harmless Entries

Log Entry	What It Means	Action Needed
`wpa_supplicant: signal change`	WiFi signal strength fluctuation	None — normal behavior
`snapd: Stopping/Starting`	Snap daemon cycling	None — normal during snap updates
`systemd-timedated: activated/deactivated`	Time service responding to queries	None — normal
`systemd-hostnamed: activated/deactivated`	Hostname service responding to queries	None — normal
`packagekitd: transaction completed`	Package manager finished checking	None — normal
`AppArmor: profile replacement for snap-confine`	Snap security profile update	None — normal during snap operations

Worth Investigating

Log Entry	What It Means	What to Do
`seahorse: Timeout was reached`	GNOME Keyring timing out during search	Usually harmless, but if persistent, restart `gnome-keyring-daemon`
`Can't update stage views actor`	Minor rendering issue	Usually harmless — if visual glitches occur, log out/in
`Buggy client sent _NET_ACTIVE_WINDOW message with timestamp of 0`	An app tried to raise its window incorrectly	Identifies which app is buggy — usually harmless
CPU consumed high time	App using significant CPU	Check with `htop` if system feels slow

Needs Attention

Log Entry	What It Means	What to Do
`Out of memory`	System ran out of RAM	Close apps, check for memory leaks with `htop`
`I/O error` on disk	Disk read/write failure	Check disk health: `sudo smartctl -a /dev/nvme0n1`
`temperature above threshold`	CPU/hardware overheating	Check fans: `sensors`, see Fan Guide
`segfault`	An application crashed	Check which app crashed, update or reinstall it
`failed to start` (for a service you need)	A system service didn’t start	`systemctl status service-name` for details

Checking Package History

See what was recently installed or removed:

# Recent apt operations
cat /var/log/apt/history.log | tail -50

# Search for a specific package in history
grep "texlive" /var/log/apt/history.log

# Full dpkg log (every package operation)
grep "install\|remove" /var/log/dpkg.log | tail -30

Quick Diagnostic Workflow

When something goes wrong, follow this order:

Check recent errors:

journalctl -b -p err --no-pager | tail -30

Check the specific service (if you know which):

systemctl status service-name
journalctl -u service-name -n 50

Check kernel messages (for hardware issues):
```
sudo dmesg --level=err,warn | tail -20
```
Check system resource usage:
```
htop
df -h
free -h
```

Search logs for a keyword:

journalctl -b | grep -i "error\|fail\|critical" | tail -30

What Didn’t Work (and Why)

Approach Tried	Why It Failed
Reading `/var/log/syslog` directly for everything	Too noisy — journalctl with filters is much more useful
Panicking about every warning in logs	Most warnings are harmless — focus on `err` and `crit` level entries
Using `dmesg` to find application errors	dmesg only shows kernel messages — use journalctl for app logs
Not using `--since` or `-b` filters	Without filters, journalctl dumps thousands of lines from all boots

Fan and Power Management — Hardware monitoring and temperature logs
Common Issues — FAQ for common problems
APT Repository Issues — Package manager troubleshooting