Configuring syslogd

The syslogd configuration file, syslog.conf, determines what can be done and when. The file is usually in /etc. Syslogd. conf is a typical Linux configuration file with one item (or rule) per line and comment lines beginning with a pound sign (#). Each rule consists of the selector portion, which determines the events to which to react, and the action portion, which determines what is to be done. The selector and action portions are separated by a tab.

The selector portion is itself broken into two parts -- facility and priority -- which are separated by a dot. The facility part says what aspect of the system is to be recorded, and the priority says what level of messages to which to react. The selector has the general syntax:

facility.priority

Table One: Syslogd's Facilities
authpriv	news
cron	security
daemon	syslog
kern	user
lpr	uucp
mail	local0 through local7
mark
The facility security should no longer be used, and the mark facility is used internally and should not be used within applications. The facilities local0 through local8 are intended for local events on your local system when there is no other applicable facility.
Table Two: Syslogd Priorities in Increasing Significance debug info notice warning or warn err or error crit alert emerg or panic The priorities error, warn, and panic are deprecated and should no longer used.

You can see a list of facilities in Table One and a list of the priorities in Table Two.

For both facilities and priorities, there is a "wildcard," represented by an asterisk (*), that can be used to mean any facility or any priority. For example, *.emerg means all emergency messages. mail.* means all messages coming from the mail facility. Logically, *.* means all priorities of messages from all facilities.

The word none is used to refer to no priority for the specified facility. For example, the selector mail.none would say not to perform the action for any mail event. At first, this might not make sense to you. Why not simply leave off that facility? The answer lies in the previous paragraph. Using the wildcard, you might want to log all messages with a priority of info in a certain file. However, for obvious reasons, you might also want to log all of the security messages (regardless of the priority) into another file.

Another possibility is to specify a subset of facilities, rather than all of them. This is done by separating the facilities with a comma, with the priority following the last facility listed. For example, to refer to information messages for mail, uucp, and news, the selector entry would look like this:

mail,uucp,news.info

One thing I need to point out here is that when you specify a priority, you are actually specifying everything at that priority or higher. Therefore, in this example, I am selecting all of the priorities at info and higher.

You can perform three primary actions with these events. Probably the most common action is to write them to a file. Because Linux (as well as other Unix dialects) treats devices as files, you can also send the logging messages to a specific device, such as the system console (/dev/console). It is a common practice to send emergency messages to the system console, where someone will see the messages no matter what console terminal they are logged on. In other cases, kernel messages are sent to one of the console terminals (e.g., /dev/tty7). You might end with something like the following:

kernel.*        /dev/tty7

Writing to the hard disk takes time, which is why the system normally buffers a number of writes before sending them all to disk. However, by default, syslogd will actually write the information to the disk with each event. This ensures the entry actually makes it to the file if the system should crash.

If overall system performance becomes an important factor with regard to logging, you can tell syslogd not to sync the disk each time it writes to a log file. This is done by putting a minus sign (-) in front of the file name, like this:

lpr.info    -/var/adm/printer.log

If you disable syncing the log file like this, one important thing to remember is that you stand the chance of losing information. If the system goes down for some reason before the information is written to the file, you may lose an important clue about why the system went down. One solution would be to have a central log server where all of the information is sent and where you do not disable syncing. That way, no matter what, you have a record of what happened.

Sending the log messages to another machine is done by using an at sign (@) in front of the machine name as the action. For example:

*.emerg         @logserver

This sends all emergency messages to the machine logserver. I would suggest that you do not create a logserver that is connected to the Internet. A malicious person might be able to bring the system to a halt or at least affect its performance by flooding it with erroneous log messages.