• Choose a category
• All
• Classic-Fiction

By Root 2715 0

of flowing to the recreated logfile, log data will start to mysteriously disappear; the active reference to the original file keeps it alive even after you delete the directory entry and create a new file with the same name. The file doesn’t disappear (and its disk space is not reclaimed) until every reference has been closed. To install a new log file, you must either signal the daemon or kill and restart it.

Here is an updated example that uses both compression and signals:

#!/bin/sh

cd/var/log

mv logfile.2.gz logfile.3.gz

mv logfile.1.gz logfile.2.gz

mv logfile logfile.1

cat /dev/null > logfile

kill -signal pid

gzip logfile.1

signal represents the appropriate signal for the program writing the log file; pid is its process ID. The signal can be hardcoded into the script, but you must determine the PID of the daemon dynamically, either by reading a file that the daemon has left around for you (e.g., /etc/syslog.pid, described below) or by filtering the output of ps. Some systems provide a standard command (such as Albert Cahalan’s skill or Werner Almesberger’s killall, both supplied with Red Hat) that simplifies the stereotypical ps-grep-kill sequence.1

Each program behaves differently with respect to logging. Consult the appropriate chapter in this book (or your manuals) to determine what procedures are necessary in each case.

Many systems supply an off-the-shelf log rotation script that is run out of cron. By all means, use the standard script if it does what you want. See the vendor-specific sections starting on page 209 for details.

If your system doesn’t supply a rotation system, we suggest that you use a Perl script called rotz written by Matt Segur and Michael Bernstein for this purpose. It’s available from www.admin.com.

Archiving log files

Some sites must archive all accounting data and log files as a matter of policy, perhaps to provide data for a potential audit. In this situation, log files should be first rotated on disk and then written to tape or other permanent media. This scheme reduces the frequency of tape backups and gives you fast access to recent data.

Log files should always be included in your regular backup sequence. They may also be archived to a separate tape series. Separate tapes are more cumbersome, but they impose less of a documentation burden and won’t interfere with your ability to recycle dump tapes. If you use separate tapes, we suggest that you use tar format and write a script to automate your backup scheme.

See Chapter 10 for more information about backups.

11.2 FINDING LOG FILES

UNIX is often criticized for being inconsistent, and indeed it is. Just take a look at a directory of log files and you’re sure to find some with names like maillog, some like ftp.log, and maybe even some like lpNet, lpd-errs, or console_log. In addition to having random names, log files are often scattered across directories and filesystems.

This section attempts to help you find all the files that are quietly taking over your disk and to suggest a granularity for dealing with each. We also note the “usual place” for log files on our four example systems.

To locate your log files, read your system’s startup scripts (/etc/rc*, /etc/rc.d/*, or /etc/init.d/*) to see if logging is turned on when daemons are run. You may have to read the man pages for individual daemons to see where the log data actually goes. Most programs these days handle logging via syslog, which is described later in this chapter. Check syslog’s configuration file, /etc/syslog.conf, to find out what happens to the messages.

The format of the syslog.conf file is described on page 211.

Table 11.1 compiles information about some of the more common log files on our example systems. Specifically, it lists

• The log files to archive, summarize, or truncate

• The program that creates each

• An indication of how each filename is specified

• The frequency of attention that we consider reasonable

• The required owner and group of the log file

• A description of the file’s contents