Logging of wazuh agents not working

[Veera]

Greetings Wazuh Team,

We are encountering an issue on RHEL 7 systems where Wazuh logs are not being generated beyond a single entry. The ossec.log file only contains the following line:

2026/04/14 00:00:10 wazuh-agentd: INFO: Starting new log after rotation.

Upon verifying the archived logs under /var/ossec/logs/wazuh/2026/Apr/, we observe the same behavior, with no additional log entries being recorded.

Restarting the Wazuh agent service temporarily resolves the issue and normal logging resumes. However, performing service restarts across hundreds of agents is not a feasible long-term solution.

Could you please help identify the possible cause of this issue and recommend a scalable solution?

Thank you.

[Veera]

Logs attached 

[adrian...@wazuh.com]

Hi,

While we investigate this issue, please verify that no external rotation mechanism (ie. logrotate) is configured to rotate the log file /var/ossec/logs/ossec.log

Regards,

Adrian.

[Veera]

Yes, I confirm there is no exernal log mechanism configured in those servers other than the daily logrotate.

Refer to the attached

[Stuti Gupta]

Hello,

From the information you provided, the Wazuh agent is running normally. All the agent processes are active, and the service has been running for more than two weeks. The daily log rotation is also happening correctly.

The line you see in the log:

2026/04/14 00:00:10 wazuh-agentd: INFO: Starting new log after rotation.

is expected. This message appears when the agent rotates its internal logs.

It is important to note that /var/ossec/logs/ossec.log only stores internal agent messages. It does not have the security alerts or events that are sent to the Wazuh manager. If the agent is running without warnings or errors, the log file can remain almost empty and may only show rotation messages.

The rotated logs you checked under /var/ossec/logs/wazuh/2026/Apr/ also show normal rotation behavior.

Since restarting the agent temporarily shows new log entries, first verify whether the agent continues sending events to the manager while the log file looks empty.

If alerts are still visible on the Wazuh manager   /var/ossec/logs/alerts/alerts.json or dashboard, then the agent is working correctly, and the behavior is simply due to very low internal logging.

You can verify the agent status from the manager with:

/var/ossec/bin/agent_control -i <agent_id>

If you want to confirm that logging is still working, you can temporarily increase the debug level on the agent. Edit the file:

/var/ossec/etc/local_internal_options.conf

and add:

logcollector.debug=2

Then restart the agent:

systemctl restart wazuh-agent

This will increase the logging level, and you should see more entries in ossec.log.

Also, there is a GitHub discussion about logcollector behavior after log rotation:
https://github.com/wazuh/wazuh/issues/26778

However, that discussion refers to changes planned for Wazuh 5.x, so it is not directly related to environments running Wazuh 4.x like yours.

If possible, please confirm whether the agent is still sending alerts to the manager while the log file shows only the rotation entry. That will help determine whether this is only a logging verbosity issue or something else.

Additionally, there is a warning related to tag syntax in the command module. Please remove the tag syntax, and to know/learn about command monitoring configuration, please refer to https://documentation.wazuh.com/current/user-manual/capabilities/command-monitoring/configuration.html

[Veera]

Hi,

There are no log entries present in /var/ossec/logs/alerts/alerts.json on the associated manager. The agent details have been verified using /var/ossec/bin/agent_control -i <agent_id>.

The primary objective of this case is to address that the agents are not only failing to generate logs, but are also not visible in the Wazuh console. Despite this, the agent.conf contains the correct server configuration.

During initial troubleshooting to determine why the agents are not appearing in the console, it was observed that the ossec.log file is empty.

Please note that restarting the Wazuh agent service must be avoided, as multiple agents are experiencing the same issue.

Given that the required ports (1514/1515) are open, guidance is requested on the next steps to identify why the agents are not reporting to Wazuh

[adrian...@wazuh.com]

Hi Veera,

We've been trying to reproduce the issue on our end without luck. 

Please confirm / provide the following information:

- Wazuh version you are using. 

- Manager logs: /var/ossec/logs/ossec.log (grep -iE "error|warn" /var/ossec/logs/ossec.log)

Thanks,

Adrian.

[Veera]

Hi Adrian,

- Wazuh version you are using.   wazuh-agent-4.14.4-1.x86_64 (both server and agent)

- Manager logs: /var/ossec/logs/ossec.log (grep -iE "error|warn" /var/ossec/logs/ossec.log)

Refer to the Attached logs ... my setup has master server and multiple worker nodes .. hence shared here the details of logs  (grep -iE "error|warn" /var/ossec/logs/ossec.log)   from the master and one sample worker node..

Will the today's /var/ossec/logs/ossec.log from the servers help?

The agent was onboarded on Apr-01 and have error logs in the sever on that day only..

bash-5.2# grep veera-affected1 ossec.log
bash-5.2# cd -
/var/ossec/logs/wazuh/2026/Apr
bash-5.2# zgrep -iE "error|warn ossec-01.log.gz ^C
bash-5.2# cd -
/var/ossec/logs
bash-5.2# grep veera-affected1 ossec.log
bash-5.2# ls
active-responses.log  alerts  api  api.log  archives  cluster  cluster.log  firewall  integrations.log  ossec.log  wazuh
bash-5.2# cd /var/ossec/logs/wazuh/2026/Apr
bash-5.2# zgrep veera-affected1 *
ossec-01.log.gz:2026/04/01 10:35:42 wazuh-authd: INFO: Received request for a new agent (veera-affected1) from: 10.0.0.23
ossec-01.log.gz:2026/04/01 10:35:42 wazuh-authd: INFO: Agent key generated for 'veera-affected1' (requested by any)
ossec-01.log.gz:2026/04/01 12:22:24 wazuh-authd: INFO: Received request for a new agent (veera-affected1) from: 10.0.0.21
ossec-01.log.gz:2026/04/01 12:22:24 wazuh-authd: WARNING: Duplicate name 'veera-affected1', rejecting enrollment. Agent '7459' has not been disconnected long enough to be replaced.
ossec-01.log.gz:2026/04/01 12:26:37 wazuh-authd: INFO: Received request for a new agent (veera-affected1) from: 10.0.0.22
ossec-01.log.gz:2026/04/01 12:26:37 wazuh-authd: WARNING: Duplicate name 'veera-affected1', rejecting enrollment. Agent '7459' has not been disconnected long enough to be replaced.
ossec-10-001.log.gz:2026/04/10 23:45:16 wazuh-authd: INFO: Agent '7459' (veera-affected1) deleted (requested locally)
bash-5.2#

I cannot attach the output from  grep -iE "error|warn" /var/ossec/logs/ossec.log due to the size

However snippets here ..

2026/04/28 00:39:40 wazuh-authd: ERROR: Too many connections. Rejecting.
2026/04/28 00:39:40 wazuh-authd: ERROR: Too many connections. Rejecting.
2026/04/28 00:39:40 wazuh-authd: ERROR: Too many connections. Rejecting.
2026/04/28 00:39:40 wazuh-authd: ERROR: Too many connections. Rejecting.
2026/04/28 00:39:40 wazuh-authd: ERROR: Too many connections. Rejecting.


bash-5.2# grep -iE "error" ossec.log  |wc -l
930702
bash-5.2#

bash-5.2# grep -iE "error" ossec.log |grep -v "Too many connections" |wc -l
678
bash-5.2# grep -iE "error" ossec.log |grep "Too many connections" |wc -l
934856
bash-5.2# grep -iE "warn" ossec.log  |grep -v Duplicate |head -5
2026/04/28 00:00:24 wazuh-db: WARNING: The groups were empty right after the set for agent '54431'
2026/04/28 00:00:44 wazuh-db: WARNING: The groups were empty right after the set for agent '54431'
2026/04/28 00:01:04 wazuh-db: WARNING: The groups were empty right after the set for agent '54431'
2026/04/28 00:01:24 wazuh-db: WARNING: The groups were empty right after the set for agent '54431'
2026/04/28 00:01:44 wazuh-db: WARNING: The groups were empty right after the set for agent '54431'
bash-5.2#

[adrian...@wazuh.com]

Hi Veraa,
Based on the details you shared, we can see that the agent name 'veera-affected1' is being used by multiple nodes (10.0.0.21, 10.0.0.22, and 10.0.0.23).

Because Wazuh requires unique agent names, there are enrollment failures with the Wazuh manager. Agents that are not successfully enrolled will not be able to send scan data. 

We also suspect that the 'Too many connections' errors are caused by agents repeatedly attempting unsuccessful enrollments.

As a corrective action, we recommend assigning unique agent names and retrying enrollment.

Regards,
Adrian.