On Sat, Jan 18, 2014 at 12:44 AM, Assaf Gordon <[email protected]> wrote:
> Hello David,
>
>
> On 01/17/2014 06:15 PM, David Lang wrote:
>
>> On Fri, 17 Jan 2014, Assaf Gordon wrote:
>>
>> BUT,
>>> If I understood the idea behind "RELP" correctly, the client-side
>>> "rsyslogd" should know and detect that those messages were not ACK'd,
>>> hence not delivered.
>>>
>>
>> your understanding matches mine that only message 11 should be lost.
>>
>> Are you sure the other messages are not being sent? the order of the
>> messages is not preserved so they will show up out of order.
>>
>>
> I'm not sure, but I've waited more than a minute.
> Is there a longer expected re-transmission time?
>
>
> we would want to look at the configuration and possibly debug log on the
>> sending system. It's possible that it's not configured to keep messages
>> that it runs into delivery failures on. If you have a client that's only
>> sending these test messages, the debug logs should be reasonable to go
>> through.
>>
>
> I did not configure any special cases for failures (not sure how to do
> that).
>
> My configuration is extremely simple (I even disabled "tls" just to be
> safe).
>
>
> Server side:
> --
> module(load="imrelp" ruleset="relp")
> input(type="imrelp" port="20517" tls="off")
>
> ruleset (name="relp") { action(type="omfile" file="/tmp/server.log") }
> --
>
> Client side:
> --
> module(load="imuxsock" SysSock.Use="off")
> module(load="omrelp")
> input(type="imuxsock" Socket="/tmp/client.sock" CreatePath="on")
> action(type="omrelp" target="1.2.3.4" port="20517" tls="off")
>
This does not request retries on delivery failuere. So it does the default
and that is discard if the target cannot be reached. Check the resumeretry
family of setting here:
http://www.rsyslog.com/doc/rsyslog_conf_actions.html
Rainer
--
>
> I've created logs of rsyslogd (with "-n -d").
>
> The client side log:
> http://pastebin.com/784EHw0J
>
> Server side Log, Part 1 (message 1 to 11, then server killed):
> http://pastebin.com/i2F1rd8W
>
> Server side Log, Part 2 (messages 44 to 50, a new server process):
> http://pastebin.com/aGGqF1CV
>
>
> If you lookup the text "Message 13" in the client log, what follows is the
> disconnect ("relp session 0xcbfa30 flagged as broken, IO error").
>
> Then lookup the text "Message 43" - just above it is the reconnection to
> the new server process.
>
>
>
> It's also possible that you are running into some other problem. what
>> version are you running?
>>
>
> I'm using:
> librelp 1.2.2
> libee 0.4.1
> libestr 0.1.9
> libjsonc 0.11
> liblognorm 0.3.7
> rsyslogd 7.5.8
>
> All compiled from source.
>
> rsyslogd was configured with:
> ./configure "--enable-regexp",
> "--enable-zlib",
> "--enable-inet",
> "--enable-unlimited-select",
> "--enable-usertools",
> "--enable-uuid",
> "--enable-gnutls",
> "--enable-mail",
> "--enable-mmnormalize",
> "--enable-mmjsonparse",
> "--enable-relp",
> "--enable-imfile",
> "--enable-imptcp",
> "--enable-imttcp",
> "--enable-impstats",
> "--enable-omstdout",
> "--enable-omruleset"
>
> Many thanks,
> -gordon
>
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
> DON'T LIKE THAT.
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
