[rsyslog-notify] Forum Thread: Re: RSyslog not sending messages - (Mode 'reply')

[noreply at adiscon.com]

User: lethalduck 
Forumlink: http://kb.monitorware.com/viewtopic.php?p=25198#p25198

Message: 
----------
[quote:1rkvlssv]So the replicated state is always going to lag behind. If
the connection isn't very busy, you have good odds that the state was
replicated before the router failed, but it's not as reliable as the
marketing blurbs make it sound.[/quote:1rkvlssv]

Makes sense.

[quote:1rkvlssv]I was meaning to read the links to understand the nuances
around how TCP could still loose data.[/quote:1rkvlssv]

Yeah, it's makeing sense. Everything you've said so far has made sense. I
only have so much time to read everything though :-S

[quote:1rkvlssv]what version of rsyslog[/quote:1rkvlssv]

rsyslogd 8.4.2 as mentioned in the first post.

[quote:1rkvlssv]and GnuTLS[/quote:1rkvlssv]

libcurl3-gnutls:amd64          7.38.0-4             amd64               
easy-to-use client-side URL transfer library (GnuTLS flavour)
libgnutls-deb0-28:amd64        3.3.8-5              amd64               
GNU TLS library - main runtime library
libgnutls-openssl27:amd64      3.3.8-5              amd64               
GNU TLS library - OpenSSL wrapper
libgnutls26:amd64              2.12.20-8+deb7u2     amd64               
GNU TLS library - runtime library
rsyslog-gnutls                 8.4.2-1              amd64               
TLS protocol support for rsyslog

[quote:1rkvlssv]Since it starts off working and then fails, i would guess
that there is some subtle incompatibility between the version of GnuTLS on
your machine and what's on the other end. You start off working and then
their system sends a message that your GnuTLS doesn't understand, so your
system kills the connection and reconnects.[/quote:1rkvlssv]

It sounds like papertrail don't have much insight into their own system.

"Thanks for the info, but I'm afraid I don't have a way to troubleshoot
this any better than you do. I'm totally happy to help you however I can,
but we're stuck with the same practical limitations you've got -- I can't
just reconstruct TCP streams :(
We run end-to-end blackbox monitoring with "canary" log messages[1], so I
can say that Papertrail itself isn't dropping inbound messages. Something
here doesn't line up, but I don't have a way to say what.
[1]: That is, we actually send log messages to every single active customer
port, just like a sender, and track them through to the final step before
the data store."

Is the wireshark capture of any use to you? Do I need to be on a more
recent libcurl3-gnutls ,libgnutls-deb0-28:amd64, libgnutls-openssl27,
libgnutls26, rsyslog-gnutls? If so, it means going out of band with Debian
testing right? What's the best way to proceed with this if you think that's
what I need to do?
These are the updates by the look of it: <!-- m --><a class="postlink"
href="http://www.gnutls.org/news.html">http://www.gnutls.org/news.html</a><!--
m -->

Thanks again.