Linux online course

Common Linux Log Files in /var/log

Learn where Linux system, authentication, kernel, service, package, mail, desktop, print, boot, and scheduled-task logs are stored and how to inspect them safely.

Linux logs record events such as system startup, authentication attempts, hardware detection, service activity, package changes, and application errors. Many traditional text-based logs are stored in /var/log and its subdirectories.

The exact files available depend on the distribution, installed software, logging daemon, and local configuration. A missing file is not automatically a fault: the same event may be stored under another filename or only in the systemd journal.

How Linux logging is organized

A log destination is the place where a logging system stores an event. Traditional syslog-based systems classify messages by a facility, which describes the source category, and a severity, which describes importance.

• Facility: a category such as auth, cron, daemon, kern, mail, or user.
• Severity: a priority ranging from emergency and alert through critical, error, warning, notice, informational, and debug.

rsyslog and syslog-ng are syslog implementations that can route messages to files, remote hosts, or other destinations. systemd-journald collects structured entries that are queried with journalctl.

Logs can be:

• Persistent: stored on disk, commonly below /var/log, and retained across reboots.
• Volatile: stored in memory or a temporary filesystem, so entries can disappear after shutdown or reboot.
• Journal-based: stored and queried by systemd-journald. A journal may be persistent or volatile depending on its configuration.

A system can use journald alone, a traditional syslog daemon alone, or both. When both are active, journald may forward selected entries to rsyslog or syslog-ng, which then writes selected messages to files. Routing rules determine which message reaches which destination.

Common Linux log files and directories

Distribution-specific names

System-wide and kernel messages

/var/log/messages and /var/log/syslog

/var/log/messages is a broad system-message file commonly found on Red Hat-family systems. Depending on rsyslog or syslog-ng rules, it may contain messages from the kernel, services, and daemons. Debian-family systems commonly use /var/log/syslog for a similar purpose.

These files are useful when you know that something happened but do not yet know which service produced it. Search around the event time and look for repeated warnings or errors rather than treating one isolated message as the entire diagnosis.

/var/log/kern.log, dmesg, and journalctl -k

/var/log/kern.log is a file destination for kernel messages when the system is configured to write one. Kernel messages help diagnose device discovery, module loading, driver failures, disk or filesystem errors, and hardware problems during boot.

sudo less /var/log/kern.log
dmesg | less
journalctl -k

dmesg views the kernel message buffer, while journalctl -k queries kernel entries collected by journald. They may not contain exactly the same history or formatting as a persistent file.

Authentication and authorization logs

On Debian-family systems, /var/log/auth.log commonly records login activity, SSH connections, PAM decisions, sudo authorization, and account-related events. On Red Hat-family systems, the comparable file is commonly /var/log/secure.

sudo grep -Ei "failed|failure|invalid|accepted|sudo" /var/log/auth.log
sudo grep -Ei "failed|failure|invalid|accepted|sudo" /var/log/secure
journalctl -u sshd

Successful and failed authentication entries answer different questions. A failed password attempt may show the account and source address; a later successful login from the same address may be important in a security investigation. Interpret entries with their timestamps, source addresses, account names, and related configuration changes.

These logs can contain usernames, IP addresses, command activity, and other sensitive information. Read and share them using least-privilege practices.

Scheduled-task logs

cron is a time-based scheduler for recurring commands. /var/log/cron is a common record of cron daemon activity on some distributions, but cron messages may instead be routed to /var/log/syslog, /var/log/messages, or the systemd journal.

sudo grep -i cron /var/log/cron
sudo grep -i cron /var/log/syslog
journalctl -u cron

A scheduler entry proves that cron attempted to invoke a job; it does not prove that the command completed successfully. Also inspect the job's own redirected standard output and error output.

15 2 * * * /usr/local/bin/backup.sh >>/var/log/backup.log 2>&1

When diagnosing a failed task, check the user running it, its limited environment and PATH, permissions, credentials, network dependencies, and the destination of its output.

Boot logs and service logs

Boot diagnostics

/var/log/boot.log may contain boot-time service messages, but it is often incomplete on modern systemd systems. Use the journal for the complete view of a boot:

journalctl -b
journalctl -b -p warning
journalctl -u SERVICE_NAME

Boot records help connect hardware initialization and service startup failures to a particular boot. If the current boot is not the one of interest, inspect retained previous boots with journalctl --list-boots.

Daemon and application destinations

A daemon is a background service process. /var/log/daemon.log may receive messages categorized with the daemon facility, but a service can instead have a dedicated application file, write to another facility, or retain messages only in journald.

The relationship is:

1. A daemon runs under a process and often under a systemd unit name.
2. The daemon or its service manager emits log messages.
3. journald, rsyslog, or syslog-ng receives and classifies them.
4. Routing configuration sends them to a file, the journal, a remote collector, or several destinations.

systemctl status SERVICE_NAME
journalctl -u SERVICE_NAME
sudo find /var/log -maxdepth 2 -type f | sort

/var/log/user.log, where present, is a destination for messages using the user syslog facility. It does not necessarily contain every action performed by every local user.

Package-management logs

On Debian-derived systems, /var/log/dpkg.log records low-level package installation, removal, upgrade, and configuration activity. On older or Red Hat-family systems, /var/log/yum.log may record YUM activity. DNF is the modern replacement for YUM on many systems, and its log location and history mechanisms can differ.

sudo less /var/log/dpkg.log
sudo less /var/log/yum.log
sudo find /var/log -iname '*dnf*' -o -iname '*yum*'

Compare package timestamps with the first occurrence of a service failure. This often identifies a package update, configuration change, or dependency change that preceded a regression.

Display, printing, and mail logs

Graphical display logs

/var/log/Xorg.0.log and numbered files matching /var/log/Xorg.X.log are X.Org display-server logs where file logging is configured. They can reveal GPU-driver problems, monitor detection failures, display initialization errors, and input-device issues.

Wayland sessions, display managers, and newer systemd configurations may use different files or the journal, so an absent Xorg log is normal on a Wayland-only system.

CUPS printing logs

CUPS means Common Unix Printing System. Its logs are commonly stored in /var/log/cups/. Check them for jobs that remain queued, printer connectivity problems, access requests, permission errors, and driver or filter failures.

sudo ls -lah /var/log/cups/
sudo grep -RniE "error|failed|denied|filter" /var/log/cups/

Mail logs

/var/log/maillog and /var/log/mail.log are common paths for mail-transfer-agent logs. An MTA, such as Postfix or Sendmail, transfers mail between systems. The actual contents depend on the installed MTA and its configuration.

Mail logs can trace message submission, delivery, rejection, relay decisions, retries, and queue activity. Search using a message identifier, sender, recipient, or timestamp.

Reading and filtering logs safely

Start by listing what actually exists:

ls -lah /var/log
sudo find /var/log -maxdepth 2 -type f | sort

Use less for interactive reading, tail for recent entries, and tail -F to follow a file across rotation or replacement:

sudo less /var/log/messages
sudo tail -n 100 /var/log/auth.log
sudo tail -F /var/log/messages

Search without changing the source file:

sudo grep -i "failed" /var/log/auth.log
sudo grep -Ei "error|fail|denied" /var/log/messages
sudo awk '/2026-08-17/ {print}' /var/log/syslog

Traditional logs may begin with a month, day, and time rather than a year. For reliable date-aware filtering, identify the file's timestamp format first, account for year boundaries, and prefer journal filters when possible:

journalctl --since "2026-08-17 00:00:00" --until "2026-08-18 00:00:00"
journalctl -u sshd --since today

Read each line as structured evidence. Look for the timestamp, hostname, process or service name, process ID when present, severity, message, and recurring pattern. Correlate related entries instead of relying on a single line.

Log rotation

logrotate rotates, compresses, retains, and removes old log files according to policy. Rotation prevents uncontrolled disk usage while preserving recent history.

Policies are commonly defined in /etc/logrotate.conf and individual files under /etc/logrotate.d/. A policy can specify daily, weekly, or monthly rotation, a retention count, compression, and a post-rotation action such as signaling or reopening a service's log.

sudo cat /etc/logrotate.conf
sudo ls -lah /etc/logrotate.d
sudo logrotate -d /etc/logrotate.conf

For example, an active /var/log/messages may become /var/log/messages.1, then older numbered files. Other policies use date suffixes. Older files may be compressed:

zless /var/log/messages.1.gz
zgrep -i "error" /var/log/messages*.gz

A forced rotation is disruptive to filenames, retention state, and sometimes service behavior. Use it only in a controlled environment when you understand the policy:

sudo logrotate -f /etc/logrotate.conf

Verifying logging services and rules

When a file is absent, first determine which collection system is active:

systemctl status rsyslog
systemctl status systemd-journald
systemctl status syslog-ng

Then inspect /var/log, query the journal, and review the relevant rsyslog or syslog-ng routing configuration. A missing expected file can result from a different distribution convention, an uninstalled service, no events yet, journal-only retention, or a changed routing rule.

Do not assume that every message is written to every file. Facility, severity, service configuration, forwarding rules, and rotation policy all affect what is available.

Practical troubleshooting workflows

Repeated SSH login failures

1. Open /var/log/auth.log on Debian-family systems or /var/log/secure on Red Hat-family systems.
2. Search for failed and accepted entries, recording timestamps, accounts, and source addresses.
3. Query the SSH service journal with journalctl -u sshd when file logs are absent.
4. Correlate a successful follow-up login with earlier failures and configuration changes.

Hardware or driver failure after startup

1. Check /var/log/kern.log if present.
2. Compare journalctl -k and dmesg for device, module, driver, and I/O messages.
3. Search around the boot time and identify repeated errors rather than harmless detection notices.

Cron task did not produce its result

1. Check /var/log/cron, /var/log/syslog, /var/log/messages, or the journal for scheduler invocation.
2. Inspect the command's redirected stdout and stderr or local mail output.
3. Run the command as the same user with a minimal environment and verify permissions, paths, credentials, and dependencies.

Package update preceded a service failure

1. Inspect /var/log/dpkg.log, /var/log/yum.log, or applicable DNF logs.
2. Record the installation or upgrade time.
3. Compare it with the service's first error in its file or journal.

Print job remains queued

1. Inspect /var/log/cups/.
2. Search for job-processing, connectivity, permission, driver, and filter errors.
3. Compare the CUPS timestamp with queue status and the printer service journal.

Boot failure is missing from boot.log

1. Use journalctl -b for the current boot.
2. Use journalctl -u SERVICE_NAME for the failing unit.
3. Check application-specific logs because boot.log may contain only a subset of startup messages.
4. Compare with a previous retained boot when useful.

Logs consume disk space

1. Measure large files and directories under /var/log.
2. Review logrotate policies and retention counts.
3. Search recent logs for an application producing repeated errors.
4. Check journal disk usage and retention configuration as well as file-based logs.

Exam-relevant notes

• /var/log/messages is commonly associated with broad system messages on Red Hat-family systems; /var/log/syslog is a common Debian-family counterpart.
• /var/log/auth.log and /var/log/secure are distribution-family alternatives for authentication and privilege events.
• journalctl -b is often more complete than /var/log/boot.log on systemd systems.
• journalctl -k and dmesg are important kernel-log inspection tools.
• A cron invocation entry does not prove that the scheduled command succeeded.
• dpkg.log records Debian-family low-level package activity; YUM is older, while DNF is common on modern Red Hat-family systems.
• Log filenames are consequences of configuration, not universal guarantees.
• Rotation limits disk use and commonly creates numbered or compressed historical files.