MonitorWare Knowledge Base

Hai,
I am using the same code till now. I also tried several times after your recent reply but did not get the required result.
I deleted the file srvrfwd in /var/log/spool and made rsyslog run again but did not find the file being created automatically.

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

Have you read the doc I posted? This is the relevant excerpt:

Please note that actual spool files are only created if the remote server is down and there is no more space in the in-memory queue. By default, a short failure of the remote server will never result in the creation of a disk file as a couple of hundered messages can be held in memory by default.

That means no file is created until there is need to.

Hai,
Good news. It's grand success. Thanks for helping me throughout the procedure. I am getting the log data in the server after it is on.
But some more doubts. They are
1. two files are being created in /var/log/spool
they are srvrfwd.00000001 srvrfwd.qi
they are being created only after running rsyslog in client for second time after server goes to unreachable state. They are not being created at the time we run rsyslog for the first time. I want to know what are the files and why are they created only after the second run of rsyslog and why not after the first run.
2. Every time i made the server reachable again they are disappearing.

The thing you need to understand is that rsyslog is highly optimized. As such, it does not persist anything to the disk unless there is need to. Unless there is need, everything is kept in main memory. Need arises when either a) the main memory queue is full or b) rsyslog is terminated (in that case, it can no longer hold anything in main memory for obvious reasons...).

What you see after your first run is b) happening. The queue files are created because you shut rsyslog down. Upon restart, it reads from the files. Then, when the remote machines comes back online, file data is read and sent. From then on, the in-memory queue takes over and the disk files can be deleted.

You can find an in-depth look at how it works in the rsyslog queue doc: http://www.rsyslog.com/doc-queues.html (but be warned, this is a deeply technical document).

The bottom line is that what you see is evidence that everything works as intended. There is much more going on under the hood, like changes in threading model when running on-disk vs. in-memory and such things. The good thing to know is that it happens automatically.

Rainer

I forgot to mention: with the suggested config, you are running a "disk-assisted memory queue". That just in case you actually go for the queue document

Rainer

Please note: the $ActionExecOnlyIfPreviousIsSuspended does not exist, this is actually a misspelled name which stemmed back to a doc bug. The real name is $ActionExecOnlyWhenPreviousIsSuspended.