VMware ESXi and vSphere Cluster Management

Common Linux Log Files in /var/log

Learn where common Linux logs are stored, how to inspect systemd journals and rotated files, and how logrotate preserves logs safely.

Linux logs record activity from the kernel, services, authentication systems, package managers, scheduled tasks, and applications. Traditional text-based logs are commonly stored in /var/log and its subdirectories, but the exact files available depend on the distribution, installed software, logging configuration, and whether the system uses a file-based logger, the systemd journal, or centralized logging.

This guide covers common paths, safe inspection commands, log interpretation, and rotation. For an overview you can bookmark, see Common Log Files.

Linux logging overview

/var/log is the conventional location for persistent log files. A logging daemon such as rsyslog or syslog-ng may receive messages from applications and the kernel, then route them to files, remote hosts, or other destinations. The word syslog describes both a traditional logging model and, on some systems, a general-purpose log file.

Systems using systemd also commonly use the systemd journal, a structured log store queried with journalctl. The journal may be persistent under a journal directory, volatile in memory, or configured alongside traditional files. It may or may not be stored under /var/log.

• Debian-family systems often provide files such as /var/log/syslog and /var/log/auth.log.
• RPM-family systems often provide /var/log/messages and /var/log/secure.
• A service may write to its own file, a directory, syslog, the journal, or a centralized logging platform.
• Containers, cloud agents, and remote logging can place events outside the local host's expected files.

Access and permissions

Logs often contain usernames, source IP addresses, commands, mail content, file paths, and other security-sensitive information. Many are readable only by root or a privileged group. Use sudo for read-only inspection when appropriate:

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

Do not manually edit, delete, or truncate an active log as routine maintenance. A daemon may keep an open file descriptor, and manual changes can break auditing, interfere with rotation, or remove evidence needed for investigation. Use the logging service's configuration and retention mechanisms instead.

Common Linux log files and directories

Distribution and logging-stack differences

Authentication and security logs

An authentication log records login, authorization, SSH, PAM, and privilege-escalation events. PAM, or Pluggable Authentication Modules, supplies authentication and account-policy components used by many Linux services. sudo commonly records authorization decisions and commands.

To investigate repeated SSH failures, search for terms such as failed, invalid user, authentication failure, or sudo. Look for the account name, timestamp, source address, and result. Treat these files as confidential.

sudo grep -i "failed\|invalid user\|sudo" /var/log/auth.log
sudo grep -i "failed\|invalid user\|sudo" /var/log/secure
sudo journalctl --since "today" | grep -i "ssh\|sudo\|authentication"

Service, daemon, and scheduled-task logs

A daemon is a background service process. Its messages may go to /var/log/daemon.log, a service-specific directory, syslog, or the journal. A cron scheduler records that it invoked a task, but that record does not establish that the command completed successfully. Check redirected output, application logs, permissions, paths, and environment variables when a job fails.

sudo grep -i "cron" /var/log/syslog
sudo less /var/log/cron
sudo journalctl -u cron --since "today"

Package-management logs

dpkg is the low-level Debian package tool, and /var/log/dpkg.log records installation, removal, upgrade, and configuration actions performed through dpkg-based tools. Older or compatible RPM systems may record Yum transactions in /var/log/yum.log. On many newer RPM systems, DNF is the modern package manager.

sudo less /var/log/dpkg.log
sudo less /var/log/yum.log
sudo dnf history

Package records are valuable when a service begins failing after a library, kernel, driver, or configuration package changed. Compare the transaction time with service and kernel events.

User-session and graphical logs

/var/log/user.log may receive messages assigned to the user facility. X.Org display-server diagnostics commonly appear in /var/log/Xorg.0.log or similarly named files. These logs can show graphical startup failures, display-driver problems, input-device detection issues, and screen or display-server errors. Modern desktop environments may store related events elsewhere or in the journal.

Printing and mail logs

CUPS, the Common UNIX Printing System, commonly stores service and job information under /var/log/cups/. Inspect these files for queue, connectivity, permission, driver, and printer-state errors.

Mail services commonly use /var/log/maillog or /var/log/mail.log. The content depends on the MTA, or Mail Transfer Agent, such as Postfix, Sendmail, or Exim, and on the system's logging rules. Mail logs can contain addresses, message identifiers, and delivery details, so protect them appropriately.

Reading and interpreting log entries

A traditional syslog line often contains a timestamp, hostname, process name, optional process ID, severity or facility information, and the event message. A simplified example is:

Aug 18 10:42:07 host1 sshd[1842]: Failed password for user1 from 203.0.113.10

• Timestamp: when the event was recorded; verify timezone and clock accuracy.
• Hostname: the system that reported the event, especially important with remote logs.
• Process and PID: the service and process that emitted the message.
• Severity: labels such as warning, error, or alert indicate urgency, but message wording still requires context.
• Event message: the operation, result, object, account, address, or error detail.

Correlate timestamps across several sources. For example, a package upgrade may precede a service failure, which may precede a kernel or authentication symptom. Search for service names, errors, failed authentication terms, and a narrow time range rather than reading unrelated entries.

Viewing and monitoring logs

sudo journalctl -p warning..alert
sudo journalctl -u cron --since "today"
sudo journalctl -b

Use a live view while reproducing the issue, then record the relevant time, service, and related messages. For a journal-only service, use journalctl rather than waiting for a file under /var/log.

Log rotation and retention

Rotation renames an active log and creates a new one. It prevents a busy log from exhausting the filesystem while retaining historical copies for a defined retention period or count. logrotate is the standard utility for rotating, compressing, retaining, and removing old files.

The main configuration is commonly /etc/logrotate.conf, with per-service snippets in /etc/logrotate.d/. Names may use numeric suffixes such as .1 and .2.gz, or date-based suffixes, depending on policy.

Example policy for /var/log/messages

The following is illustrative and applies only where /var/log/messages exists and rsyslog manages it:

/var/log/messages {
    weekly
    rotate 4
    compress
    missingok
    notifempty
    create 0640 root adm
    sharedscripts
    postrotate
        systemctl reload rsyslog 2>/dev/null || true
    endscript
}

Do not add a duplicate rule if an existing distribution-provided policy already manages the file. Ownership, group, mode, daemon name, and reload behavior must match the local system. Inspect and test configuration before forcing rotation:

sudo less /etc/logrotate.conf
sudo ls -lah /etc/logrotate.d
sudo logrotate -d /etc/logrotate.conf
sudo logrotate -f /etc/logrotate.conf

The -d option performs a dry run. Forced rotation with -f should have a defined operational reason because it changes files and may trigger service reloads.

Operational cautions and disk usage

• Check capacity and retention before logs fill a filesystem: df -h /var.
• Find large log locations with sudo du -sh /var/log/* 2>/dev/null | sort -h.
• Fix high-volume errors or debug logging at the source instead of only deleting evidence.
• Review both logrotate policies and journal retention when disk usage grows.
• Treat authentication, mail, and application logs as potentially confidential.
• Account for centralized logging, containers, cloud logging agents, and journal-only configurations.

Troubleshooting common problems

The expected file does not exist

List /var/log, check the distribution's naming convention, and query the journal. The service may not be installed, may log to a separate directory, or may forward events remotely. Review rsyslog, syslog-ng, application, or service configuration rather than creating an empty file and assuming it will be used.

Permission is denied

Use sudo for read-only inspection and review ownership and permissions before changing access controls. Broadening access to security logs can expose sensitive information.

A cron task started but did not finish

Cron records invocation, not successful completion. Check the command's own output and logs, redirected output, executable paths, environment variables, permissions, and the difference between a cron environment and an interactive shell.

Disk space is exhausted by logs

Measure /var/log, identify the largest files, inspect logrotate dry-run output, and review journal usage and retention. Correct the source of excessive messages and repair failed rotation rather than routinely truncating files.

New entries stop after rotation

The producing daemon may still hold the old file descriptor, the post-rotation reload may be missing, or the recreated file may have incorrect ownership, mode, or security labels. Check the logrotate rule, service status, journal output, and newly created file permissions.

An SSH or sudo event is missing

Search the journal, rotated and compressed files, alternate facility paths, and any remote logging destination. Retention may have expired, or the service may use a different unit or logging rule.

Practical investigation patterns

Repeated failed SSH logins

1. Identify whether the host uses auth.log, secure, or the journal.
2. Search for failed authentication and invalid-user messages.
3. Record timestamps, account names, source addresses, and the result.
4. Correlate with firewall, SSH service, and remote logging records.

Kernel or hardware failure after boot

Compare /var/log/kern.log, /var/log/messages, /var/log/boot.log, and journalctl -k -b. Look for storage, network, driver, firmware, or hardware initialization failures around the same time.

Recent package change

Search /var/log/dpkg.log, /var/log/yum.log, or DNF history for the transaction time and changed packages. Then correlate that change with service startup and kernel messages.

Failed print job

Inspect files under /var/log/cups/ for queue, connectivity, driver, permission, and printer-state errors. Match the job time with the CUPS service events.

Live service fault

Run tail -F on the relevant file or use journalctl -u service-name, reproduce the issue, and stop monitoring after collecting the relevant timestamps. This avoids confusing old entries with new symptoms.