Messages lost during log server downtime when using plain TCP forwarding

[BenGig]

Expected behavior

Messages created during log server downtime should be delivered when the server is up again.

Actual behavior

Messages do not appear on log server.

Steps to reproduce the behavior

Client setup following the instructions in https://www.rsyslog.com/doc/v8-stable/tutorials/reliable_forwarding.html

Shut down log server. Issue
`logger MESSAGE_1'

Start log server. Issue
`logger MESSAGE_2'

Log on log server only shows MESSAGE_2.

Environment

Message buffering is not ok with these environments:

• rsyslog version: 8.2001.0, platform: Ubuntu 20.04
• rsyslog version: 8.1911.0, platform: CentOS 8
• rsyslog version: 8.1901.0, platform: Debian 10

Message buffering is ok with these environments:

• rsyslog version: 8.24.0, platform CentOS 7
• rsyslog version: 8.24.0, platform Debian 9

Log server is 8.1901.0 on Debian 10

Configuration:

$ModLoad imuxsock # local message reception
$WorkDirectory /var/spool/rsyslog # default location for work (spool) files
$ActionQueueType LinkedList # use asynchronous processing
$ActionQueueFileName srvrfwd # set file name, also enables disk mode
$ActionResumeRetryCount -1 # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
*.* @@logger:514

I run into the issue during integration testing of an Ansible module with Molecule. The client configuration differs from the example in the documentation, the behavior is the same:

$ModLoad imuxsock             # local message reception
*.*  action(type="omfwd" target="logger" port="514" protocol="tcp"
            action.resumeRetryCount="-1"
            queue.spoolDirectory="/var/spool/rsyslog"
            queue.type="linkedList"
            queue.size="20000"
            queue.filename="logger"
            queue.maxFileSize="16m"
            queue.saveOnShutdown="on"
     )

[BenGig]

Found that the 1st message during downtime is lost, but subsequent messages are retained and sent after the server is up again.

This is ok for me, it's just TCP and not RELP grade reliability. Maybe someone wants to comment this behavior before closing this issue.

[rgerhards]

Sorry for the bad news, but works as expected. Details: https://rainer.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html

If your traffic is low, setting ResendLastMSGOnReconnect="on" may "resolve" your issue. But as above link says, there is no guarantee at all. Param doc: https://www.rsyslog.com/doc/v8-stable/configuration/modules/omfwd.html