Rainer Gerhards

Note: I have just tenatively assigend the 2024.08 milestone. Based on my current schedule, it will probably be a bit later (plus we currently plan to release 2024.08 rather early...

OK, so it is not consistently reproducible. That complicates things. Unfortunately, the debug log does not help much in this case :-(

well.. redo the test without debug log. If the problem reoccurs, that also gives us some info. It would even be clearer if omfwd triggers the bug and omfile not....

If the remote server is not listening, it will not be able to receive messages. Please clarify and show remote server config.

oh, and this does not work in any case . ``` /var/log/siemlogs/* @192.168.1.20:1514 /var/log/test_logs/* @192.168.1.20:1514 ``` You need to filter them according to the filter doc.

Which software is running there if not rsyslog?

This looks good, but I do not know if the received message are written by the server. But you first need to fix the invalid filter. You cannot just give...

Note that rsyslog follows a "at last once" principle. Duplication can e.g. happen when the transmission is interrupted. This is often the case when load balancers are involved.

Do you have any error messages from rsyslog? This sounds like either a problem with the queue files or some blocked access to state files etc. rsyslog usually complains in...

you could also create a debug log, at least from the startup. Maybe this helps us better understand what is happening. But I would suggest to check the rsyslog logs...