VMware ESXi and vSphere Cluster Management

Understanding the /var/log/messages File in Linux

Learn what /var/log/messages contains, how to read and monitor it, troubleshoot common issues, and use syslog or systemd journal alternatives.

/var/log/messages is a traditional, general-purpose Linux system log. It can contain service activity, hardware notices, network changes, startup and shutdown events, warnings, and system-level errors. It is often a useful first place to investigate an incident, but its exact contents depend on the distribution, logging daemon, and routing configuration.

This lesson explains how to inspect the file safely, understand its fields, use rotated logs, and find equivalent information when the file does not exist.

What Is /var/log/messages?

The path /var/log/messages traditionally identifies a text file maintained by a syslog-compatible logging service. A logging service receives messages from the kernel, system services, applications, and other sources, then classifies and routes them to destinations such as files, a remote log server, or a systemd journal.

The file is general-purpose rather than application-specific. Common entries include:

• Service start, stop, restart, and failure messages
• Hardware detection and driver notices
• Kernel-related warnings and other operating-system events
• Network interface state changes and DHCP lease activity
• Startup, shutdown, reboot, and device events
• Warnings and non-application-specific errors

A message in this file is not automatically a failure. Informational messages may describe normal activity, such as a DHCP lease renewal. Always interpret an entry alongside nearby events, system state, and the symptoms being investigated.

Where Is the General System Log?

The traditional path is /var/log/messages, but Linux distributions do not all use the same destination. Debian- and Ubuntu-based systems commonly use /var/log/syslog for general system messages. Some modern systemd installations store messages primarily in the systemd journal and do not create either flat file unless rsyslog, syslog-ng, or another forwarding service is configured.

Do not assume that a path exists. Check the available files first:

ls -l /var/log/messages /var/log/syslog 2>/dev/null

Listing the surrounding directory can reveal custom names or application-specific logs:

ls -lah /var/log/

How a Traditional Syslog Entry Is Formatted

Traditional log files normally contain one event per text line. A common format includes a timestamp, hostname, program or service name, optional process identifier, and message body.

Aug 19 14:32:10 server1 dhclient[842]: DHCPACK from 192.0.2.1 (xid=0x4a12)

In this example, the DHCP client reports that it received an acknowledgment for a DHCP lease. The event may be routine, not an error.

Formatting varies by syslog implementation, application, distribution, and configuration. Some entries use a different timestamp format, include structured data, or omit fields. A traditional timestamp may not identify the timezone, so confirm the host's timezone and clock when correlating events.

Facility and Severity

A facility is a syslog classification for the source category of a message, such as kern for kernel events or daemon for system daemons. Severity is the priority of the event, ranging from emergency conditions through alert, critical, error, warning, notice, informational, and debug messages.

These classifications are often used by rsyslog or syslog-ng routing rules. A rule can send informational messages from many facilities to one file while excluding authentication or mail messages. Therefore, the absence of an event from /var/log/messages does not prove that the event was never generated.

Reading the File Safely and Effectively

Use a pager rather than opening a log in an editor. A pager lets you navigate and search without accidentally changing the file.

sudo less /var/log/messages

Inside less, use /word to search forward, n to find the next match, and q to quit. Elevated privileges may be required because log files are commonly readable only by root or members of a logging group.

View Recent Entries

sudo tail /var/log/messages
sudo tail -n 50 /var/log/messages

The first command displays the final ten lines by default. The second displays a larger recent sample.

Follow New Entries

sudo tail -F /var/log/messages

-F follows the file and can continue across common rotation events. This is useful while restarting a service, reconnecting a network interface, or reproducing a problem. Press Ctrl+C to stop.

Search and Filter

sudo grep -iE 'dhcp|network|eth0|enp[0-9]s[0-9]+' /var/log/messages

grep searches text, -i ignores letter case, and -E enables an extended pattern. Replace interface names and keywords with values relevant to the host.

For a service-oriented search, combine likely process names and severity-related terms:

sudo grep -iE 'sshd|nginx|failed|error|warning' /var/log/messages

A Practical Troubleshooting Workflow

1. Identify the incident time. Use the user's report, monitoring alert, command history, or service timestamps. Account for timezone differences.
2. Inspect a time window. Read entries immediately before and after the event rather than examining only the alarming line.
3. Correlate the host and process. Confirm that the hostname, service name, PID, interface, and device match the affected system.
4. Look for repetition and priority. Repeated messages often indicate an ongoing fault. Consider whether a warning or error is a cause, consequence, or harmless status update.
5. Compare related sources. Check the systemd unit journal, kernel-related output, authentication logs, network-manager logs, or application-specific logs.
6. Test the suspected cause. Check service state, interface state, addresses, routes, storage health, or other relevant system conditions.

Network and DHCP Events

A DHCP lease is a time-limited network address assignment obtained from a DHCP server. A renewal entry may contain the timestamp, hostname, DHCP client process, PID, interface name, server address, and assigned address.

A renewal is usually normal when it occurs periodically and connectivity remains healthy. It deserves investigation when entries repeat rapidly, are followed by lease failures, or coincide with interface-down events and lost connectivity. Read the surrounding lines and compare them with the interface address and route.

sudo grep -iE 'dhcp|network|link|carrier|enp[0-9]s[0-9]+' /var/log/messages

Failed Services

The general log may show that a service failed, but the service's own journal usually provides more detail, such as configuration errors, dependency failures, or exit status information.

sudo journalctl -u ssh.service --since '1 hour ago'

Replace ssh.service with the relevant systemd unit. Compare the unit's entries with general messages around the failure time.

Storage, Filesystem, Kernel, and Reboot Events

Look for repeated filesystem warnings, device errors, driver notices, kernel reports, and messages indicating shutdown or startup. A single informational device message may be expected during boot; repeated I/O errors or filesystem errors require a broader storage investigation.

syslog, rsyslog, syslog-ng, and systemd-journald

These terms describe different parts of Linux logging:

• syslog is both a traditional logging protocol and a logging model for collecting, classifying, and routing messages.
• rsyslog is a widely used syslog implementation that can receive, filter, write, and forward messages.
• syslog-ng is an alternative syslog implementation with configurable processing and destinations.
• systemd-journald is the systemd component that collects system and service records into the journal.
• journalctl is the command-line tool used to query and follow the systemd journal.

Think of logging as a chain: a source generates an event, a logging service receives it, routing rules classify or filter it, and a destination stores it. The destination might be /var/log/messages, /var/log/syslog, another file, a remote server, or the journal.

On a system using both journald and rsyslog, journald may collect a message first and forward it to rsyslog, which then writes selected events to a flat file. On another system, the event may remain only in the journal. Routing rules determine what appears in each destination.

Inspecting rsyslog Routing

sudo grep -R --line-number '/var/log/messages' /etc/rsyslog.conf /etc/rsyslog.d 2>/dev/null
systemctl status rsyslog

An illustrative routing rule might look like this:

*.info;mail.none;authpriv.none;cron.none    /var/log/messages

This example routes informational-and-higher messages to the file while excluding selected facilities. Actual rules vary by distribution and local policy. Do not copy a rule into production without understanding its facility, severity, exclusions, permissions, and reload requirements.

Log Rotation and Retention

Log rotation prevents a continuously growing file from consuming disk space. A rotation process renames the current file, creates a new one, optionally compresses older files, and eventually removes logs beyond the retention limit.

Typical names include:

• /var/log/messages — current file
• /var/log/messages.1 — most recently rotated uncompressed file
• /var/log/messages.2.gz — an older gzip-compressed file

logrotate is the common Linux utility used to manage rotation frequency, compression, retention count, ownership, permissions, and post-rotation actions.

sudo grep -R --line-number '/var/log/messages' /etc/logrotate.conf /etc/logrotate.d 2>/dev/null

Read an uncompressed historical file normally:

sudo less /var/log/messages.1

Read a compressed file without manually extracting it:

sudo zless /var/log/messages.2.gz
sudo zgrep -i 'error' /var/log/messages*.gz

Retention determines how far back an investigation can go. If an incident is older than the retained files, the local host may no longer contain the evidence.

Using the Systemd Journal

When a flat file is missing or incomplete, query the journal. Show recent records:

sudo journalctl -n 50

Follow new records live:

sudo journalctl -f

Query a particular systemd unit within a defined time window:

sudo journalctl -u ssh.service --since '1 hour ago'

You can also define a start and end time when the incident window is known:

sudo journalctl --since '2026-08-19 13:00:00' --until '2026-08-19 14:00:00'

Service-specific logs are often more useful than the general messages file for focused troubleshooting. Other complementary sources include authentication and security logs, kernel logs, boot logs, package-management logs, and application-specific files. The exact paths vary by distribution and software.

When /var/log/messages Does Not Exist

A missing file is not necessarily a logging failure. Common causes include:

• The distribution uses /var/log/syslog instead.
• The host uses only systemd-journald.
• rsyslog or syslog-ng is not installed, enabled, or configured to create the file.
• A custom policy sends general messages to another file or remote destination.

Use this diagnostic path:

1. Check /var/log/syslog and list /var/log.
2. Run sudo journalctl -n 50 to determine whether recent messages exist in the journal.
3. Check the status of rsyslog or syslog-ng if one is expected.
4. Inspect routing configuration for a destination containing /var/log/messages.
5. Check service-specific logs if the event belongs to an application or systemd unit.

Common Problems and Diagnostic Responses

The File Cannot Be Read

Inspect ownership and permissions:

ls -l /var/log/messages

Use sudo only when authorized. If the path is absent, check alternate flat files and the journal rather than repeatedly changing permissions.

Expected Messages Are Missing

The application may write to its own log, log directly to the journal, or be excluded by a facility or severity filter. The logging service may also be stopped or misconfigured, or rotation may have removed the relevant time period. Search the journal and service-specific logs, review routing rules, check logging-service status, and search rotated files.

The File Is Growing Quickly

Rapid growth commonly indicates a repeatedly failing service, debug logging enabled in production, or broken or overly generous rotation. Follow the file to identify the repeated source, correct the underlying failure, review the service's logging level, and verify logrotate configuration and execution. Deleting the file only hides the symptom and can destroy useful evidence.

A Network Message Looks Alarming

A DHCP renewal or interface transition may be routine. Read entries before and after it, check the address, route, and interface state, and compare the timestamp with reported connectivity symptoms. Repetition combined with lease failures or link loss is more significant than a single status message.

Exam-Relevant Notes

• /var/log/messages is a traditional general system log, not a guaranteed universal path.
• /var/log/syslog is commonly used for general system messages on Debian-derived systems.
• systemd-journald stores records in the journal; use journalctl to query it.
• rsyslog and syslog-ng can route selected messages to files according to facility and severity.
• A traditional syslog timestamp may omit the year and timezone.
• Log rotation creates names such as messages.1 and messages.2.gz.
• A message's presence or absence depends on routing, retention, and the application's logging destination.

Summary

/var/log/messages is a valuable starting point for understanding system activity, especially service, hardware, network, kernel, and boot-related events. First verify which logging destination the host uses. Then inspect the relevant time window with a pager, search for related processes or keywords, follow events during controlled tests, and compare the results with the systemd journal and service-specific logs. Treat the file as one part of a logging system rather than as a complete record of everything that happened.

For related instruction, continue with Linux system log troubleshooting with /var/log/messages.