I was trying to build a custom Syslog server on the Windows platform, which I, for a start, am implementing a basic TCP listener (server). I encountered problem and I have asked this on StackOverflow: Question.

Later on, I realized the problem exists even when I use two Rsyslogs on two separate linux machines.

This is the rsyslog.conf on the client machine:

local3.*    @@

This is rsyslog.conf on the server machine:

local3.*    /var/log/test.log

This is the script (on client) to send log messages:


for i in 1 2 3 4 5 6 7 8 9 10
logger -i -t Test -p local3.debug "This is test $i"

This is the output file received at server machine (test.log):

2016-08-02T00:10:33-07:00 ubuntu Test[37023]: This is test 2
2016-08-02T00:10:33-07:00 ubuntu Test[37024]: This is test 3
2016-08-02T00:10:33-07:00 ubuntu Test[37025]: This is test 4
2016-08-02T00:10:33-07:00 ubuntu Test[37026]: This is test 5
2016-08-02T00:10:33-07:00 ubuntu Test[37027]: This is test 6
2016-08-02T00:10:33-07:00 ubuntu Test[37028]: This is test 7
2016-08-02T00:10:33-07:00 ubuntu Test[37029]: This is test 8
2016-08-02T00:10:33-07:00 ubuntu Test[37030]: This is test 9
2016-08-02T00:10:33-07:00 ubuntu Test[37031]: This is test 10

Apparently, the first message This is test 1 is the one that triggers the TCP connection, and it has been discarded.

Is there any settings on rsyslog that I can set to prevent this?


I want to point out that this only happens if the connection has yet been established; if I run the script the second time immediately after the first, the second script run will generate This is test 1.

I am also glad to have upvotes for the question, but it seems weird to me that there aren't many people who have noticed this problem, and have tried to remedy this. People who log are typically people who are serious about knowing where their system went right and wrong, and yet they are assuming things would work right if they set the configurations right? I wanted to try more things, but I am really very new to Unix systems, so I have no idea how to tackle this problem.


I did further tests. It seems like I wasn't totally right. It seems to happen only if I do systemctl restart rsyslog on the server (receiving) machine, but doing so for the client machine.

My guess is that the client thinks that it is still connected (whereas at server side isn't), and tries to send the next message. This is when the client realizes the connection has been broken, and attempts to re-establish a new connection.

The weird thing is, I have no idea why the client would think that the lost message is delivered.

I know there is RELP, but eventually I would have the central syslog server on Windows platform. How do I either use TCP without this problem, or get (or build) a syslog server (collector) running on Windows supporting RELP?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.