Where to Find the Logs

Logging & Log Analysis

Chapter 3 · Where to Find the Logs

Knowing what a log is and how severity works doesn't help much if you can't actually locate one. This chapter is a practical map: where Linux keeps its logs, the modern systemd alternative to plain log files, how Windows does the equivalent job very differently, and what to do when a log genuinely isn't where the defaults say it should be.

Linux: The /var/log/ Directory

On most Linux systems, /var/log/ is the traditional home for both system-level and application-level log files. A handful of names show up constantly:

File / folderWhat it holds
/var/log/syslogGeneral system activity — the traditional catch-all on Debian/Ubuntu systems
/var/log/messagesThe same kind of general system activity — the equivalent file on RHEL/CentOS-family systems
/var/log/auth.logAuthentication events (logins, sudo usage) — Debian/Ubuntu naming
/var/log/secureThe same authentication events — RHEL/CentOS naming
/var/log/apache2/ or /var/log/httpd/Apache's own access and error logs — folder name depends on distro (Chapter 4 covers the file contents in depth)
/var/log/dmesgKernel ring buffer — hardware and boot-time messages
The same log, two different filenames — a genuinely common source of confusion
Debian/Ubuntu-family distros and RHEL/CentOS-family distros use different conventional filenames for the same underlying log — auth.log vs. secure, syslog vs. messages, apache2 vs. httpd. Following a guide written for the wrong distro family is a real, common way to end up looking for a file that simply doesn't exist on the system in front of you.

The systemd Journal — journalctl

Most modern Linux distributions run systemd as their init system, and systemd includes its own logging component, journald, which stores structured, binary log data rather than plain text files. It's queried with the journalctl command, not a text editor or cat.

# everything in the journal, oldest first journalctl # only logs from one specific service journalctl -u apache2.service # follow live, the same idea as `tail -f` for a plain log file journalctl -f # only entries from the last hour journalctl --since "1 hour ago" # only entries at "err" priority or worse journalctl -p err
journalctl's -p flag uses Chapter 2's own syslog priority names
journalctl -p accepts the exact same syslog severity keywords (and numbers) covered in Chapter 2 — emerg, alert, crit, err, warning, notice, info, debug. Knowing that scale from Chapter 2 means journalctl -p err already makes sense — it's the same "0 through 7, lower is worse" filter applied directly at the command line.

Windows: Event Viewer

Windows takes a genuinely different approach from plain text files: the Windows Event Log service stores structured events, each with an Event ID, a source, and a severity level, browsable through the Event Viewer GUI (eventvwr.msc). The three logs worth knowing first:

LogWhat it holds
ApplicationEvents logged by applications and services running on the system
SystemEvents logged by Windows itself and its own drivers/components
SecurityLogin attempts, permission changes, and other security-relevant events

For a command-line equivalent to browsing Event Viewer's GUI, Get-WinEvent (or the older Get-EventLog) does the same job from PowerShell — see PowerShell Fundamentals and PowerShell Intermediate/Advanced for real depth on scripting against these logs directly.

Application-Specific Log Locations

ApplicationTypical default location
Apache/var/log/apache2/access.log and error.log (or the httpd equivalent)
Nginx/var/log/nginx/access.log and error.log
MySQL/var/log/mysql/error.log by default, but genuinely configurable via my.cnf
Docker containersNot a plain file at all by default — docker logs <container> reads the container's own captured stdout/stderr

When the Log Isn't Where You Expect

Defaults are defaults, not guarantees. When a log file genuinely isn't in its usual location, a few things are worth checking before assuming it doesn't exist at all:

  • The application's own configuration. Most services let you set a custom log path — the config file is the actual source of truth, not the convention
  • The systemd unit file for that service, if it's managed by systemd — StandardOutput/StandardError directives can redirect a service's output somewhere other than the journal entirely
  • Log rotation. The file you're looking for might have already been rotated — renamed to access.log.1, or compressed to access.log.2.gz — Chapter 9 covers exactly how and why this happens

Hands-On Exercises

Exercise 1

A troubleshooting guide written for Ubuntu tells you to check /var/log/auth.log, but the server you're actually working on is CentOS. Explain what's likely going on, and what file you should check instead.

📄 View solution
Exercise 2

Explain what journalctl -p err actually does, and why understanding Chapter 2's syslog severity scale makes this command immediately readable rather than something to memorize separately.

📄 View solution
Exercise 3

You expect to find a service's log at its usual default path, but the file isn't there. Name two genuinely different reasons this could be true, according to this chapter, other than "the log doesn't exist."

📄 View solution

Chapter 3 Quick Reference

  • /var/log/ — the traditional home for Linux system/application logs; exact filenames vary by distro family (Debian/Ubuntu vs. RHEL/CentOS)
  • journalctl — queries systemd's own structured journal; -u filters by service, -f follows live, -p filters by Chapter 2's own syslog severity scale
  • Windows Event Viewer — Application/System/Security logs, structured events with Event IDs; Get-WinEvent is the PowerShell equivalent
  • Applications have their own default log paths, but config files can override them — the default is a convention, not a guarantee
  • A "missing" log might be redirected (via app config or a systemd unit file) or simply rotated to a numbered/compressed filename
  • Next chapter: Reading Web Server Logs: Apache & Nginx