MonitorWare Knowledge Base

Hi,
First let me say how impressed I am with rsyslog's features.
great work. much appreciated

I have a few questions regarding rsyslog's high availability features.
I see that rsyslog has the global directive $ActionExecOnlyWhenPreviousIsSuspended.

Lets say I have the following configuration (copied from your example...):

*.* @@primary
$ActionExecOnlyWhenPreviousIsSuspended on
& @@secondary

1.Does this mean that every message that arrives to the daemon is first sent to primary and then if failed, to secondary?
Is there some timeout when rsyslog will jump straight to secondary and not even try primary?
I'm asking this because if the primary server is down it could be very time consuming to try and send it every message,
so I would expect to find some configurable primary server retry time interval but I couldn't find such a thing
and from a peek at the source it seems that it doesn't work that way. Am I right?

2.If primary and or secondary are down, do I have some indication of that?
Do I have an indication of lost messages as a result?

Thanks,
Nir

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

Nir,

sorry, I am currently swamped but finally got some time to look at the forum posts

Note: I am talking v3/4 here, v2 is probably different.

If an action fails, it asks the engine to suspend it. The engine will not retry it unless a timeout has expired. There is a setting to specifiy this timeout on an per-action basis (something along the lines of $ActionResumeRetryTimeout). As long as the action is suspended, the next action in that chain is called.

.. what brings us to your second question. This is not a primary/secondary thing but rather has an unlimited depth. So if both actions fail, you could add a third (4th, 5th, nth) action that shall only be executed if the previous failed. To record otherwise lost message to a file, you could use this:

*.* @@primary
$ActionExecOnlyWhenPreviousIsSuspended on
& @@secondary
$ActionExecOnlyWhenPreviousIsSuspended on
& /var/log/fail.log

Alternatively, you could also queue them - see the doc set for a "reliable delivery" (or so...) guide.

HTH
Rainer

Hi,
Thank you very much for your answers. They were very helpful.
Don't know why I missed the $ActionResumeRetryTimeout directive,
I guess I wasn't looking hard enough. sorry for that...

Thanks again for your time, I really appreciate it
Nir