error message from docker container itself: Error in the push function.

[JLarky]

I'm getting errors that are internal for syslog. Here's the error:

severity: Error
timestamp: 2016-03-07T17:57:59.638236+00:00
facility: messages generated internally by syslogd
priority: 43
host: 17010d56a5f9
unparsed:
message: unexpected GnuTLS error -53 in nsd_gtls.c:1618: Error in the push function. [v8.9.0 try http://www.rsyslog.com/e/2078 ]

I use docker like that (docker-compose format):

loggly-docker:
  restart: always
  image: sendgridlabs/loggly-docker
  ports:
   - 514/udp
  environment:
   - TAG=MyTag
   - TOKEN=xxxx

it also sends some other non application specific messages like:

action 'action 1' resumed (module 'builtin:omfwd') [v8.9.0 try http://www.rsyslog.com/e/2359 ]
-- MARK --

but I'm ok with those since at least they don't say "error" in them :)

[jonathan-short]

Can you compare the two images "sendgridlabs/loggly-docker:1.3" and "sendgridlabs/loggly-docker:1.4" to see if the behavior is the same in both?

[JLarky]

it seems that 1.3 is no longer available on docker hub

[jonathan-short]

Ah - that's unexpected I haven't done anything to make then unavailable.

I pushed up a rebuilt 1.3 with the tag '1.3-rebuild'. If you could compare that to 1.4 that'd be an interesting data point. There was an upgrade of the alpine base image and a minor change to the rsyslog config between the two.

[JLarky]

I was going to ask you how do you do that :))

I started two containers, one with latest and one with 1.3-rebuild, I will let you know

[JLarky]

I had two containers running, and as you can see it behaves this way in both of them

[jonathan-short]

Thanks for doing the comparison - I wanted to be sure it wasn't broken by the recent changes and it looks like it wasn't.

It looks like the containers may both exhibit the problem at about the same time.

Unfortunately I don't have any insight into rsyslog's log message or internals. My best guess is that this is a network error of some kind? Perhaps you could pursue an answer upstream with rsyslog?

[JLarky]

Actually I see this issue in rsyslog github https://github.com/rsyslog/rsyslog/issues/846 so I guess you would just have to update image to use whatever version that was fixed in

[frederikaalund]

@JLarky I just want to let you know that I recently re-opened rsyslog/rsyslog#846 since it actually wasn't fixed in the 8.17.0 release.

[JLarky]

@jonathan-short later in rsyslog discussion they talk about http://www.rsyslog.com/doc/relp.html maybe that's what you should use for loggly instead of tcp?

[jonathan-short]

@JLarky thanks for finding and connecting to the upstream rsyslog issue. I don't see that loggly supports RELP server side, so that probably isn't a viable option. (Note - I don't work for loggly). If/when loggly does support RELP, I can consider a pull request to use it.

From the upstream issue, it sounds like network interruption is to blame, the only resolution being an improved syslog message. We can pick that up when alpine pulls in the new version.

I'll close this issue for now as it sounds like everything is working as expected.

[alex88]

Seems there is issue is still there with latest version, I still having continuous errors like

rsyslogd: unexpected GnuTLS error -53 in nsd_gtls.c:1618: Error in the push function.  [v8.9.0 try http://www.rsyslog.com/e/2078 ]
GnuTLS error: Error in the push function.

using latest version (image downloaded couple months ago)