[syslog-ng] Some logs written, some are not

[Fabien Wernli]

Hi Jason,

On Fri, Jun 12, 2020 at 09:58:40AM +0200, Jason Brown wrote:
> It looks like the cause of the “Error processing log message: <-1>” was indeed the logback configuration.  Changing the priority to something valid cleans up that error.  
> Unfortunately, it looks like that wasn’t the source of the problem.  Digging in a little deeper, I’m seeing this message:
> 
> Jun 12 07:37:03 s_local at syslog syslog-ng[28873]: Syslog connection accepted; fd='19', client='AF_INET(10.13.97.36:49346)', local='AF_INET(0.0.0.0:514)'
> Jun 12 07:37:03 s_local at syslog syslog-ng[28873]: internal() messages are looping back, preventing loop by suppressing all internal messages until the current message is processed; trigger-msg='Syslog connection accepted; fd=\'19\', client=\'AF_INET(10.13.97.36:49346)\', local=\'AF_INET(0.0.0.0:514)\'', first-suppressed-msg='>>>>>> filter rule evaluation begin; rule=\'f_auth\', location=\'/etc/syslog-ng/syslog-ng.conf:136:32\', msg=\'0x11c1bc0\’’  
> 
> So I’m assuming it’s likely a flow control issue.

I've already seen this message. It's probably unrelated to your issue which
I forgot what it was about. This message means that the internal() source,
which is referenced somewhere in your configuration (explicitly or
implicitly through an scl) which contains messages from syslog-ng itself
produces a feedback loop in a log path. This snowball effect is detected by
syslog-ng and action is taken to keep syslog-ng from exploding
catastrophically ;-)

You could disable the internal() source, but usually isolating it in its
separate log path is the way to go.

Now back to your initial issue, what's happening exactly ?