Looks like I cracked my problem. I now reliably get logs send to my server
regardless of how I break the connection between server and client, and
regardless of the number of messages.
My config on the client:
action( type="omrelp"
name="logtoserver"
target="192.168.8.134"
port="514"
queue.size="5000"
queue.type="LinkedList"
queue.spoolDirectory="/var/lib/rsyslog"
queue.filename="testforwardingqueue"
queue.lowwatermark="2000"
queue.highwatermark="3500"
queue.discardmark="5000"
queue.maxfilesize="1g"
queue.saveonshutdown="on"
action.ResumeInterval="10"
action.ResumeRetryCount="-1"
action.reportSuspension="on"
action.reportSuspensionContinuation="on"
)
What did the trick in the end was looking at the queue settings by running
rsyslog in debug mode and noticing that the action settings were "unset". I
expected them to be set to default values but this has turned out not to be
the case so a bit of a gotcha.
With regards to the debugging I had to do the following to get debugging
working as I wanted:
( Assuming RH7 with latest rsyslog installed, not the OS supplied version )
systemctl disable rsyslog
systemctl stop rsyslog
rsyslogd -dn
I hope this helps someone in the future. Any comments on the queue values
being set to "unset" would be appreciated. Is it on purpose, or a bug in my
config or related to mixing old and new config?
Regards
On 21 July 2015 at 14:05, Gerhardus Geldenhuis <
[email protected]> wrote:
> Hi
> I have not been able to figure out yet why the firewall would cause me to
> loose packets send by rsyslog. I thought I would write a summary for anyone
> reading this thread later on.
>
> In summary this is what I have done so far:
> Client Config:
> module(load="imuxsock") # provides support for local system logging (e.g.
> via logger command)
> module(load="imklog") # provides kernel logging support (previously done
> by rklogd)
> module(load="omrelp")
> module(load="impstats" interval="10" severity="7")
>
> if $syslogtag contains 'rsyslogd-pstats' then {
> action(type="omfile" queue.type="linkedlist" queue.discardmark="980"
> name="pstats" file="/var/log/pstats")
> stop
> }
>
> #### GLOBAL DIRECTIVES ####
> $IncludeConfig /etc/rsyslog.d/*.conf
>
> #### RULES ####
>
> *.info;mail.none;authpriv.none;cron.none /var/log/messages
> authpriv.* /var/log/secure
> mail.* /var/log/maillog
> cron.* /var/log/cron
> *.emerg :omusrmsg:*
> uucp,news.crit /var/log/spooler
> local7.* /var/log/boot.log
> action( type="omrelp"
> name="logtoserver"
> target="192.168.8.134"
> port="514"
> queue.size="500"
> queue.type="LinkedList"
> queue.spoolDirectory="/var/lib/rsyslog"
> queue.filename="testforwardingqueue"
> queue.lowwatermark="200"
> queue.highwatermark="350"
> queue.discardmark="500"
> queue.maxfilesize="1g"
> queue.saveonshutdown="on"
> )
>
> Server Config:
> module(load="imuxsock") # provides support for local system logging (e.g.
> via logger command)
> module(load="imklog") # provides kernel logging support (previously done
> by rklogd)
> module(load="imrelp")
> input(type="imrelp" port="514")
> $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
> $IncludeConfig /etc/rsyslog.d/*.conf
> *.info;mail.none;authpriv.none;cron.none /var/log/messages
> authpriv.* /var/log/secure
> mail.* /var/log/maillog
> cron.* /var/log/cron
> *.emerg :omusrmsg:*
> uucp,news.crit /var/log/spooler
> local7.* /var/log/boot.log
>
>
> My test methodology is as follows:
>
> 1. Start firewall on rsyslog server
> 2. Run for loop: for i in $(seq 1 600); do logger -p error
> "############### TESTING ########### SEQ005-${i}"; done
> 1. Change SEQ number as required
> 3. Stop firewall
> 4. Wait for logs to come across
> 5. Run grep SEQ### -c /var/log/messages on rsyslog server.
>
> I am expecting to see a count of 600 when I do so but I get 249. I
> consistently get 249 and if I change my queue sizes I get a bigger number
> but also consistently the same value. So I loose messages but a predictable
> amount.
>
> If I do the same test but I disable the networking on the server then I
> get all 600 messages or whatever amount I have send. So it seems that for
> some strange reason firewalld causes me to loose messages but not quite
> sure why. I have done a tcpdump but there is nothing there that
> particularly jumps out at me.
>
> Regards
>
> On 15 July 2015 at 11:13, Gerhardus Geldenhuis <
> [email protected]> wrote:
>
>> I can't see any firwalld related issues. What is interesting is that
>> running: systemctl stop rsyslog on the server seems to cause issues. I
>> can't run systemctl start rsyslog and get an error:
>> systemctl start rsyslog
>> A dependency job for rsyslog.service failed. See 'journalctl -xn' for
>> details.
>>
>> If I run: systemctl enable rsyslog I don't get the error any more but I
>> then if I run systemctl stop rsyslog it does not stop... it becomes a
>> vampire which I can't kill. I don't have any silver bullets.
>>
>> Regards
>>
>> On 15 July 2015 at 10:55, Gerhardus Geldenhuis <
>> [email protected]> wrote:
>>
>>> Hmmmm,
>>> There should not be... it is firewalld and I don't think it limits
>>> connections. I can dig around a bit more to see if there is something else
>>> that would do that or cause it to happen. It is suppose to be vanilla
>>> firewalld...
>>>
>>> I will do another test where I shutdown rsyslog on the remote server and
>>> see what happens.
>>>
>>> Regards
>>>
>>> On 15 July 2015 at 10:36, Rainer Gerhards <[email protected]>
>>> wrote:
>>>
>>>> 2015-07-15 11:33 GMT+02:00 Gerhardus Geldenhuis
>>>> <[email protected]>:
>>>> > I have made a bit of progress...
>>>> > 2015-07-14T19:53:26.374223+01:00 rclient rsyslogd-pstats: logtoserver
>>>> > queue[DA]: origin=core.queue size=0 enqueued=15232 full=0
>>>> discarded.full=0
>>>> > discarded.nf=0 maxqsize=15232
>>>> > 2015-07-14T19:53:26.374227+01:00 rclient rsyslogd-pstats: logtoserver
>>>> > queue: origin=core.queue size=24642 enqueued=56608 full=0
>>>> discarded.full=0
>>>> > discarded.nf=0 maxqsize=35002
>>>> >
>>>> > Those lines show that the DA queue has a smaller max queue size of
>>>> 15232.
>>>> > If I subtract that from 40 000 I get 24 768 which is the exact amount
>>>> of
>>>> > messages that I get on the remote server. The max queue size value is
>>>> thus
>>>> > the number of messages that I seem to loose or not get on the remote
>>>> server.
>>>> >
>>>> > I don't have a solution yet but I think that will give some guidance
>>>> as to
>>>> > where things are going wrong ( I suspect in my config and/or
>>>> assumptions )
>>>>
>>>> Not a solution, but a thought: This looks like the remote end does not
>>>> accept the additional connection the DA queue tries to make. I have
>>>> seen similar effects during testing when running against nc, which
>>>> only permits one connection. Something in the firewall that limits
>>>> that?
>>>>
>>>> Rainer
>>>> >
>>>> > Regards
>>>> >
>>>> > On 15 July 2015 at 09:58, Gerhardus Geldenhuis <
>>>> > [email protected]> wrote:
>>>> >
>>>> >> Hi
>>>> >> I am attaching a pstats file here as requested.
>>>> >>
>>>> >> I configured pstats to log every 10 seconds and the queue that
>>>> forwards to
>>>> >> the remote host is called:
>>>> >> action( type="omrelp"
>>>> >> name="logtoserver"
>>>> >> target="192.168.8.134"
>>>> >> port="514"
>>>> >> queue.size="50000"
>>>> >> queue.type="LinkedList"
>>>> >> queue.spoolDirectory="/var/lib/rsyslog"
>>>> >> queue.filename="testforwardingqueue"
>>>> >> queue.lowwatermark="20000"
>>>> >> queue.highwatermark="35000"
>>>> >> queue.discardmark="50000"
>>>> >> queue.maxfilesize="1g"
>>>> >> queue.saveonshutdown="on"
>>>> >> # queue.fulldelaymark="2500"
>>>> >> )
>>>> >>
>>>> >> My process were:
>>>> >> Start firewall on remote server to block syslog
>>>> >>
>>>> >> Run script:
>>>> >>
>>>> >> #!/bin/bash
>>>> >>
>>>> >> echo '' > /var/log/pstats
>>>> >>
>>>> >> echo "" >> /var/log/pstats
>>>> >> echo "BEGINING of TEST with SEQ-${1}" >> /var/log/pstats
>>>> >> echo "" >> /var/log/pstats
>>>> >>
>>>> >> echo 'Starting log storm'
>>>> >> for i in $(seq 1 40000); do logger -p error "############### TESTING
>>>> >> ########### SEQ${1}-${i}"; done
>>>> >>
>>>> >> echo "" >> /var/log/pstats
>>>> >> echo "END of TEST with SEQ-${1}" >> /var/log/pstats
>>>> >> echo "" >> /var/log/pstats
>>>> >>
>>>> >> after having run the script, I then stopped the firewall and waited
>>>> for
>>>> >> the logs to flush. Some logs flushed and after I saw them appear in
>>>> the
>>>> >> remote server I stopped rsyslog on the client and took a copy of the
>>>> pstats
>>>> >> file.
>>>> >>
>>>> >> I am trawling through the pstats file now but hopefully you might
>>>> have
>>>> >> some useful tool that can make it easier on your side and if not
>>>> experience
>>>> >> will always reveal things quicker.
>>>> >>
>>>> >> Regards
>>>> >>
>>>> >> On 14 July 2015 at 17:12, Rainer Gerhards <[email protected]>
>>>> >> wrote:
>>>> >>
>>>> >>> 2015-07-14 17:32 GMT+02:00 Gerhardus Geldenhuis
>>>> >>> <[email protected]>:
>>>> >>> > Thanks David,
>>>> >>> > I configured RELP but it has not made a difference...
>>>> >>> >
>>>> >>> > More specifically if I turn on the firewall by
>>>> >>> >
>>>> >>> > 1. running: systemctl start firewalld on the master server
>>>> >>> > 2. and then start generating 40 000 log entries on the client,
>>>> and
>>>> >>> wait
>>>> >>> > for it to finish
>>>> >>> > 3. run: systemctl stop firewalld
>>>> >>> > 4. Wait for logs to come over
>>>> >>> > 5. Count logs
>>>> >>> >
>>>> >>> > I still get 24767 messages instead of 40000.
>>>> >>>
>>>> >>> can you share the impstats data with us? We may get a better
>>>> >>> understanding of what's going on based on it...
>>>> >>>
>>>> >>> Rainer
>>>> >>> >
>>>> >>> > If however I physically turn of the network on the master machine
>>>> using
>>>> >>> > VMWare, I do get 40 000 messages when I connect the network back
>>>> again.
>>>> >>> >
>>>> >>> > So why is RELP handling it like this surely if it does not get any
>>>> >>> response
>>>> >>> > from the firewall for if the firewall sends it to a black hole
>>>> then it
>>>> >>> > should not mark messages as delivered. I am also willing to admit
>>>> that
>>>> >>> my
>>>> >>> > testing methodology is flawed but then I would like to understand
>>>> why
>>>> >>> > exactly and at the moment I feel my testing methodology
>>>> represents a
>>>> >>> real
>>>> >>> > world scenario which would make loosing logs a reality even if
>>>> you use
>>>> >>> RELP.
>>>> >>> >
>>>> >>> > Importantly I enable the firewall before starting the log test so
>>>> it
>>>> >>> should
>>>> >>> > all be blocked from the very beginning.
>>>> >>> >
>>>> >>> > Regards
>>>> >>> >
>>>> >>> > On 14 July 2015 at 12:44, David Lang <[email protected]> wrote:
>>>> >>> >
>>>> >>> >> One issue you are probably running into is the fact that TCP is
>>>> not
>>>> >>> >> reliable enough. TCP is 'reliable' in that if a packet gets
>>>> dropped it
>>>> >>> will
>>>> >>> >> detect and re-send it as part of the same connection, but there
>>>> is a
>>>> >>> >> problem when the connection is interrupted (as it is in your
>>>> test by
>>>> >>> the
>>>> >>> >> firewall)
>>>> >>> >>
>>>> >>> >> When the sending rsyslog hands the message to the OS on the
>>>> sending
>>>> >>> >> system, it is told "yes, I have this and will deliver it" by the
>>>> OS.
>>>> >>> But if
>>>> >>> >> the OS is unable to deliver it (because the network connection
>>>> breaks),
>>>> >>> >> there is no way for the OS to go back to the sending application
>>>> and
>>>> >>> say
>>>> >>> >> "oops, I really can't get this through to the other end" so the
>>>> >>> messages
>>>> >>> >> are lost.
>>>> >>> >>
>>>> >>> >> This is what the RELP protocol was developed to fix. It does
>>>> >>> application
>>>> >>> >> level acks for the messages so that if the network is
>>>> interrupted, it
>>>> >>> knows
>>>> >>> >> what messages didn't get through and will re-send them. switch to
>>>> >>> >> omrelp/imrelp instead of omfwd/imtcp and you should avoid
>>>> loosing any
>>>> >>> >> messages
>>>> >>> >>
>>>> >>> >> If you make the firewall send resets rather than dropping
>>>> packets, the
>>>> >>> >> sending machine will detect the problem faster.
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> This would account for some messages being lost between the time
>>>> that
>>>> >>> you
>>>> >>> >> ahve the firewall block the connection and the time that rsyslog
>>>> >>> detects
>>>> >>> >> this. But once rsyslog detects this and starts queueing
>>>> messages, those
>>>> >>> >> messages should be sent when rsyslog re-establishes the
>>>> connection.
>>>> >>> >>
>>>> >>> >> enable impstats writing stats rapidly (say every 10 seconds or
>>>> so for
>>>> >>> >> testing)
>>>> >>> >>
>>>> >>> >> then block the connection and send a small number of messages
>>>> until
>>>> >>> >> rsyslog logs locally that it's unable to send and the queue for
>>>> the
>>>> >>> action
>>>> >>> >> starts filling.
>>>> >>> >>
>>>> >>> >> then do your write of 40000 test messages
>>>> >>> >>
>>>> >>> >> then open the firewall and you should see all the messages get
>>>> sent
>>>> >>> once
>>>> >>> >> rsyslog retries and notices that the connection is open again.
>>>> >>> >>
>>>> >>> >> David Lang
>>>> >>> >>
>>>> >>> >> On Tue, 14 Jul 2015, Gerhardus Geldenhuis wrote:
>>>> >>> >>
>>>> >>> >> Date: Tue, 14 Jul 2015 11:20:46 +0100
>>>> >>> >>> From: Gerhardus Geldenhuis <[email protected]>
>>>> >>> >>> Reply-To: rsyslog-users <[email protected]>
>>>> >>> >>> To: rsyslog-users <[email protected]>
>>>> >>> >>> Subject: Re: [rsyslog] Disk queue to flush after restart
>>>> >>> >>>
>>>> >>> >>> Hi,
>>>> >>> >>> I don't seem to be making as much progress as I would hope for.
>>>> I now
>>>> >>> have
>>>> >>> >>> the following client config:
>>>> >>> >>> action( type="omfwd"
>>>> >>> >>> target="192.168.8.134"
>>>> >>> >>> port="514"
>>>> >>> >>> protocol="tcp"
>>>> >>> >>> queue.size="50000"
>>>> >>> >>> queue.type="LinkedList"
>>>> >>> >>> queue.spoolDirectory="/var/lib/rsyslog"
>>>> >>> >>> queue.filename="testforwardingqueue"
>>>> >>> >>> queue.lowwatermark="20000"
>>>> >>> >>> queue.highwatermark="35000"
>>>> >>> >>> queue.discardmark="50000"
>>>> >>> >>> queue.maxfilesize="1g"
>>>> >>> >>> queue.saveonshutdown="on"
>>>> >>> >>> # queue.fulldelaymark="2500"
>>>> >>> >>> )
>>>> >>> >>>
>>>> >>> >>> I have made the numbers smaller to be able to do testing that
>>>> will
>>>> >>> finish
>>>> >>> >>> in a reasonable amount of time.
>>>> >>> >>>
>>>> >>> >>> My process is:
>>>> >>> >>>
>>>> >>> >>> 1. Start firewall on master server to block all access.
>>>> >>> >>> 2. On client server start logging using: for i in $(seq 1
>>>> 40000); do
>>>> >>> >>> logger -p error "############### TESTING ###########
>>>> SEQ001-${i}";
>>>> >>> done
>>>> >>> >>> 3. Wait for for loop to finish and check if all entries are
>>>> >>> contained
>>>> >>> >>> locally
>>>> >>> >>> 4. watch 'ls -l /var/lib/rsyslog' to see if queue gets
>>>> created.
>>>> >>> >>> 5. Disable firewall on master
>>>> >>> >>> 6. run logger -p error with one message to get logs going
>>>> again
>>>> >>> >>> 7. Wait for logs to arrive on master server
>>>> >>> >>> 8. grep 'SEQ001' /var/log/messages -c
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> The problem I am getting is that the number of messages I
>>>> receive on
>>>> >>> the
>>>> >>> >>> remote server does not correspond with what I get on the master
>>>> >>> server.
>>>> >>> >>> I only get 24768 messages on the master server.
>>>> >>> >>>
>>>> >>> >>> Is there anything else that I have missed out of the
>>>> configuration? I
>>>> >>> >>> can't
>>>> >>> >>> see anything that would cause my messages to not arrive. The
>>>> queue
>>>> >>> file I
>>>> >>> >>> specified grows in size but interestingly when I grep'ed it for
>>>> >>> SEQ005 I
>>>> >>> >>> only get 15232 matches. I did the grep after re-enabling the
>>>> firewall.
>>>> >>> >>>
>>>> >>> >>> I thought that it might be because syslog thinks my messages
>>>> are the
>>>> >>> same
>>>> >>> >>> and then marks them as duplicates. I then added:
>>>> >>> >>> for i in $(seq 1 40000); do logger -p error "###############
>>>> TESTING
>>>> >>> >>> ########### SEQ005-${i}-$(openssl rand -base64 32)"; done
>>>> >>> >>>
>>>> >>> >>> to try and prevent that. However if the firewall is not enabled
>>>> then
>>>> >>> all
>>>> >>> >>> 40k messages arrive on the master server.
>>>> >>> >>>
>>>> >>> >>> Any help would be appreciated.
>>>> >>> >>>
>>>> >>> >>> Regards
>>>> >>> >>>
>>>> >>> >>> On 13 July 2015 at 14:20, Rainer Gerhards <
>>>> [email protected]>
>>>> >>> >>> wrote:
>>>> >>> >>>
>>>> >>> >>> 2015-07-13 15:18 GMT+02:00 Gerhardus Geldenhuis
>>>> >>> >>>> <[email protected]>:
>>>> >>> >>>>
>>>> >>> >>>>> Hi,
>>>> >>> >>>>> Thanks for the replies. I think the bulk of my problem was
>>>> mixing
>>>> >>> old
>>>> >>> >>>>> and
>>>> >>> >>>>> new config and I much further along to get something working.
>>>> I have
>>>> >>> >>>>> discovered a few other niggles but will report back once I
>>>> have
>>>> >>> >>>>> something
>>>> >>> >>>>> working properly. As far as pull requests go, I would really
>>>> >>> consider
>>>> >>> >>>>>
>>>> >>> >>>> doing
>>>> >>> >>>>
>>>> >>> >>>>> so but as always time is a factor.
>>>> >>> >>>>>
>>>> >>> >>>>
>>>> >>> >>>> yup - for everyone ;) And that is what it is like it currently
>>>> is ;)
>>>> >>> >>>>
>>>> >>> >>>> It does bug me so much that I must just
>>>> >>> >>>>> end up doing it for the documentation. I will give debug mode
>>>> a go.
>>>> >>> >>>>>
>>>> >>> >>>>> Regards
>>>> >>> >>>>>
>>>> >>> >>>>> On 13 July 2015 at 13:17, Rainer Gerhards <
>>>> [email protected]
>>>> >>> >
>>>> >>> >>>>>
>>>> >>> >>>> wrote:
>>>> >>> >>>>
>>>> >>> >>>>>
>>>> >>> >>>>> 2015-07-10 13:40 GMT+02:00 Gerhardus Geldenhuis
>>>> >>> >>>>>> <[email protected]>:
>>>> >>> >>>>>>
>>>> >>> >>>>>>> Hi
>>>> >>> >>>>>>> I am struggling a bit to get rsyslog to work as described.
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> <rant>
>>>> >>> >>>>>>> Firstly the documentation is a struggle. There is some
>>>> reference
>>>> >>> to
>>>> >>> >>>>>>>
>>>> >>> >>>>>> old
>>>> >>> >>>>
>>>> >>> >>>>> and
>>>> >>> >>>>>>
>>>> >>> >>>>>>> new style configuration but no clear differentiation
>>>> between the
>>>> >>> two.
>>>> >>> >>>>>>>
>>>> >>> >>>>>> What
>>>> >>> >>>>>>
>>>> >>> >>>>>>> makes it more confusing is that documents like
>>>> >>> >>>>>>> http://www.rsyslog.com/doc/queues.html then refers to what
>>>> looks
>>>> >>> like
>>>> >>> >>>>>>>
>>>> >>> >>>>>> the
>>>> >>> >>>>>>
>>>> >>> >>>>>>> old style of config and none of the examples contains new
>>>> syntax
>>>> >>> >>>>>>>
>>>> >>> >>>>>> examples.
>>>> >>> >>>>>>
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> There was also an expectation that the new rsyslog package
>>>> would
>>>> >>> >>>>>>>
>>>> >>> >>>>>> install
>>>> >>> >>>>
>>>> >>> >>>>> a
>>>> >>> >>>>>>
>>>> >>> >>>>>>> new style config but that turned out to be not the case. I
>>>> >>> deleted the
>>>> >>> >>>>>>> config file and did a yum reinstall just to be sure.
>>>> >>> >>>>>>> </rant>
>>>> >>> >>>>>>>
>>>> >>> >>>>>>
>>>> >>> >>>>>> well, this is open source. Pull requests are always
>>>> appreciated,
>>>> >>> >>>>>> anything else happens as time permits ;)
>>>> >>> >>>>>>
>>>> >>> >>>>>>
>>>> >>> >>>>>>> OS: CentOS 7
>>>> >>> >>>>>>> RSyslog:
>>>> >>> >>>>>>> rsyslog-8.11.0-1.el7.x86_64
>>>> >>> >>>>>>> rsyslog-relp-8.11.0-1.el7.x86_64
>>>> >>> >>>>>>> rsyslog-gnutls-8.11.0-1.el7.x86_64
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> So basically what I am trying to achieve is the following:
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> - Log remotely to a rsyslog server
>>>> >>> >>>>>>> - Turn off the remote server ( via firewall )
>>>> >>> >>>>>>> - Have logs be cached locally and saved to disk
>>>> >>> >>>>>>> - Restart client server
>>>> >>> >>>>>>> - Turn remote server back on
>>>> >>> >>>>>>> - See cached logs appear in the remote server
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> It does not work...
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> - So more specifically, if I turn the firewall off, log
>>>> a few
>>>> >>> >>>>>>>
>>>> >>> >>>>>> messages
>>>> >>> >>>>
>>>> >>> >>>>> and turn it back on then the caching works and I get the
>>>> >>> messages.
>>>> >>> >>>>>>> - If however I restart the client server, the logs never
>>>> make
>>>> >>> it to
>>>> >>> >>>>>>>
>>>> >>> >>>>>> the
>>>> >>> >>>>>>
>>>> >>> >>>>>>> remote sever, I can see the logs in the cached file but
>>>> it
>>>> >>> does not
>>>> >>> >>>>>>>
>>>> >>> >>>>>> get
>>>> >>> >>>>>>
>>>> >>> >>>>>>> send to the remote server.
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> My config on the client:
>>>> >>> >>>>>>> #### MODULES ####
>>>> >>> >>>>>>> module(load="imuxsock") # provides support for local system
>>>> >>> logging
>>>> >>> >>>>>>>
>>>> >>> >>>>>> (e.g.
>>>> >>> >>>>
>>>> >>> >>>>> via logger command)
>>>> >>> >>>>>>> module(load="imklog") # provides kernel logging support
>>>> >>> (previously
>>>> >>> >>>>>>>
>>>> >>> >>>>>> done
>>>> >>> >>>>>>
>>>> >>> >>>>>>> by rklogd)
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> #### GLOBAL DIRECTIVES ####
>>>> >>> >>>>>>> $IncludeConfig /etc/rsyslog.d/*.conf
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> #### RULES ####
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> *.info;mail.none;authpriv.none;cron.none
>>>> >>> >>>>>>>
>>>> >>> >>>>>> /var/log/messages
>>>> >>> >>>>
>>>> >>> >>>>> authpriv.*
>>>> >>> >>>>>>>
>>>> >>> >>>>>> /var/log/secure
>>>> >>> >>>>
>>>> >>> >>>>> mail.*
>>>> >>> >>>>>>>
>>>> >>> >>>>>> /var/log/maillog
>>>> >>> >>>>
>>>> >>> >>>>> cron.*
>>>> >>> /var/log/cron
>>>> >>> >>>>>>> *.emerg
>>>> >>> :omusrmsg:*
>>>> >>> >>>>>>> uucp,news.crit
>>>> >>> >>>>>>>
>>>> >>> >>>>>> /var/log/spooler
>>>> >>> >>>>
>>>> >>> >>>>> local7.*
>>>> >>> >>>>>>>
>>>> >>> >>>>>> /var/log/boot.log
>>>> >>> >>>>
>>>> >>> >>>>>
>>>> >>> >>>>>>> # ### begin forwarding rule ###
>>>> >>> >>>>>>> $WorkDirectory /var/lib/rsyslog # where to place spool files
>>>> >>> >>>>>>> $MainMsgQueueFileName LocalCaching # unique name prefix for
>>>> spool
>>>> >>> >>>>>>>
>>>> >>> >>>>>> files
>>>> >>> >>>>
>>>> >>> >>>>> $MainMsgQueueSaveOnShutdown on # save messages to disk on
>>>> shutdown
>>>> >>> >>>>>>> # $MainMsgQueueType LinkedList
>>>> >>> >>>>>>> $MainMsgQueueType Disk
>>>> >>> >>>>>>> $MainMsgResumeRetryCount -1 # infinite retries if host
>>>> is down
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> *.* @@192.168.8.253:514
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> # ### end of the forwarding rule ###
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> My config on the remote server:
>>>> >>> >>>>>>> module(load="imuxsock") # provides support for local system
>>>> >>> logging
>>>> >>> >>>>>>>
>>>> >>> >>>>>> (e.g.
>>>> >>> >>>>
>>>> >>> >>>>> via logger command)
>>>> >>> >>>>>>> module(load="imklog") # provides kernel logging support
>>>> >>> (previously
>>>> >>> >>>>>>>
>>>> >>> >>>>>> done
>>>> >>> >>>>>>
>>>> >>> >>>>>>> by rklogd)
>>>> >>> >>>>>>> module(load="imtcp") # needs to be done just once
>>>> >>> >>>>>>> input(type="imtcp" port="514")
>>>> >>> >>>>>>> $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
>>>> >>> >>>>>>> $IncludeConfig /etc/rsyslog.d/*.conf
>>>> >>> >>>>>>> *.info;mail.none;authpriv.none;cron.none
>>>> >>> >>>>>>>
>>>> >>> >>>>>> /var/log/messages
>>>> >>> >>>>
>>>> >>> >>>>> authpriv.*
>>>> >>> >>>>>>>
>>>> >>> >>>>>> /var/log/secure
>>>> >>> >>>>
>>>> >>> >>>>> mail.*
>>>> >>> >>>>>>>
>>>> >>> >>>>>> /var/log/maillog
>>>> >>> >>>>
>>>> >>> >>>>> cron.*
>>>> >>> /var/log/cron
>>>> >>> >>>>>>> *.emerg
>>>> >>> :omusrmsg:*
>>>> >>> >>>>>>> uucp,news.crit
>>>> >>> >>>>>>>
>>>> >>> >>>>>> /var/log/spooler
>>>> >>> >>>>
>>>> >>> >>>>> local7.*
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> Any pointers would be appreciated. I am hoping I am missing
>>>> >>> something
>>>> >>> >>>>>>> obvious or misunderstanding what I am suppose to be doing.
>>>> >>> >>>>>>>
>>>> >>> >>>>>>>
>>>> >>> >>>>>> You should run rsyslog in such a situation in debug
>>>> mode.From the
>>>> >>> >>>>>> debug log, we can see why it thinks it can't deliver to the
>>>> remote
>>>> >>> >>>>>> system (well, hopefully ;)).
>>>> >>> >>>>>>
>>>> >>> >>>>>> HTH
>>>> >>> >>>>>> Rainer
>>>> >>> >>>>>>
>>>> >>> >>>>>> Regards
>>>> >>> >>>>>>>
>>>> >>> >>>>>>> --
>>>> >>> >>>>>>> Gerhardus Geldenhuis
>>>> >>> >>>>>>> _______________________________________________
>>>> >>> >>>>>>> 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.
>>>> >>> >>>>>>
>>>> >>> >>>>>>
>>>> >>> >>>>>
>>>> >>> >>>>>
>>>> >>> >>>>> --
>>>> >>> >>>>> Gerhardus Geldenhuis
>>>> >>> >>>>> _______________________________________________
>>>> >>> >>>>> 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.
>>>> >>> >>>>
>>>> >>> >>>>
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> _______________________________________________
>>>> >>> >> 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.
>>>> >>> >>
>>>> >>> >
>>>> >>> >
>>>> >>> >
>>>> >>> > --
>>>> >>> > Gerhardus Geldenhuis
>>>> >>> > _______________________________________________
>>>> >>> > 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.
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Gerhardus Geldenhuis
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Gerhardus Geldenhuis
>>>> > _______________________________________________
>>>> > 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.
>>>>
>>>
>>>
>>>
>>> --
>>> Gerhardus Geldenhuis
>>>
>>
>>
>>
>> --
>> Gerhardus Geldenhuis
>>
>
>
>
> --
> Gerhardus Geldenhuis
>
--
Gerhardus Geldenhuis
_______________________________________________
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.
