When something goes wrong on a server or workstation, log files can be your first stop. This article covers the key log locations on modern Linux distributions (Ubuntu 22.04/24.04, AlmaLinux/Rocky Linux 9), log analysis via systemd's journal, and the Windows Event Viewer.

Note on end-of-life distros: Debian 8 reached end of life in 2018. CentOS 7 reached end of life in June 2024. If you're still running either, plan a migration. The paths below apply to their modern successors.

1. Linux log file locations
2. Log analysis via systemd journal
3. Log analysis via Windows Event Viewer

Linux log file locations

On all major distributions, the primary log directory is /var/log/. Global syslog configuration lives in /etc/rsyslog.conf (or drop-in files under /etc/rsyslog.d/). The exact filenames differ between Debian-based and Red Hat-based systems.

Debian / Ubuntu (Ubuntu 22.04 / 24.04)

/var/log/auth.log Records successful and failed authentication attempts, including SSH logins and sudo invocations.

/var/log/syslog The central system log. Processes that implement the syslog interface write here. Also captures system startup and cron job execution — one of the most useful files for general troubleshooting.

/var/log/kern.log Kernel messages only: hardware errors, driver warnings, and OOM events. You can also query it with journalctl -k.

dmesg (or /var/log/dmesg) Reads the kernel ring buffer directly. Useful for diagnosing hardware issues, boot problems, and USB/storage events. Run dmesg --human for human-readable timestamps.

RHEL / AlmaLinux / Rocky Linux (v9)

/var/log/secure Equivalent to /var/log/auth.log on Debian systems. All authentication events, SSH sessions, and PAM output are logged here.

/var/log/messages General-purpose system log combining the roles of both syslog and messages on Debian. Process messages, startup events, and cron jobs all land here.

/var/log/cron Cron-specific log, separate from the main messages file. Check here first if a scheduled task is not running as expected.

Application logs: Web servers, databases, and other services typically write to their own subdirectory under /var/log/ — for example, /var/log/nginx/ or /var/log/mysql/. Check the application's configuration file if a log directory isn't where you expect it.

Log analysis via systemd journal

Systemd is the init system on all major Linux distributions and ships its own logging layer: the Journal. On modern systems (RHEL 8+, Ubuntu 22.04+), journald and the traditional /var/log/ flat files run side by side. As a rule of thumb, use journalctl for systemd-managed services and /var/log/ for applications that write their own log files.

Every process managed by systemd is a unit. List all active units with:

systemctl list-units

Add --all to include inactive units.

Basic journal queries

# All logs for a specific service journalctl -u nginx 
# Logs between two timestamps journalctl -u nginx --since "2025-06-01 08:00:00" --until "2025-06-01 10:00:00" 
# Relative time shortcuts journalctl -u nginx --since yesterday 
# Multiple services at once journalctl -u nginx -u php-fpm --since yesterday 
# Follow new entries in real time journalctl -u nginx -f 
# Kernel messages only journalctl -k 
# Last 50 lines journalctl -u nginx -n 50

Structured output

For scripting or ingestion into a log management tool:

journalctl -u nginx -o json-pretty

Persistent journal storage: By default, the journal may only be stored in memory and lost on reboot. To enable persistence, run: sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald

For the full reference, run man journalctl.

Log analysis via Windows Event Viewer

Open Event Viewer by pressing Win + R, typing eventvwr.msc, and pressing Enter - or search for "Event Viewer" in the Start menu.

Windows Logs

Under Windows Logs in the left-hand navigation:

Application Events logged by installed applications. Start here when diagnosing crashes, service failures, or errors from third-party software.

Security Records successful and failed login attempts, account changes, policy modifications, and privilege escalations. Requires administrator access to view.

System OS-internal events - driver failures, service starts/stops, disk errors, and hardware issues. The first place to look for OS-level problems.

Setup Events recorded during Windows installation and updates. Useful for diagnosing failed Windows Update installations.

Other useful locations

Filtering and searching

Use Filter Current Log (right-hand panel) to narrow by event level (Critical, Error, Warning, Information), date/time range, or Event ID.

For command-line access, use Get-WinEvent in PowerShell:

# Last 20 errors from the System log Get-WinEvent -LogName System -MaxEvents 20 | Where-Object { $_.Level -eq 2 } 
# Filter by Event ID (4625 = failed logon) Get-WinEvent -LogName Security | Where-Object { $_.Id -eq 4625 }

Windows Update logs: Since Windows 10 / Server 2016, update logs are written as binary ETW trace files in %windir%\Logs\WindowsUpdate\. To convert them to a readable format, run Get-WindowsUpdateLog in an elevated PowerShell session.