UNIX System Administration Handbook - Evi Nemeth [133]
FreeBSD also runs the periodic command from cron on a daily, weekly, and monthly basis to execute scripts stored under /etc/periodic. Log maintenance can be done from these scripts if you find that newsyslog doesn’t meet your needs.
11.5 SYSLOG: THE SYSTEM EVENT LOGGER
Syslog, originally written by Eric Allman, is a comprehensive logging system. Many vendors use syslog to manage the information generated by the kernel and the system utilities.
Syslog has two important functions: to liberate programmers from the tedious mechanics of writing log files and to put administrators in control of logging. Before syslog, every program was free to make up its own logging policy. System administrators had no control over what information was kept or where it was stored.
Syslog is quite flexible. It allows messages to be sorted by their source and importance (“severity level”) and routed to a variety of destinations: log files, users’ terminals, or even other machines. Syslog’s ability to centralize the logging for a network is one of its most valuable features.
Syslog consists of three parts:
• syslogd, the logging daemon (along with its config file, /etc/syslog.conf)
• openlog et al., library routines that submit messages to syslogd
• logger, a user-level command that submits log entries from the shell
In the following discussion, we first cover the configuration of syslogd and then briefly show how to use syslog from Perl scripts.
syslogd is started at boot time and runs continuously. Programs that are syslogaware write log entries (using the syslog library routine) to the special file /dev/log (or, on some systems, /var/run/log), which is either a UNIX domain socket, a named pipe, or a STREAMS module, depending on the system. syslogd reads messages from this file, consults its configuration file, and dispatches each message to the appropriate destinations. On many systems, syslogd also reads kernel messages from the device /dev/klog.
A hangup signal (HUP, signal 1) causes syslogd to close its log files, reread its configuration file, and start logging again. If you modify /etc/syslog.conf, you must send a hangup signal to syslogd to make your changes take effect. A TERM signal causes syslogd to exit.
syslogd writes its process ID to the file /var/run/syslog.pid (or /etc/syslog.pid, on a few systems). This convention makes it easy to send signals to syslogd from a script. For example, the following command sends a hangup signal:
# kill -HUP `/bin/cat /var/run/syslog.pid`
Trying to compress or rotate a log file that syslogd has open for writing is not healthy and has unpredictable results. Some vendors provide you with a skeletal script, often /usr/lib/newsyslog, that purports to rotate log files.2
A better one, rotz, is available from www.admin.com.
Configuring syslogd
The configuration file /etc/syslog.conf controls syslogd’s behavior. It is a text file with a relatively simple format. Blank lines and lines with a pound sign (#) in column one are ignored. The basic format is:3
selector For example, the line mail.info /var/log/maillog would cause messages from the email system to be saved in the file /var/log/maillog. The selector and action fields must be separated by one or more tabs; spaces don’t work (in most versions) and become invisible errors that are very hard to track down. Cutting and pasting with your window system is one way to introduce such errors. Selectors identify the program (“facility”) that is sending a log message and the message’s severity level with the syntax facility.level Both facility names and severity levels must be chosen from a short list of defined values; programs can’t make up their own. Facilities are