Table of Contents
Location and Purpose of `/var/log`
On a traditional Linux system, most system and application logs are stored as plain text files under the directory /var/log. The /var part indicates "variable" data, which can grow and change frequently, and log is specifically for logging information.
Log files in /var/log record what the system and its services are doing over time. They are essential when you need to investigate problems, check security events, or simply understand how your system behaves.
Logs in /var/log are one of your primary tools for troubleshooting and security investigations on a Linux system.
The directory is usually readable only by the root user or specific system groups, because logs can contain sensitive information such as IP addresses, usernames, or even parts of configuration data.
Structure of the `/var/log` Directory
Although exact contents vary by distribution and by which services are installed, some common patterns appear in /var/log.
Most distributions keep a set of core system logs directly inside /var/log, such as syslog or messages, authentication logs, kernel logs, and boot logs. In addition to these, many services have their own subdirectories. For example, web servers often log to /var/log/apache2 or /var/log/httpd, and mail servers log under /var/log/mail or similar paths.
This layout lets you quickly narrow down where to look. When troubleshooting a specific service, you typically first check its dedicated directory under /var/log before looking at the more general system logs.
Key System Log Files
Several files in /var/log are especially important for everyday administration. The exact names are distribution dependent, but the roles are consistent across systems.
On Debian based systems, such as Ubuntu, you usually find a file called /var/log/syslog that collects general system messages from many services. On Red Hat based systems, such as Fedora or CentOS, the equivalent is usually /var/log/messages. When you suspect a general problem that is not obviously tied to a specific service, this kind of file is often your first stop.
Authentication related events, such as logins, failed login attempts, and sudo use, are typically recorded centrally. On Debian based systems, this is often /var/log/auth.log. On Red Hat based systems, you frequently see /var/log/secure performing a similar role. These logs are central when you investigate suspected unauthorized access or when you need to verify that authentication is working correctly.
Kernel specific messages, such as hardware detection, driver issues, or kernel warnings, may appear in a dedicated kernel log file like /var/log/kern.log or may be merged into the main system log, depending on configuration. When you suspect an issue with hardware or drivers, kernel logs are particularly valuable.
Boot messages may also be recorded in a separate boot log file, such as /var/log/boot.log, recording messages that appear during system startup. This can be helpful when you want to see what happened at boot time, especially if there were delays or failures.
Many other service specific logs reside in /var/log as well, such as mail.log for mail transport, cron.log for scheduled tasks, and dpkg.log or yum.log for package management actions, depending on your distribution.
Accessing and Reading Log Files
Since most files in /var/log are plain text, you can use standard text viewing tools to inspect them. Utilities such as cat, less, and tail are frequently used. In general, you read /var/log files as root, either by logging in as root or by using sudo with your viewer.
If you want to read an entire log file, you can use less for convenient scrolling and searching. For example:
sudo less /var/log/syslog
Within less, you can move line by line or page by page, and you can search with /pattern. This makes it easy to navigate large log files. less does not modify the file, it only reads it.
If you only need the last few lines of a log, such as when you are watching for a recent error, tail is useful. To see the last 20 lines of a file, you can run:
sudo tail -n 20 /var/log/auth.log
When you need to watch a log file as it updates, for example while restarting a service and looking for fresh error messages, you can follow the file with tail -f:
sudo tail -f /var/log/syslog
This command keeps running and prints new lines as they are written by the system. You can stop it with Ctrl+C.
You can also search within logs for specific patterns using tools like grep. An example is:
sudo grep "error" /var/log/syslog
This shows only lines containing the word error in the specified log.
Permissions and Security Considerations
Because log files can contain sensitive details, access is usually restricted. Ordinary users may not have permission to read most files under /var/log. As an administrator, you typically access them via sudo. If you list the directory with:
ls -l /var/log
you can see the owner, group, and permissions of each file and directory. Logs are often owned by root or by a specific service user, and may belong to a dedicated group such as adm or syslog, which can grant read access to certain administrative users without giving them full root access.
You should resist the temptation to relax permissions on log files for convenience. Making logs world readable can expose security information. Similarly, log files should not be writable by ordinary users. If a user can modify logs, they can hide their actions or inject misleading entries.
Some services rotate logs and change ownership or permissions as new files are created. For example, a web server log may be owned by the service user that runs the web server. When you inspect such logs, you may still need sudo if your user does not belong to the relevant group.
Never grant write access on critical logs in /var/log to untrusted users. Writable logs undermine the integrity of your auditing and troubleshooting data.
Log Rotation and File Naming Patterns
Traditionally, log files in /var/log are not allowed to grow indefinitely. Instead, a log rotation system periodically archives older logs and truncates or recreates the active log file. On many systems, this is managed by logrotate, which is typically configured in /etc/logrotate.conf and /etc/logrotate.d/.
When log rotation is used, you will see file naming patterns that indicate rotated logs. A current log file may be named /var/log/syslog, and older versions may appear as /var/log/syslog.1, /var/log/syslog.2.gz, and so on. The .1 file usually holds the previous period, and higher numbers hold older data. The .gz suffix indicates that the log has been compressed using gzip to save disk space.
Rotation is usually driven by size, time, or a combination. For example, logs may rotate once per day, or when they reach a certain number of megabytes, or both. When retention policies are applied, older rotated logs are eventually deleted after a configured number of rotations.
From an administrator’s perspective, this means that when you investigate an incident that happened some time ago, you may need to look into the rotated and possibly compressed logs. To read a compressed log, you can either decompress it with gunzip or use tools like zless and zgrep that read gzip compressed files directly. For example:
sudo zless /var/log/syslog.3.gzWhen you know roughly when an event occurred, the date of rotation and the numbering pattern help you identify which file to inspect.
Service Specific Logs in `/var/log`
Beyond the central system and authentication logs, many individual services maintain their own log files or log directories under /var/log. Experienced administrators often go directly to these service specific logs when diagnosing a problem with a particular component.
Web servers are a typical example. Apache HTTP Server, depending on the distribution, logs to a directory like /var/log/apache2 or /var/log/httpd. Inside you may find separate access.log and error.log files. access.log records details of HTTP requests, such as client IPs and requested URLs, while error.log contains warnings, configuration errors, and runtime problems for the web server itself.
Mail transport agents, such as Postfix or Exim, also maintain detailed logs. These might live in files like /var/log/mail.log, /var/log/maillog, or in service specific directories. When investigating mail delivery issues, bounces, or spam filtering behavior, these logs are the primary reference.
Task schedulers, such as cron, may log their activities to a file like /var/log/cron or cron.log. This can be crucial when a scheduled job does not seem to run as expected and you need to confirm whether the job was triggered and what the outcome was.
Database servers, such as MySQL or PostgreSQL, often have their own logs as well. These may be placed under /var/log/mysql, /var/log/mariadb, or /var/log/postgresql, depending on how the service was packaged for your distribution. You inspect these files when you need to understand connection failures, query errors, or startup problems for the database server.
Each service can choose its own logging format and level of detail. Some log plain text, some log structured data. They also often control how verbose they are through their own configuration files, which determine whether they log only critical errors or also warnings, informational messages, or debug level details.
Practical Use of `/var/log` for Troubleshooting
In everyday administration, the traditional logs in /var/log are a core part of your troubleshooting routine. When a user reports that a service is not working, or when you notice an error in system behavior, you typically use a series of steps that revolve around these logs.
You first identify which component is involved. If the problem is system wide or not clearly linked to a single service, you look at the main system log file such as /var/log/syslog or /var/log/messages. You check recent entries using tail or less, and you may search for relevant words such as fail, error, or the name of a service.
If the issue seems related to authentication, for example the user cannot log in or sudo fails, you focus on /var/log/auth.log or /var/log/secure. These logs can show you whether login attempts reached the system, whether they were denied, and why. Patterns such as repeated failed logins can also indicate brute force attempts from remote hosts.
When you restart a specific service that behaves unexpectedly, you often watch its logs in real time. You open one terminal, run sudo tail -f on the relevant log file, and in another terminal you restart the service. New log entries that appear while the service starts often provide direct clues, such as missing configuration files, permission errors, or port conflicts.
If the problem occurred in the past, you might need to check older logs. In this case, you inspect rotated files and possibly compressed archives in /var/log, based on the timeframe. For example, if an incident happened several days ago, and your logs rotate daily, you might check syslog.1, syslog.2.gz, and so on, until you cover the desired period.
Through repeated use, you develop an intuition for which logs to inspect first, how to search them quickly, and how to correlate entries from different log files, such as matching timestamps between an authentication failure and a network error. The traditional logs in /var/log provide a foundational, historical record that supports this investigative work.