MonitorWare Knowledge Base

Hi to all,
all of my clients log remotely on the server using TCP as transports. Logs are correctly received and write to disk.
If I stop the deamon on the server-side, the clients are expected to saturate the in-memory portion of queue and
to start writing to disk, but that does not happen.

I think to have read all the doc related to queueing but have not figured out what is wrong. Here is the interesting
portion of client configuration:

$MainMsgQueueType LinkedList
$MainMsgQueueFileName mainq
$MainMsgQueueSaveOnShutdown on
$MainMsgQueueDiscardSeverity 8

$WorkDirectory /var/spool/rsyslog # default location for work (spool) files
$ActionQueueType LinkedList # use asynchronous processing
#$ActionQueueType FixedArray # use asynchronous processing
$ActionQueueFileName srvfwd # set file name, also enables disk mode
$ActionResumeRetryCount -1 # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
$ActionQueueDiscardSeverity 8
$ActionQueueWorkerThreads 5

local7.* @@rsyslog.private:514
local7.* ~


I run the following on the client:
client# while true; do /usr/bin/logger -p local7.info -t my_tag_used_remotely "`date`"; done

In the meanwhile I stop rsyslog on the server:
server# /etc/init.d/rsyslog stop,

I keep the 'while' running on the client for several minutes, nevertheless the client does not seem to
start spooling at all.

Can anyone help me in figuring out what's wrong? If you need some further informations, debug logs,
whatever, let me know.

Thanks in advance,
Paolo Larcheri

• Custom written rsyslog.conf?
• Maintenance Contract?
• Installation support?

I don't see anything obviously wrong, except that $ActionQueueWorkerThreads should probably log an error upon startup (I don't think this directive exists).

So can you please post the "uninteresting" part of your config file(s), often the problem lurks in such places. On thing that comes to my mind immediately is if you have "last message repeated n times" compression turned off or not. If it is turned on, you actually generate one message per second with your script and so I think it will take 2000 (don't know the exact default out of my head) seconds to fill up the action queue.

Another good suggestion is the move on to a recent build - especially the queue code has undergone considerable review, so if it is a bug, chances are great it is already fixed in the recent v3-stable (you can also try the beta, it will be "stamped" v3-stable very, very soon).

HTH
Rainer

rgerhards wrote:I don't see anything obviously wrong, except that $ActionQueueWorkerThreads should probably log an error upon startup (I don't think this directive exists).

I saw it here and here. It was just a shot for being sure that it wasn't somehow a matter of starvation in serving the queues.

rgerhards wrote:So can you please post the "uninteresting" part of your config file(s), often the problem lurks in such places. On thing that comes to my mind immediately is if you have "last message repeated n times" compression turned off or not. If it is turned on, you actually generate one message per second with your script and so I think it will take 2000 (don't know the exact default out of my head) seconds to fill up the action queue.

Here it is:

Code: Select all

$ModLoad imuxsock # provides support for local system logging
$ModLoad imklog   # provides kernel logging support (previously done by rklogd)

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

$FileOwner root
$FileGroup adm
$FileCreateMode 0640

$IncludeConfig /etc/rsyslog.d/*.conf

auth,authpriv.*         /var/log/auth.log
*.*;auth,authpriv.none      -/var/log/syslog
daemon.*         -/var/log/daemon.log
kern.*            -/var/log/kern.log
lpr.*            -/var/log/lpr.log
mail.*            -/var/log/mail.log
user.*            -/var/log/user.log
mail.info         -/var/log/mail.info
mail.warn         -/var/log/mail.warn
mail.err         /var/log/mail.err
news.crit         /var/log/news/news.crit
news.err         /var/log/news/news.err
news.notice         -/var/log/news/news.notice
*.=debug;\
   auth,authpriv.none;\
   news.none;mail.none   -/var/log/debug
*.=info;*.=notice;*.=warn;\
   auth,authpriv.none;\
   cron,daemon.none;\
   mail,news.none      -/var/log/messages
*.emerg            *
daemon.*;mail.*;\
   news.err;\
   *.=debug;*.=info;\
   *.=notice;*.=warn   |/dev/xconsole


rgerhards wrote:Another good suggestion is the move on to a recent build - especially the queue code has undergone considerable review, so if it is a bug, chances are great it is already fixed in the recent v3-stable (you can also try the beta, it will be "stamped" v3-stable very, very soon).

I could pretty easily upgrade from 3.18.1 to 3.18.6, but switch to the current stable 3.20.6 is a task I would like to keep as a last resort.

Best Regards,
Paolo Larcheri

Paolo Larcheri wrote:I could pretty easily upgrade from 3.18.1 to 3.18.6, but switch to the current stable 3.20.6 is a task I would like to keep as a last resort.

No sooner said than done! Rsyslog version 3.18.6 works like a charm.
Thanks a lot for the hint!

Paolo LArcheri

excellent!