go-audit process dies frequently on a busy system

[nbommu1]

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.

Description

Hi,
go-audit process dies frequently on a server which is too busy. it work as expected on rest of the servers. so far I have increased socket buffer receive 16384 x 3 with no luck. can you help us out on this?

Failed to write message, retrying in 1 second. Error: write unixgram @->/dev/log: write: message too long
Failed to write message, retrying in 1 second. Error: write unixgram @->/dev/log: write: message too long
Failed to write message, retrying in 1 second. Error: write unixgram @->/dev/log: write: message too long
Failed to write message, retrying in 1 second. Error: write unixgram @->/dev/log: write: message too long
Failed to write message, retrying in 1 second. Error: write unixgram @->/dev/log: write: message too long
Failed to write message. Error: write unixgram @->/dev/log: write: message too long

rsyslog is allowing message size $MaxMessageSize 20k

Reproducible in:

go-audit version: current version
OS version(s):Amazon Linux AMI release 2016.09

[nbrownus]

/dev/log is a datagram socket and I don't recommend using it for this. There is a way to setup rsyslog to use a stream socket which is much better suited to go-audit message sizes.

[nbommu1]

thanks a lot,

trying with these options.

network: udp
address: localhost:514

[nbommu1]

unfortunatly died again with the same error message, cleared up error log and started, will get more info on next failure.

[nbrownus]

That would be because you are still using a datagram transport mode. If you use tcp or a unix domain socket in stream mode you will remove the transit size limit.

[nbommu1]

Thanks, I have turned on TCP reception on that server and update go-audit.yaml, things are looks good so far.
network: tcp
address: localhost:514

[nbommu1]

we have minimised logging on that server, so far things looks good.