I'm running a busy DNS server which logs queries to a remote server via rsyslog.

Due to the amount of traffic we're processing I've had to increase the rate limits in rsyslog.conf. This server is processing at peak ~1.2K DNS requests/sec, which translates to ~2Mbps outgoing traffic to the remote logger.

However, when using the $AddUnixListenSocket /var/named/chroot/dev/log rsyslog directive I see a drastic decrease in data sent to the remote server. Without this directive everything is fine, except that after an rsyslog restart the logging stops, requiring a restart of BIND as well.

It seems as if adding $AddUnixListenSocket "breaks" the rate limit increase in rsyslog. What's going on here?

Software versions: - CentOS 6.7 x86_64 - rsyslog-5.8.10-10.el6_6.x86_64 - bind-9.8.2-0.37.rc1.el6_7.2.x86_64

My /etc/rsyslog.conf:

$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$SystemLogRateLimitInterval 10
$SystemLogRateLimitBurst 15000
$ModLoad imklog   # provides kernel logging support (previously done by rklogd)
$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                                                 *
uucp,news.crit                                          /var/log/spooler
local7.*                                                /var/log/boot.log

and /etc/rsyslog.d/fwd.conf:

# keep logging after rsyslog restart
$AddUnixListenSocket /var/named/chroot/dev/log

# ### begin forwarding rule ###
# The statement between the begin ... end define a SINGLE forwarding
# rule. They belong together, do NOT split them. If you create multiple
# forwarding rules, duplicate the whole block!
# Remote Logging (we use TCP for reliable delivery)
# An on-disk queue is created for this action. If the remote host is
# down, messages are spooled to disk and sent when it is up again.
$WorkDirectory /var/lib/rsyslog # where to place spool files
$ActionQueueFileName tso_fwd # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g   # 1gb space limit (use as much as possible)
$ActionQueueMaxFileSize 100M  # AF: limit open file descriptors
$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
$ActionQueueType LinkedList   # run asynchronously
$ActionQueueTimeoutEnqueue 0  # AF: discard when queue is full
$ActionResumeRetryCount -1    # infinite retries if host is down
# remote host is: name/ip:port, e.g., port optional
#*.* @@remote-host:514
local0.* @@
& ~
# ### end of the forwarding rule ###

Well, it seems that it was indeed ignoring the rate-limiting settings.

When I added $AddUnixListenSocket the input was changed to the imuxsock module, which has its own rate-limiting settings.

The top of /etc/rsyslog.d/fwd.conf looks like:

# raise logging limits
$IMUXSockRateLimitInterval 10
$IMUXSockRateLimitBurst 15000

# keep logging after rsyslog restart
$AddUnixListenSocket /var/named/chroot/dev/log

which fixed the issue.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.