296 Technique 41: Keeping an Eye on Your System

• Figure 41-11: Adding a log file to the list of currently monitored logs.

3. Click the OK button to open a monitor dialog for that log file.

The Monitoring Logs dialog opens, as shown in Figure 41-12.

• Figure 41-12: Current log activity displayed by the Log Monitor.

Take a quick trip back in time to view the log entries recorded on a prior date by choosing View Calendar to open the Calendar dialog. Log files exist for the dates displayed in bold text — click the date to see the log file for that date.

Customizing Your Log Files

Most log files are recorded by the syslogd daemon. When an application (such as an e-mail relay or a login program) wants to record a log message, it sends the message to syslogd, and syslogd decides what to do with it. Every log message is comprised of three parts:

Facility: The facility tells you which subsystem produced the message. Table 41-1 shows some of the facilities recognized by Linux.

Severity: The severity (the syslog documentation calls it a priority) tells you how important the message is. Table 41-2 lists the severity codes defined by Linux.

Message text: The message text tells you about an event detected by the facility.

Most log messages are simply discarded without anyone actually seeing them, but you can customize log handling by adjusting the /etc/syslog.conf configuration file. You can route messages generated by a given facility to a separate log file (for easier viewing) or tell syslogd not to throw out messages that you might want to see.

Each entry in syslog.conf is made up of three parts: a facility code, a severity code, and a target. The facility code and severity code are used to classify incoming messages, and the target tells syslogd what do with matching messages. For example, suppose you have an entry like this:

mail.error /var/log/maillog

syslogd will route error messages generated by the mail facility to a file named /var/log/maillog. Actually, that entry will route error messages and all messages with a higher severity (crit, alert, and panic) to /var/log/maillog. If you want to route only the error messages, put an equal sign in front of the severity, like this:

mail.=error /var/log/maillog

If you peek at your own syslog.conf file, you’ll probably see a few wildcards, too. You can use a * on either side of the dot that separates the facility and severity:

To select all mail messages, regardless of severity (for example), type in an entry like this:

mail.* /var/log/maillog

Customizing Your Log Files 297

To select every critical message, regardless of the facility that produced it, use an entry like this:

*.crit /var/log/serious

It’s not a good idea to use a wildcard on both sides of the period because that would select all facilities and all severities.

The first two pieces of a syslog.conf entry (the facility code and the severity code) decide which messages are routed by that entry. The last piece (the target) decides what happens to those messages.

Most syslog messages are either discarded or recorded in a log file, but you can also route messages to other destinations. The first character of the target tells syslogd whether to send messages to a file, a named pipe, another computer, or a list of users. The following list explains what the different characters accomplish:

/: If the first character of the target is a /, the target is a filename (or the name of a terminal device).

@: If the first character is @, the target is a host name (selected messages are routed to the syslog daemon on the named computer).

|: You can route messages to another program by creating a named pipe and prefixing the name of the pipe with a |.

*: Route selected messages to a group of one or more users by listing the users (separated by commas), or route messages to all users currently logged in by specifying a target of *.

To summarize, here are a few sample syslog.conf entries that show you how to specify message targets:

*.crit /var/log/serious: Writes critical messages to /var/log/serious

*.crit /dev/console: Displays critical messages on the console

*.crit @bastille: Sends critical messages to the syslogd daemon on host bastille

*.crit |/var/log/messages: Writes critical messages to the named pipe /var/log/messages

*.crit freddie,franklin: Sends critical messages to users freddie and franklin (if they’re logged in)

*.crit *: Sends critical messages to all users

TABLE 41-1: SYSLOG FACILITIES

Facility	Description
Authpriv	Security and authorization
	messages (you can also spell
	this facility Auth)
Cron	Messages sent by the task
	schedulers (cron, at, anacron,
	and so on)
Daemon	Messages sent by daemon
	processes (also known as
	services)
FTP	Messages sent by the FTP server
Kern	Messages sent by the Linux
	kernel
Lpr	Messages sent by the printing
	subsystem
Mail	Mail-processing messages
News	Usenet news-processing
	messages
Syslog	Messages sent by the syslog
	facility itself
User	Generic messages not falling into
	another category
UUCP	UUCP messages (you’ll probably
	never see UUCP messages
	though)
Local0-Local7	User-definable messages (sort of
	user-definable anyway)