Log rotation is one of the most important maintenance processes in any Wazuh deployment.
Every Wazuh component continuously generates logs that record security events, agent communications, API activity, cluster synchronization, alerts, and system operations.
Without proper log rotation, these files continue growing indefinitely, consuming valuable disk space and making log management increasingly difficult.
When Broken Wazuh Log Rotations occur, administrators often discover the problem only after the system begins experiencing secondary failures.
Large log files can fill partitions, slow filesystem operations, increase backup times, and even prevent critical Wazuh services from writing new events.
In severe cases, a full disk can interrupt security monitoring, prevent alerts from being indexed, or cause services to crash unexpectedly.
One of the most common causes of failed log rotations is a “permission denied” error.
These errors typically occur when the log rotation process lacks sufficient privileges to rename, compress, create, or delete log files.
Incorrect file ownership, restrictive Linux permissions, SELinux or AppArmor policies, manually modified log files, and improperly configured logrotate directives can all prevent successful rotation.
Fortunately, these issues are usually straightforward to diagnose once you understand how Wazuh’s logging system works.
By identifying where permissions are failing and correcting ownership or configuration problems, you can restore automatic log maintenance before storage problems begin affecting your environment.
In this guide, you’ll learn:
- How Wazuh log rotation works behind the scenes
- Which components are responsible for rotating different log files
- The most common symptoms of broken log rotations
- How to diagnose “permission denied” errors
- Step-by-step methods to repair ownership and permission issues
- Best practices to prevent future log rotation failures
Throughout the article, you’ll also learn how to verify that log rotations complete successfully and how to keep your Wazuh deployment healthy over the long term.
Understanding How Wazuh Log Rotation Works
What Is Log Rotation?
Log rotation is the automated process of managing log files by periodically renaming, archiving, compressing, and replacing active logs with new empty files.
Rather than allowing a single log file to grow forever, the operating system periodically rotates it according to predefined rules.
Most Linux distributions perform this task using the logrotate utility, which has become the standard mechanism for maintaining application logs.
Purpose of Rotating Logs
The primary purpose of log rotation is to keep log management predictable and efficient.
Instead of handling one enormous log file, administrators work with smaller archived logs that are easier to search, transfer, compress, and back up.
Regular rotation also minimizes the impact of log-intensive workloads during security incidents, when thousands of new events may be generated every minute.
Preventing Unlimited Log Growth
Without rotation, important files such as ossec.log or alert logs can grow into multiple gigabytes. Large files consume disk space, increase filesystem fragmentation, and slow many administrative tasks.
Automatic rotation limits file sizes by periodically moving older logs into archived copies while allowing Wazuh to continue writing to fresh files.
Maintaining Long-Term Log History
Log rotation is not simply about deleting logs.
Instead, it preserves historical records by creating archived copies, often compressed into .gz files.
These archives provide valuable forensic evidence during incident response while significantly reducing storage requirements.
Organizations frequently retain weeks or months of rotated logs depending on compliance requirements.
Which Wazuh Logs Are Rotated?
Several important Wazuh log files are rotated automatically.
These commonly include:
ossec.logalerts.logalerts.jsonarchives.logarchives.json- Wazuh API logs
- Cluster synchronization logs
- Active Response logs
- Manager service logs
Depending on your deployment, additional logs generated by Filebeat, OpenSearch, or the dashboard may also be rotated separately using their own rotation policies.
Understanding which files are managed by each service helps narrow down permission-related failures more quickly.
Related Guide: How to Configure Wazuh Log Retention
Components Involved in Wazuh Log Rotation
Successful log rotation depends on several Linux components working together correctly.
logrotate
logrotate is the utility responsible for executing scheduled log rotations.
It reads configuration files under locations such as:
/etc/logrotate.conf
/etc/logrotate.d/Based on configured rules, it renames active log files, compresses old logs, creates new log files, and removes archives that exceed the retention policy.
Wazuh Manager
The Wazuh Manager continuously writes security events into multiple log files.
During rotation, the manager must either reopen the newly created files or receive a signal instructing it to continue logging to the fresh file.
Improper restart or post-rotation commands can leave Wazuh writing into deleted or renamed files.
File Ownership
Correct ownership is essential.
Most Wazuh log files are owned by the Wazuh user and group, while some auxiliary services may use different accounts.
If ownership changes unexpectedly, for example after manually copying files or restoring backups, logrotate may no longer have permission to modify them.
Linux Permissions
Standard Linux permissions determine whether files can be:
- Read
- Written
- Renamed
- Deleted
- Compressed
- Recreated
Even if a file itself appears writable, restrictive permissions on its parent directory may still prevent rotation.
Systemd Services
Many Linux distributions execute scheduled log rotations through systemd timers or cron jobs.
If these scheduling services fail, rotations may never run regardless of how well the configuration is written.
Administrators should always verify that scheduled rotation jobs are executing as expected.
Typical Rotation Schedule
Most Wazuh deployments follow predictable rotation policies.
Daily Rotations
Many production systems rotate logs every 24 hours.
Daily rotation keeps individual files manageable while preserving a complete history of security activity.
Size-Based Rotations
Some environments rotate logs whenever they exceed a specified size, such as:
- 50 MB
- 100 MB
- 500 MB
This approach is especially useful in high-volume environments where daily logs can become extremely large.
Compression
Older logs are usually compressed automatically after rotation.
Compression dramatically reduces storage consumption while preserving historical data for future investigations.
Compressed logs typically appear as:
ossec.log.1.gz
alerts.log.2.gzRetention Periods
Rotation policies also define how many archived logs are retained before deletion.
For example:
- Keep the last 7 days
- Keep the last 30 rotations
- Keep 90 days of compressed archives
Choosing an appropriate retention period depends on available storage, compliance requirements, and incident response needs.
Symptoms of Broken Wazuh Log Rotations
Broken log rotations rarely go unnoticed for long.
As rotation failures accumulate, storage consumption increases and Wazuh eventually begins exhibiting operational problems.
Recognizing these warning signs early can prevent outages and data loss.
Log Files Continue Growing Indefinitely
The most obvious symptom is that one or more log files never stop increasing in size.
For example:
/var/ossec/logs/ossec.logor
alerts.jsonmay continue growing for weeks without ever being archived.
Checking file sizes with commands like ls -lh often reveals unusually large files measured in gigabytes rather than megabytes.
“Permission Denied” Errors in logrotate Output
Permission failures are among the clearest indicators that rotation is broken.
Administrators may encounter errors similar to:
error: error renaming /var/ossec/logs/ossec.log:
Permission deniedor
failed to create output file:
Permission deniedThese errors usually indicate problems involving:
- Incorrect ownership
- Directory permissions
- Immutable files
- SELinux or AppArmor restrictions
- Missing privileges
The exact error message often points directly to the resource causing the failure.
Disk Space Gradually Fills Up
Since logs are never archived or deleted, storage usage steadily increases.
Eventually administrators may observe:
- High filesystem utilization
- Low free disk space
- Warning alerts from monitoring systems
- Failed package updates
- Database write failures
In severe situations, a completely full partition can prevent Wazuh services from starting correctly.
Related Guide: How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes
Rotated Logs Are Never Created
Normally, older log files appear with numbered suffixes such as:
ossec.log.1
ossec.log.2.gzIf these files never appear, even after scheduled rotation periods, the rotation process likely failed before completing.
Missing rotated files almost always warrant investigation.
Compressed Archives Are Missing
Healthy log rotation typically compresses older logs to conserve disk space.
If your log directory contains only active log files and no .gz archives despite weeks of operation, compression is likely never being reached because rotation itself is failing.
This symptom commonly accompanies permission-related errors.
Wazuh Services Report Logging Errors
As log files become excessively large or storage fills up, Wazuh components may begin reporting logging-related failures.
Possible symptoms include:
- Delayed alert processing
- Failed writes to log files
- API logging failures
- Manager warnings
- Filebeat indexing issues
- Service instability
These downstream effects often indicate that log rotation has been failing for some time rather than representing the original problem itself.
Related Guide: Resolving Filebeat Connection Refused Errors in Wazuh Deployments
Expert insight: The Linux logrotate utility is designed to automate log management, but its maintainers emphasize that correct ownership, permissions, and post-rotation actions are essential for reliable operation. Likewise, the Wazuh documentation recommends monitoring log health and storage utilization as part of routine platform maintenance to prevent operational issues caused by oversized or unmanaged log files.
Be First to Comment