If the timeout is because the name really doesn't exist in DNS and you get a timeout rather than a 'does not exist' message, a cacheing server won't help.

David Lang

On Sun, 9 Mar 2014, Boylan, James wrote:

Date: Sun, 9 Mar 2014 18:59:40 -0500
From: "Boylan, James" <james.boy...@orbitz.com>
Reply-To: rsyslog-users <rsyslog@lists.adiscon.com>
To: rsyslog-users <rsyslog@lists.adiscon.com>
Subject: Re: [rsyslog] rsyslog v5 blocked by dns timeout

Also, if you are having DNS timeout issues but you are sending it to the same 
place regularly, you might consider using NSCD. It will implement the DNS 
caching for you if you are unable to upgrade to a newer version of rsyslog.

-- James

________________________________________
From: rsyslog-boun...@lists.adiscon.com [rsyslog-boun...@lists.adiscon.com] On 
Behalf Of David Lang [da...@lang.hm]
Sent: Sunday, March 09, 2014 3:30 PM
To: rsyslog-users
Subject: Re: [rsyslog] rsyslog v5 blocked by dns timeout

On Sun, 9 Mar 2014, Tanky Woo wrote:

On Sun, 9 Mar 2014, Tanky Woo wrote:

rsyslog version is 5.8

I found rsyslogd will be blocked, if the remote server domain name can’t 
resolve because of timeout.

I configured the rsyslogd to send log to remote by udp:

*.* @xxx.com:514

now the name server has problem and the dns request will timeout(only timeout 
will cause this problem). the cause the rsyslogd can’t work right.

I use logger to send log, and no log will write in /var/log/syslog。

I just add the domain in /etc/hosts to solve this problem. But is there any 
other way, or is it a bug in v5?

The message where the timeout happens will eventually get into the log, but the
problem is that while it is stalled waiting for the timeout, other UDP messages
will end up getting dropped.

you can disable name resolution entirely by starting rsyslog with the -x flag
(it won't even use /etc/hosts at that point)

This is a problem with basically every syslog daemon from the beginning. Rsyslog
7+ has a DNS cache, but I'm not sure that it will cach failures, so you may
still have a problem (I think it also changes the point at which the DNS
resolution happens, so it may receive message without a problem, but then get
stuck writing them out)

David Lang
I have already setted the `-x` options:
RSYSLOGD_OPTIONS="-c5 -Q -x”
and it will still blocked.
and the manual say:
-x     Disable DNS for remote messages.
if I disable it, it will not do name resolution, how can the rsyslog to use 
xxx.com in configuration?

It depends how you are using xxx.com in your configuration. If you disable name
resolution, you don't get %fromhost%, but you still have %fromhost-ip% and if
the sender sets %hostname% in the message you can still use that.

then:
The message where the timeout happens will eventually get into the log, but the 
problem is that while it is stalled waiting for the timeout, other UDP messages 
will end up getting dropped.

If it is stalled waiting for the timeout, and the udp messages will dropped, 
why rsyslog won’t write message to file, I just move that statements to the end 
of the configuration.

the message should end up getting to the file eventually, it's other messages
that arrive during this time that will end up being dropped. This happens as
rsyslog is receiving the message to put it into the queue to be processed, it
doesn't matter where in the configuration the output is.

David Lang
_______________________________________________
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.

Reply via email to