Last modified: June 01, 2025

This article is written in: 🇺🇸

Log Files, Journals, and Logging Systems

Understanding how logging works in Linux is like learning the language your system uses to communicate. Logs are the detailed records that your system keeps about its activities, and they are invaluable for troubleshooting, monitoring performance, and ensuring security. Let's embark on a journey to demystify log files, journals, and the various logging systems used in Linux.

What is a log?

+-----------------------------------------------------------+
| LOG FILE                                                  |
|-----------------------------------------------------------|
| TIMESTAMP        | SEVERITY  | SERVICE   | MESSAGE        |
|-----------------------------------------------------------|
| 2023-08-01 09:00 | INFO      | myapp     | Server started |
| 2023-08-01 09:01 | WARNING   | myapp     | High CPU usage |
| 2023-08-01 09:02 | ERROR     | myapp     | Server crashed |
+-----------------------------------------------------------+

• A log file is a structured record of events, typically generated by applications, systems, or network devices, capturing critical data for monitoring and troubleshooting purposes.
• Each log entry begins with a timestamp, which marks the exact date and time when a specific event occurred, allowing for precise tracking of system activities.
• The severity level of each event is included in the log to indicate its importance, ranging from informational messages (INFO) to warnings (WARNING) and critical errors (ERROR).
• Logs also specify the service or application that generated the event, helping to pinpoint which part of the system is involved, such as "myapp" in the example.
• The message section of a log entry provides a brief description of the event or issue, offering insights into what happened, such as "Server started," "High CPU usage," or "Server crashed."
• By reviewing log files, system administrators can identify potential issues, monitor system performance, and diagnose failures to maintain the overall health of the system.

Why Logging Matters

Imagine trying to fix a car without knowing what's wrong. Logs provide the clues needed to diagnose and fix issues. They record everything from system errors and warnings to user activities and application events. By analyzing logs, you can:

• Identify and resolve system issues before they escalate.
• Monitor system performance to optimize resources.
• Ensure security compliance by tracking unauthorized access attempts.
• Audit user activities for accountability.

The Landscape of Linux Logging Methods

Linux offers several methods for logging, each with its own set of features suited to different needs. The primary logging methods include plain text log files, journald, and rsyslog.

Plain Text Log Files

At the heart of Linux logging is the traditional plain text log file. These are simple text files where the system writes log messages. They're stored in the /var/log directory and are straightforward to read and parse.

Example of a Plain Text Log File (/var/log/syslog):

Aug  1 09:00:01 myhostname CRON[12345]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug  1 09:01:22 myhostname sshd[12346]: Accepted password for user from 192.168.1.100 port 54321 ssh2
Aug  1 09:02:33 myhostname sshd[12347]: Failed password for invalid user admin from 192.168.1.101 port 54322 ssh2

In this snippet:

• Each line starts with a timestamp.
• It includes the hostname, process ID, and the log message.
• Messages range from routine tasks to security events.

Journald: The Systemd Journal

With the introduction of systemd, journald became the default logging system for many Linux distributions. It stores logs in a binary format, enabling more efficient storage and richer metadata.

Visual Representation of Journald Workflow:

+--------------------------------+
|        systemd-journald        |
+---------------+----------------+
                |
                | Collects Logs from:
                |
+---------------+----------------+
|               |                |
|           Systemd Units        |
|          (Services, etc.)      |
|               |                |
|           Kernel Messages      |
|               |                |
|           Applications         |
|               |                |
+---------------+----------------+
                |
                v
+--------------------------------+
|          Journal Files         |
|   (/run/log/journal/ or        |
|     /var/log/journal/)         |
+--------------------------------+

Features of journald:

• By using structured logging, logs can include enriched metadata like UID, GID, and system capabilities, making detailed filtering and analysis much easier.
• The binary format allows for efficient storage by supporting compression and indexing, which saves disk space and speeds up access to log data.
• Access controls can be applied to ensure security, protecting log files from unauthorized access and preserving their integrity.

Rsyslog

Rsyslog is a powerful logging system that extends the capabilities of traditional syslog. It supports various input and output modules, enabling complex log processing tasks.

Features of Rsyslog:

• With high performance capabilities, it can manage extremely large volumes of log data, making it suitable for environments with heavy logging demands.
• The modular design supports various plugins, allowing users to extend functionality based on specific needs, such as different input/output formats.
• Flexible configuration options enable content-based filtering and routing, making it easy to direct specific logs to designated locations based on their content.

Exploring Common System Log Files

Logs are typically stored in the /var/log directory. Let's explore some of the most important log files you should be familiar with.

/var/log/syslog

This is the primary log file where most system messages are recorded. It includes messages from the kernel, system services, and applications.

Viewing /var/log/syslog:

sudo tail /var/log/syslog

Sample Output:

Aug  1 10:15:42 myhostname NetworkManager[1234]: <info>  [1596274542.1234] device (eth0): state change: activated -> deactivating
Aug  1 10:15:42 myhostname avahi-daemon[5678]: Withdrawing address record for 192.168.1.10 on eth0.
Aug  1 10:15:45 myhostname kernel: [12345.678901] eth0: Link is Down

• NetworkManager messages indicate changes in network device states.
• Avahi-daemon logs relate to network service announcements.
• Kernel messages provide low-level hardware and driver information.

/var/log/auth.log

This file records authentication-related events, such as logins and sudo usage.

Viewing Authentication Logs:

sudo grep "Failed password" /var/log/auth.log

Sample Output:

Aug  1 11:00:01 myhostname sshd[23456]: Failed password for invalid user admin from 192.168.1.101 port 54323 ssh2
Aug  1 11:05:12 myhostname sshd[23457]: Failed password for root from 192.168.1.102 port 54324 ssh2

• Failed login attempts could indicate unauthorized access attempts.
• IP addresses help identify the source of the attempts.
• Usernames show which accounts are being targeted.

/var/log/kern.log

Kernel logs contain messages from the Linux kernel, providing insights into hardware and system-level events.

Viewing Kernel Logs:

sudo tail /var/log/kern.log

Sample Output:

Aug  1 12:00:00 myhostname kernel: [13000.000000] CPU0: Temperature above threshold, cpu clock throttled
Aug  1 12:00:05 myhostname kernel: [13005.000000] CPU0: Temperature/speed normal

• Temperature warnings indicate potential overheating issues.
• Throttling messages show the system is taking action to prevent damage.

/var/log/dmesg

The dmesg command outputs messages from the kernel ring buffer, which is especially useful for diagnosing hardware issues.

Running dmesg:

dmesg | less

Sample Output:

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Linux version 5.8.0-43-generic (buildd@lgw01-amd64-052) (gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0) #49-Ubuntu SMP ...
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.8.0-43-generic root=UUID=...
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD

• Boot messages provide a detailed view of the system's initialization process, showing each step as the system starts up.
• During hardware detection, it lists detected components, including CPUs, memory, and connected devices, giving an overview of the system's physical resources.
• The command line displays boot parameters, indicating the specific options and configurations applied during the boot process.

Delving into Journald and journalctl

journalctl is the command-line tool for accessing logs stored by journald. It provides powerful filtering and querying capabilities.

Basic Usage of journalctl

Viewing All Logs:

journalctl

This command displays all journal entries, starting from the oldest.

Viewing Recent Logs:

journalctl -n 50

Shows the most recent 50 log entries.

Following Logs in Real-Time:

journalctl -f

Similar to tail -f, it streams new log entries as they occur.

Filtering Logs with journalctl

Filtering is where journalctl truly shines.

Filtering by Time Range:

journalctl --since "2023-08-01 08:00:00" --until "2023-08-01 12:00:00"

The --since and --until options accept natural language inputs like "1 hour ago" or "yesterday".

Filtering by Unit (Service):

journalctl -u apache2.service

Sample Output:

Aug  1 09:00:00 myhostname systemd[1]: Starting The Apache HTTP Server...
Aug  1 09:00:01 myhostname apachectl[1234]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name...
Aug  1 09:00:01 myhostname systemd[1]: Started The Apache HTTP Server.

• Service Start Messages indicate when the service was started.
• Warnings/Errors help diagnose configuration issues.

Advanced journalctl Usage

Filtering by Priority Level:

journalctl -p err

Shows logs with priority err (error) and higher (more severe).

Priority Levels:

Example of Priority Filtering:

journalctl -p warning -u ssh.service

Displays warnings and errors related to the SSH service.

Persistent Journals

By default, journald stores logs in memory, which means logs are lost on reboot. To make logs persistent:

I. Create Journal Directory:

sudo mkdir -p /var/log/journal

II. Set Permissions:

sudo systemd-tmpfiles --create --prefix /var/log/journal

III. Restart systemd-journald:

sudo systemctl restart systemd-journald

Now, logs are stored in /var/log/journal and persist across reboots.

Mastering Rsyslog for Log Management

Rsyslog offers extensive capabilities for collecting, processing, and forwarding log messages.

Understanding Rsyslog Configuration

Rsyslog configuration files are located at /etc/rsyslog.conf and in the /etc/rsyslog.d/ directory.

Basic Rsyslog Syntax:

facility.priority    action

Facilities:

Priorities:

Example Configuration:

# Log all kernel messages to /var/log/kern.log
kern.*    /var/log/kern.log

# Log mail info messages to /var/log/mail.info
mail.info    /var/log/mail.info

# Log cron messages to /var/log/cron.log
cron.*    /var/log/cron.log

Filtering and Routing Logs

You can fine-tune which messages are logged where.

Example: Ignore Debug Messages for a Specific Facility:

daemon.none    /var/log/daemon.log

This prevents debug messages from the daemon facility from being logged to /var/log/daemon.log.

Setting Up a Centralized Log Server with Rsyslog

Centralized logging is crucial for managing logs in environments with multiple servers.

Configuring the Log Server

I. Enable UDP Reception:

In /etc/rsyslog.conf, uncomment or add:

module(load="imudp")
input(type="imudp" port="514")

II. Enable TCP Reception (Optional):

module(load="imtcp")
input(type="imtcp" port="514")

III. Define Templates and Rules (Optional):

To organize logs by host:

template(name="RemoteLogs" type="string" string="/var/log/%HOSTNAME%/%PROGRAMNAME%.log")
*.* ?RemoteLogs

IV. Restart Rsyslog:

sudo systemctl restart rsyslog

Configuring Client Machines

I. Edit /etc/rsyslog.conf:

Add the following line at the end:

* 514

For TCP, use @@ instead of @.

II. Restart Rsyslog:

sudo systemctl restart rsyslog

Verifying Centralized Logging

On the log server, check if logs from clients are being received:

ls /var/log/

You should see directories or files corresponding to client hostnames.

Example Directory Structure:

/var/log/client1/
/var/log/client2/
/var/log/client3/

Logger

The logger command is a shell utility used to add messages to the system log.

Basic Usage

Sending a Simple Message:

logger "Backup completed successfully."

This appends the message to /var/log/syslog.

Including Tags:

logger -t backup_script "Backup failed due to insufficient disk space."

Adds a tag [backup_script] to the log entry for easy identification.

Advanced Options

Specifying Facility and Priority:

logger -p local0.notice "Application started."

Sending to a Remote Syslog Server:

logger -n logserver_ip -P 514 "Remote log message from client."

Incorporating into Scripts

Example Backup Script with Logging:

#!/bin/bash

backup_dir="/backup"
source_dir="/data"

if rsync -av "$source_dir" "$backup_dir"; then
    logger -t backup_script -p local0.info "Backup completed successfully."
else
    logger -t backup_script -p local0.err "Backup failed!"
fi

• Uses rsync to perform the backup.
• Logs success or failure with appropriate severity.

Managing Log Files with Logrotate

Over time, log files can grow large, consuming significant disk space. logrotate automates the rotation, compression, and removal of log files.

Understanding Configuration

Configurations are stored in /etc/logrotate.conf and /etc/logrotate.d/.

Sample logrotate Configuration for /var/log/syslog:

/var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        invoke-rc.d rsyslog rotate > /dev/null
    endscript
}

Explanation:

Forcing Log Rotation

To manually force a log rotation:

sudo logrotate -f /etc/logrotate.conf

Verifying Log Rotation

Check the rotated and compressed log files:

ls /var/log/syslog*

Expected Output:

/var/log/syslog
/var/log/syslog.1.gz
/var/log/syslog.2.gz
/var/log/syslog.3.gz
...

Practical Scenarios and Applications

Let's apply our knowledge to real-world situations.

Scenario 1: Detecting Unauthorized SSH Attempts

Step 1: Analyze Authentication Logs

sudo grep "Failed password" /var/log/auth.log

• Identify IP addresses with multiple failed attempts.
• Determine if certain usernames are being targeted.

Step 2: Block Malicious IP Addresses

sudo iptables -A INPUT -s malicious_ip -j DROP

Alternatively, install fail2ban to automate this process.

Step 3: Secure SSH Configuration

I. Change the Default SSH Port:

Edit /etc/ssh/sshd_config:

Port 2222

II. Disable Root Login:

PermitRootLogin no

III. Use Public Key Authentication:

PasswordAuthentication no

IV. Restart SSH Service:

sudo systemctl restart sshd

Scenario 2: Monitoring Disk Usage

Step 1: Check Disk Space with df:

df -h

Sample Output:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   45G  5.0G  90% /

The root filesystem is 90% full.

Step 2: Find Large Log Files

sudo du -sh /var/log/*

Sample Output:

1.2G    /var/log/apache2
500M    /var/log/mysql

Step 3: Rotate Logs Manually

If logrotate isn't configured properly, you might need to force rotation.

sudo logrotate -f /etc/logrotate.d/apache2

Step 4: Remove Old Logs

sudo find /var/log -type f -name "*.gz" -mtime +30 -delete

Deletes compressed log files older than 30 days.

Best Practices

• Regular log analysis should be automated using tools like Logwatch or Splunk to enhance efficiency and reduce manual oversight.
• It is important to set up alerts for critical events, which can be configured using tools such as Nagios or Prometheus to ensure rapid response to incidents.
• To secure log storage, access control should be enforced by restricting log file permissions to authorized personnel only, ensuring that sensitive data remains protected.
• Encrypting log data, especially during transmission over networks, is crucial for preventing unauthorized access and maintaining confidentiality.
• Implementing log retention policies is necessary to ensure compliance with legal requirements, especially for industries with strict data retention mandates.
• Proper disk space management is essential when storing logs, requiring a balance between keeping historical data for analysis and ensuring that storage resources are not overwhelmed.
• Centralized logging solutions offer significant advantages by simplifying log management across multiple servers, reducing complexity and improving oversight.
• Platforms like the ELK Stack (Elasticsearch, Logstash, Kibana) should be utilized to provide robust search capabilities and visualization tools for more effective log analysis.
• Regular reviews of logging configurations are necessary to ensure that the system is capturing all relevant data and that no important events are missed.
• Keeping logging software updated is vital for benefiting from the latest security patches and new features, reducing the risk of vulnerabilities in the system.

Challenges

1. Discuss the importance of logging in system administration, including its role in maintaining system health, identifying issues, and assisting with security auditing. Provide examples of how logging helps in daily administration tasks and long-term system monitoring.
2. Research and describe Journald, its functions, and its advantages over traditional text-file-based logging systems. Explain how Journald works with systemd, highlighting features like binary storage, structured logging, and how it simplifies log management for modern systems.
3. Explain how Rsyslog works and describe its configuration process, including how to set up centralized logging. Discuss severity levels, how they categorize log messages, and how they can be used to filter specific types of messages based on their importance or urgency.
4. Use the logger command to create custom messages in the system logs. Experiment with different flags, such as specifying the facility or severity level, and explain how logger can be used to add entries manually or from within scripts for testing or informational purposes.
5. Configure and use logrotate to automate log file management. Set up a basic configuration to rotate, compress, and delete log files on a schedule, and discuss how logrotate helps prevent logs from consuming excessive disk space. Explain the importance of log rotation in production systems.
6. Research common log file formats, such as text-based, JSON, and binary formats, and compare their structures. Discuss the benefits and drawbacks of each format, considering factors like readability, compatibility with log analysis tools, and efficiency for storage and search.
7. Set up and use log filters to selectively include or exclude specific log messages. Use either Rsyslog or Journald, and create a rule that filters messages based on criteria such as facility, severity level, or keywords. Document how filtering helps reduce noise in the logs and improves readability.
8. Utilize log analysis tools like grep, journalctl, or awk to extract meaningful information from log files. Perform tasks such as searching for specific events, identifying patterns, and generating summary reports. Explain how log analysis helps administrators identify issues and monitor system health.
9. Outline best practices for managing logs in a production environment. Discuss strategies for log retention, log security, and ensuring reliability and availability of log files. Include recommendations on how to securely store and transmit logs, especially for compliance purposes.
10. If you delete an application’s log file on a production server, could that cause the application to stop functioning?
11. Describe common logging-related issues in a Linux environment, such as missing logs, log file corruption, or disk space running out due to log growth. Explain steps for diagnosing and resolving each problem, including strategies for recovering lost logs and freeing up space.