Linux online course

Understanding /var/log/messages in Linux

Learn what /var/log/messages contains, how to read and monitor it, how it differs from /var/log/syslog and the systemd journal, and how to use it for troubleshooting.

/var/log/messages is a general-purpose system log found on many Linux systems that use traditional syslog-style logging. It can contain messages from services, the kernel, hardware, networking components, and other parts of the operating system.

It is not a universal or complete record of every event. The logging daemon, distribution, configuration rules, installed services, and incident itself determine which log is most useful. Depending on the system, the relevant information may instead be in /var/log/syslog, the systemd journal, a service-specific log, or a security log.

What /var/log/messages contains

On traditional syslog-based distributions, a syslog daemon receives messages and routes them to destinations according to configuration rules. One destination may be /var/log/messages.

Common event types include:

• Service and daemon startup, shutdown, and status messages
• Kernel-related notices and warnings
• Boot and shutdown activity
• Hardware detection and device events
• Network interface changes, link events, and DHCP activity
• Authentication-adjacent system notices, such as a service rejecting or accepting a connection
• Errors, warnings, and other diagnostic messages

The exact contents are controlled by the logging configuration. A distribution may use rsyslog, syslog-ng, systemd-journald, or a combination of these. A service may also write to its own log or only to the journal.

Use the log that matches the incident. For example, a kernel hardware problem may require the journal or dmesg, an SSH problem may be clearer in the SSH service journal, and an application failure may be recorded only by that application.

Which systems have this file?

/var/log/messages is common on RHEL-family, Fedora-family, SUSE-family, and other systems configured to write general syslog messages to that filename. Debian- and Ubuntu-style systems commonly use /var/log/syslog for a comparable general-purpose text log.

Some modern installations rely primarily on systemd-journald. They may not create either text file by default. Always check before trying to read a path:

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

Where to find general system logs on common Linux families

Linux family or setup: RHEL, Fedora, SUSE, or syslog-configured system
Typical location: /var/log/messages
Primary viewing method: less, tail, or grep
Caveat: The configured rules may exclude some facilities or priorities.

Linux family or setup: Debian or Ubuntu with traditional text logging
Typical location: /var/log/syslog
Primary viewing method: less, tail, or grep
Caveat: Do not assume that /var/log/messages exists.

Linux family or setup: systemd-journald-centered installation
Typical location: Journal storage, queried with journalctl
Primary viewing method: journalctl
Caveat: A text file may not exist or may contain only forwarded messages.

Reading the log safely

When maintained by a syslog daemon, the file is normally plain text. It can become large, so use a pager rather than opening it in an editor or printing the whole file to the terminal.

sudo less /var/log/messages

Inside less, use the arrow keys or Page Up and Page Down to navigate, /term to search, and q to quit. Elevated privileges may be required because log files often have restricted ownership and permissions. Use sudo only when authorized; do not weaken permissions globally just to make logs easier to read.

To inspect recent entries:

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

To monitor new entries while reproducing a problem:

sudo tail -F /var/log/messages

-F follows the filename and is generally better than plain -f when log rotation can rename the current file and create a replacement. Behavior still depends on the rotation method and the tool. If messages do not appear, compare the text file with journalctl -f.

Search case-insensitively for several terms:

sudo grep -i 'dhcp\|network\|error' /var/log/messages

For more practice with text searching, see searching for text with grep.

Anatomy of a traditional syslog entry

A traditional entry often resembles this fictional example:

Aug 18 14:22:07 host-a dhclient[842]: eth0: DHCPREQUEST for 192.0.2.42

Field: Timestamp
Example: Aug 18 14:22:07
Meaning: The date and time associated with the event.
Always present: Usually, but formatting varies.

Field: Hostname
Example: host-a
Meaning: The machine that generated or forwarded the message.
Always present: Common in traditional syslog records.

Field: Program or service name
Example: dhclient
Meaning: The program that emitted the message.
Always present: Common, but application formatting differs.

Field: Process identifier
Example: 842
Meaning: The PID of the emitting process.
Always present: No; it may be absent.

Field: Message body
Example: eth0: DHCPREQUEST for 192.0.2.42
Meaning: The event-specific details.
Always present: The content and format depend on the application.

Traditional timestamps may omit the year and timezone. A PID may be missing, and applications may place their own structured fields in the message body. The program name and PID help identify the source process. The hostname becomes especially valuable when messages are forwarded from several machines into one central log.

Example: interpreting a DHCP client event

In the example, dhclient is the DHCP client, 842 is its process ID, and eth0 is the network interface. A DHCP lease is a temporary address assignment from a DHCP server. A request or renewal message indicates that the client is maintaining or attempting to maintain that assignment.

A lease renewal is often normal network maintenance, not automatically an error. To decide whether it is a problem, inspect nearby entries and the service context. Look for an acknowledgment, an address change, repeated retries, timeouts, link-down events, or a later failure. Informational messages, warnings, and failures must be interpreted together rather than by one alarming-looking word.

A practical troubleshooting workflow

1. Identify approximately when the problem occurred. Record the local time, timezone, host, and affected service or interface.
2. Inspect entries immediately before and after that time. The initiating event may precede the visible symptom.
3. Search for the affected service, device, interface name, username, error text, or relevant keyword.
4. Correlate the result with the journal, a service-specific log, kernel messages, authentication logs, or logs from another host.
5. Verify the current state instead of assuming that a log message describes the present condition. For example, check a service with systemctl status or inspect a network interface with the appropriate network command.
6. Preserve the timestamp and a small surrounding context when escalating the issue. Redact sensitive values before sharing it.

Observed message pattern: Service start failure or repeated restart
Possible interpretation: The daemon may have invalid configuration, missing dependencies, or a permission problem.
Next check: Inspect the unit journal and current service state.
Related log or command: journalctl -u service-name, systemctl status service-name

Observed message pattern: Interface link changes or DHCP retries
Possible interpretation: Network connectivity, cable, driver, access point, or DHCP-server issue.
Next check: Correlate interface, DHCP, and kernel events.
Related log or command: journalctl -f, network status commands, service-specific network logs

Observed message pattern: Hardware or driver warnings
Possible interpretation: A device, firmware, bus, or kernel driver may be reporting a fault.
Next check: Inspect surrounding kernel messages and hardware state.
Related log or command: journalctl -k, dmesg

Observed message pattern: Messages stop around an unexpected restart
Possible interpretation: The system may have lost power, crashed, rebooted, or failed to persist logs.
Next check: Compare boot records and previous-boot journal entries.
Related log or command: journalctl --list-boots, journalctl -b -1

A log entry is evidence, not automatically the root cause. A service may report the symptom of a lower-level network, storage, permission, or dependency problem. Correlation across sources and verification of the current state are essential.

/var/log/messages and the systemd journal

systemd-journald collects structured journal records from the kernel, services, standard output, and other sources on many modern Linux systems. The records can contain metadata that is not visible in a traditional text line, such as the systemd unit, boot identifier, priority, and process information.

rsyslog or syslog-ng may receive selected messages from syslog sources or the journal, filter them by facility and priority, and write them to files such as /var/log/messages or /var/log/syslog. Consequently, the text file may be a subset of the journal, and the journal may be the better source when the file is missing or incomplete.

sudo journalctl -n 50
sudo journalctl -f
sudo journalctl -b
sudo journalctl -b -1
sudo journalctl -u sshd --since '1 hour ago'

These commands show recent records, follow new records, display the current boot, display the previous boot, and filter by a systemd unit and time range. Journal queries can also filter by boot, unit, priority, and time. If the expected text log does not exist, start with journalctl rather than creating a new file manually.

Goal: Read a text log with paging
Command: sudo less /var/log/messages
What it does: Opens the file without dumping it all to the terminal.
Use journalctl instead when: The file is absent or the event is likely journal-only.

Goal: View recent text entries
Command: sudo tail -n 50 /var/log/messages
What it does: Shows the latest 50 lines.
Use journalctl instead when: You need boot, unit, priority, or time filtering.

Goal: Follow a text log live
Command: sudo tail -F /var/log/messages
What it does: Watches the named file across common rotations.
Use journalctl instead when: The system writes primarily to journald.

Goal: Search a text log
Command: sudo grep -i 'error' /var/log/messages
What it does: Finds matching lines.
Use journalctl instead when: You need structured filters or unit-specific results.

Log rotation and retention

Logs are rotated to prevent uncontrolled disk usage. A rotation policy may rename the active file, create a new file, compress older files, and remove data after a defined retention period.

Common names include:

• messages.1 for a recent uncompressed rotated file
• messages-20260818 for a date-based rotated file
• messages.2.gz for an older compressed file

sudo ls -lh /var/log/messages*
sudo zless /var/log/messages.2.gz

zless lets you inspect a gzip-compressed log without manually extracting it. Retention periods, rotation frequency, compression, and file naming are controlled by the administrator and distribution configuration. Older evidence may therefore no longer be available.

Logging configuration

rsyslog is a widely used syslog implementation that receives, filters, stores, and forwards messages. syslog-ng is an alternative implementation with similar collection and routing responsibilities. Both commonly use syslog facilities and priorities.

A facility identifies the source category, such as kernel, mail, or daemon. A priority identifies severity, ranging from emergency through debug. Configuration rules combine these properties with destinations. A rule might route selected daemon and kernel messages to /var/log/messages, while sending authentication-related messages elsewhere.

Common rsyslog locations include /etc/rsyslog.conf and files under /etc/rsyslog.d/. Inspect rules that reference the file with:

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

Paths for syslog-ng and other logging services vary by distribution. Log rotation rules are commonly found in /etc/logrotate.conf and /etc/logrotate.d/:

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

Security and operational considerations

Logs may contain hostnames, IP addresses, service names, usernames, interface names, and other operational details. Limit access according to local policy. Before sharing an excerpt, redact addresses, usernames, tokens, internal hostnames, and other sensitive values while retaining useful timestamps and message context.

If expected messages stop appearing, check:

• Available disk space and inode availability
• Filesystem errors or a read-only filesystem
• The status and health of rsyslog, syslog-ng, or journald
• Whether the service writes to a different log or only to the journal
• Whether rotation changed the active filename
• Whether the journal is persistent or only stored in volatile memory

Accurate clocks matter when correlating events between systems. Verify time synchronization and timezone assumptions; a clock adjustment can make an event appear earlier or later than expected. See Network Time Protocol and NTP for related timekeeping concepts.

Common problems and diagnostic paths

/var/log/messages does not exist

• Check whether /var/log/syslog exists.
• Query recent entries with sudo journalctl -n 50.
• Check the status of the installed logging service.
• Review configuration before creating or altering a destination.

New events are not appearing

• Compare sudo tail -F /var/log/messages with sudo journalctl -f.
• Check logging service status and disk space.
• Review rotation activity and confirm that you are following the active filename.
• Check whether the relevant service uses its own log.

An error line has no clear cause

• Inspect a time window before and after the line.
• Filter by the program name and PID when available.
• Check the associated systemd unit and service-specific logs.
• Correlate with kernel, network, authentication, or application events.

Expected entries are missing after a reboot

• Use journalctl --list-boots and query the relevant boot.
• Inspect rotated files such as messages.1 and compressed archives.
• Check whether the journal was persistent or volatile.
• Account for clock changes and time synchronization.

Reading the log returns permission denied

• Inspect file permissions and ownership.
• Use sudo where authorized.
• Check distribution-specific journal-reading groups and mandatory access policies.
• Do not weaken log permissions globally as a shortcut.

Exam-relevant notes

• /var/log/messages is a general text log on many traditional syslog configurations, not a guaranteed path on every Linux distribution.
• Debian and Ubuntu commonly use /var/log/syslog for comparable general system messages.
• journalctl is the primary query tool for systemd journal records.
• tail -F is useful for following a text log through common rotations.
• Facilities classify message sources; priorities classify severity.
• Log rotation controls disk use and retention, so historical evidence may be compressed or deleted.
• A single log line is evidence that must be correlated with surrounding events, service state, and other logs.

For broader Linux administration topics, return to the Linux topic index. Related skills include determining file types, managing file ownership, and understanding UID and GID permissions.