Log Analysis: Reading System Logs

Overview

When something goes wrong on Linux, the logs are the first place to look — and unlike Windows Event Viewer, they are plain text and reachable from the terminal. This guide shows where logs live (systemd journal, /var/log, the kernel ring buffer), how to filter journalctl down to what actually matters, and how to tell the entries that matter from the background noise every system produces.

---

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

Source	What It Contains	How to Read
systemd journal	All system logs	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
kernel ring buffer	Kernel messages (boot + hardware)	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

These entries are common across Ubuntu 24.04-based systems including both Linux Mint and Zorin OS. The examples below came from a Zorin OS 18.1 log:

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 (sudo apt install htop if not installed)

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:

1. Check recent errors:

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

2. Check the specific service (if you know which):

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

3. Check kernel messages (for hardware issues):

   sudo dmesg --level=err,warn | tail -20

4. Check system resource usage:

   htop
   df -h
   free -h

5. 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

---

Related Guides

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