Kahibaro
Discord Login Register

Log files in /var/log

Understanding `/var/log` in Context

On most Linux systems, /var/log is the central place where system and application logs are stored. From a monitoring perspective, it’s where you:

This chapter focuses on what you’ll typically find inside /var/log, how the files are structured and rotated, and how to read them efficiently for monitoring and troubleshooting.

How Logging to `/var/log` Works (High Level)

Modern systems often use systemd-journald plus a traditional syslog daemon (like rsyslog or syslog-ng):

You don’t need to configure this here; just understand that:

Structure of `/var/log`

Typical top-level contents might look like:

/var/log
├── auth.log        # or secure
├── boot.log
├── dmesg
├── kern.log
├── messages
├── syslog
├── faillog
├── journal/        # systemd journal (binary)
├── apt/            # package manager logs (Debian/Ubuntu)
├── dnf.rpm.log     # package manager logs (Fedora/RHEL)
├── httpd/ or apache2/  # web server logs
├── nginx/
├── samba/
├── Xorg.0.log
└── ... many more ...

The exact set of files and directories varies by distribution and installed software, but there are common patterns:

Key System Log Files

Exact filenames differ by distribution, but these are common categories and where they usually appear.

General System Logs

`/var/log/syslog` (Debian/Ubuntu)

Basic usage:

sudo less /var/log/syslog
sudo tail -f /var/log/syslog

On systems without syslog, this file may not exist; instead, journalctl is used.

`/var/log/messages` (RHEL, CentOS, Fedora, some others)

Usage:

sudo tail -f /var/log/messages
sudo grep -i error /var/log/messages

Kernel-Related Logs

`/var/log/kern.log` (often on Debian-based systems)

Example:

sudo grep -i "error" /var/log/kern.log
sudo tail -f /var/log/kern.log

`/var/log/dmesg`

Usage:

sudo less /var/log/dmesg

Boot and Startup Logs

`/var/log/boot.log`

Example:

sudo less /var/log/boot.log

On systemd-based systems, more detailed boot logs often come via journalctl -b, but boot.log still provides a plain-text summary when present.

Authentication and Security Logs

`/var/log/auth.log` vs `/var/log/secure`

These files log:

Monitoring examples:

# Show recent auth events (Debian/Ubuntu)
sudo tail /var/log/auth.log
# Show failed SSH attempts
sudo grep "Failed password" /var/log/auth.log
# On RHEL/Fedora-based systems
sudo tail /var/log/secure
sudo grep "Failed password" /var/log/secure

`/var/log/faillog`

Example:

sudo faillog          # Summary of failed logins
sudo faillog -u username

Useful for security monitoring (brute-force login attempts).

`/var/log/btmp` and `/var/log/wtmp`

Examples:

# Show login history
last                    # reads /var/log/wtmp
# Show failed login attempts
sudo lastb              # reads /var/log/btmp

These are binary logs; do not edit them directly.

Service-Specific Logs in `/var/log`

Many services write their own logs under /var/log or a subdirectory. You’ll use these heavily for monitoring specific services.

Web Servers

Apache HTTPD

Typical locations:

Common files:

Usage examples:

# Follow Apache access log
sudo tail -f /var/log/apache2/access.log
# Check for 500 Internal Server Errors
sudo grep " 500 " /var/log/apache2/access.log

Nginx

Typical location: /var/log/nginx/

Common files:

Monitoring example:

sudo tail -f /var/log/nginx/access.log
sudo grep -i "error" /var/log/nginx/error.log

Database Servers

Examples (paths may vary):

Use these to:

Other Common Service Logs

Each service typically documents its log file locations in its configuration files or manual pages.

Package Management Logs

These logs help you answer: What changed on this system and when?

Debian/Ubuntu — `/var/log/apt/`

Key files:

Examples:

less /var/log/apt/history.log
grep "install" /var/log/apt/history.log

RHEL/Fedora — `dnf.rpm.log` and `yum.log`

Common files:

Check which packages were installed/updated and when:

sudo less /var/log/dnf.rpm.log
sudo grep "install" /var/log/yum.log

Other managers

These are useful for correlating new issues with recent package changes.

X and Desktop Logs

On desktop systems:

These are primarily used for troubleshooting graphical display problems.

Log Rotation in `/var/log`

Log files grow over time; logrotate (or a similar tool) manages their size, retention, and compression.

Recognizing Rotated Logs

In /var/log, you’ll often see patterns like:

syslog
syslog.1
syslog.2.gz
syslog.3.gz

Or:

messages
messages-20241115
messages-20241108.gz

Meaning:

To search in compressed logs, either decompress them or use zgrep, zless, etc.:

zgrep "error" /var/log/syslog.2.gz
zless /var/log/messages-20241108.gz

Basic `logrotate` Behavior (Conceptual)

While configuration details are separate:

Configuration is normally in /etc/logrotate.conf and /etc/logrotate.d/. Understanding that logs rotate helps when you’re looking for older events.

Access Control and Permissions

Many logs in /var/log are readable only by root or certain groups, because they contain sensitive data (usernames, IPs, command histories via sudo, etc.).

Check permissions:

ls -l /var/log/auth.log
ls -ld /var/log

If you’re troubleshooting as a regular user, you may need sudo:

sudo less /var/log/secure
sudo tail -f /var/log/messages

Avoid changing permissions on sensitive logs just to make them readable; that can introduce security risks.

Practical Monitoring Examples Using `/var/log`

Here are some focused tasks tied directly to /var/log for day-to-day monitoring and troubleshooting.

Monitor a Service for Errors

For example, Apache on Debian/Ubuntu:

# Follow the error log for new entries
sudo tail -f /var/log/apache2/error.log
# Look for 'Segmentation fault' in recent history
sudo grep -i "segmentation fault" /var/log/apache2/error.log

Investigate SSH Brute-Force Attempts

Debian/Ubuntu:

sudo grep "Failed password" /var/log/auth.log | tail
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr

RHEL/Fedora:

sudo grep "Failed password" /var/log/secure

Correlate System Crash with Package Updates

Suppose a service started failing yesterday:

  1. Check auth/system logs for failure time:
sudo grep "myservice" /var/log/syslog
  1. Check if any packages were upgraded near that time:
# Debian/Ubuntu
less /var/log/apt/history.log
# RHEL/Fedora
less /var/log/dnf.rpm.log

Search Historic Logs Including Rotated Files

To search all syslog instances (current + rotated, compressed):

sudo zgrep "myservice" /var/log/syslog*

Adapt for messages or other logs as needed.

Good Practices When Working with `/var/log`

The more familiar you become with the layout and contents of /var/log, the faster you’ll be able to diagnose and monitor your systems in real-world scenarios.

Views: 24

Comments

Please login to add a comment.

Don't have an account? Register now!