How to Fix /var/log/messages Not Updating on CWP Server

One of the most common issues encountered on CentOS Web Panel (CWP) servers is that the /var/log/messages file suddenly stops logging during heavy traffic or high-intensity attacks (like DDoS or brute-force). When you check the file, you only see the initial “start” logs from the system boot, but no new activities, CSF blocks, or LFD alerts are recorded afterward.

Many server administrators mistakenly think this is caused by high-performance firewall settings such as LF_IPSET = 1 in the csf.conf file. However, this is not the case. This issue is entirely caused by a bottleneck or deadlock between Linux’s logging daemons: rsyslog and systemd-journald.

If your CWP server’s main system log file is frozen, follow this step-by-step guide to resolve the issue permanently.

What Causes This Issue?

When you run systemctl status rsyslog, the service might show as active (running), but you will usually notice this critical warning in the output:

imjournal: journal files changed, reloading...

This indicates that the imjournal module (the bridge responsible for pulling logs from systemd-journald and writing them into rsyslog’s text files) has crashed or entered an infinite loop due to the overwhelming volume of incoming logs during an attack.

Steps to Fix the Log Flow in /var/log/messages

Connect to your server via SSH as the root user and execute the following commands in sequence.

Step 1: Optimize the rsyslog Configuration

We need to adjust rsyslog’s limits so it doesn’t give up or choke when dealing with high-volume journal files.

  1. Open the configuration file with your preferred text editor:Bashnano /etc/rsyslog.conf
  2. Navigate to the #### MODULES #### section and look for the imjournal configuration. Update it or append the following lines:
$ModLoad imjournal
$IMJournalStateFile imjournal.state
$IMJournalIgnorePreviousMessages off
$IMJournalRateLimitInterval 0

Save the file and exit the editor.

Step 2: Clear Corrupted State Files and Refresh Services

Rsyslog keeps track of where it left off using a state file. If this file gets corrupted during a spike, logging freezes. Let’s wipe it out and restart the services cleanly:

# Stop the logging services
systemctl stop rsyslog
systemctl stop systemd-journald

# Delete the potentially corrupted state file
rm -f /var/lib/rsyslog/imjournal.state

# Start the services back up in the correct order
systemctl start systemd-journald
systemctl start rsyslog

(Note: You might see a warning regarding socket activation while stopping systemd-journald. This is perfectly normal and can be safely ignored.)

Step 3: Test the System Log Flow

To verify that everything is working, send a manual test log message into the system and check if it reaches the file:

Bash

logger -i "CWP Log Flow Test Successful"
tail -n 15 /var/log/messages

If you see CWP Log Flow Test Successful at the very bottom of the command output, congratulations! Your system’s logging mechanism is fully restored.

Restarting CSF and LFD

Now that the main log file is functioning properly, we need to restart the lfd (Login Failure Daemon) service so it can read the freshly generated logs from the beginning:

Bash

csf -r
systemctl restart lfd

You can watch your firewall blocks and security events land in the log file in real-time by running:

Bash

tail -f /var/log/messages | grep -E "csf|lfd"

Does LF_IPSET = 1 Cause This?

No. Turning on LF_IPSET = 1 in your CSF configuration instructs the firewall to store blocked IP addresses inside high-performance ipset kernel sets rather than stacking thousands of individual iptables rules. This is an excellent, highly recommended performance optimization that reduces CPU overhead during attacks. It has absolutely nothing to do with logs stopping. The issue is strictly an OS-level logging module crash.

Scroll to Top