The downside to having programs that can provide useful or verbose logging output is the amount of disk space this output can consume. This is a concern for all three operating systems covered in this book: Unix, MacOS, and Windows NT/2000. Of the three, NT/2000 is probably the least troublesome of the lot because its central logging facility has built-in autotrimming support. MacOS does not have a central logging facility, but it too can run servers that will happily produce enough logging output to fill your disks if given the chance.
Usually, the task of keeping the log files down to a reasonable size is handed off to the system administrator. Most Unix vendors provide some sort of automated log size management mechanism with the OS, but it often only handles the select set of log files shipped with the machine. As soon as you add another service to a machine that creates a separate log file, it becomes necessary to tweak (or even toss) the vendor-supplied solution.
solution to the space problem is to rotate your log files.
(We’ll see an unusual solution later in this section.) After a
specific duration has passed or a file size has been reached, the
current log file is moved to another name, e.g.,
logfile.0. The logging process is then continued
into an empty file. At the next interval or limit, we repeat the
process, first moving the backup file (
) to another name (like
logfile.1). This process is repeated until a set number ...