next up previous contents
Next: Cyclic log commands Up: Introduction Previous: Introduction   Contents

The need for cyclic logs

Servers need to record the error, warning and diagnostic output that they produce. There are a number of ways they can do this. Some write to the syslog facility but this is only available on POSIX platforms. Other servers write to stdout and stderr. This is platform-independent but raises the issue of the disk space required to capture the output.

Server logs are typically not examined unless something goes wrong. Old data is often not needed. When there is a problem the log data of most interest is usually what was recorded near to when the problem occurred. This means it is useful to retain recent information but not critical to retain very old information.

What is needed is a platform-independent way for a server to record stdout and stderr such that the most recent information can be retained in a logfile without such logfiles growing in size such that they might fill the disk up. One way to do this is to merge stdout and stderr and pipe the lot through a filter that writes all its input to a cyclic log. A cyclic log has a fixed size upon creation and a structure that allows older data to be overwritten on the arrival of new data to be logged.

Suppose the server is called myserver and we want to record the output in a cyclic log called myserver.log. The command needed is:
server 2>&1 | alog myserver.log.
This ensures that the last 10k of log data (the default log size) is always available. To view it, use the command:
acat myserver.log.


next up previous contents
Next: Cyclic log commands Up: Introduction Previous: Introduction   Contents
Andrew Marlow 2004-01-01