MonitorWare Knowledge Base

We had a failure of our centralized logging server(s) in an upgrade, which caused some unexpected results. When the individual servers could no longer sent their messages via TCP it buffered those messages (yay). What was unexpected was that when the buffer filled, no local log was written (boo). It seems like I'm missing a configuration somewhere - shouldnt local files be written regardless of the state of a remote object?

What have I missed?

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

I think that you have forgotten to run the sender on a separate queue. If you post your config, I can pinpoint to the cause, but it is rather clear. I guess you have unlimited retries set.

If you do not define an async queue for an action, it is executed on the main queue. If all actions execute on the main queue (the default), one that hangs blocks all others. Compare your config to this doc:

http://www.rsyslog.com/doc-rsyslog_reli ... rding.html

I guess you'll see a missing statement. For your overall understanding (not the actual use case), this link may be worth reading:

http://www.rsyslog.com/doc-rsyslog_high ... _rate.html

HTH
Rainer

Maybe I'm hurting more than I think I am. We're doing a lot with rsyslog, since we're dealing with blades (shipping off all our log files, for example). When I added in another configuration at the bottom for a remote destination, it still didn't work. I've attached my unedited config. What I did, was I removed the last line (*.* @@), and replaced it with ...

Code: Select all

$ActionQueueType LinkedList   # use asynchronous processing
$ActionQueueFileName srvrfwd1 # set file name, also enables disk mode
$ActionResumeRetryCount -1    # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
*.* @@172.24.2.207;prodea


It didn't work. Do I need to be defining a Action/Queue for each destination or input? I feel like I'm missing a big chunk of configuration knowledge...

a quick look does not reveal something obviously wrong. Can you send me a debug log? Most useful would be one where the destination is taken down while processing (a couple of) messages.

oh, one thing: the unedited config had actionqueue mode direct, which is not an async mode. But your edit uses an async mode, so that should work.