BSD DevCenter
oreilly.comSafari Books Online.Conferences.


Where the Log Files Live
Pages: 1, 2, 3

So, do you have permission to muck about with this syslog.conf file? To find out, type:

ls -l /etc/syslog.conf
-rw-r--r--  1 root  wheel  903 Jul 28 09:10 /etc/syslog.conf

Looks like anyone can read it, but only the superuser will be able to modify it. Let's just take a peek at it as a regular user using the more command:

more /etc/syslog.conf

View the results from this command here.

Some parts of this file are self-explanatory, but we'll have to take this file's advice and read the syslog.conf(5) manpage before we start making any changes to it. I'll cover the highlights; you'll have to do a man 5 syslog.conf to get all the details.

Each line in syslog.conf has two fields: the selector field (on the left), which specifies the type of message, and an action field (on the right), which specifies the action to be taken if a message matches the selection criteria. The selector field is separated from the action field by one or more tabs.

The selector field itself is divided into two parts separated by a period, like this:


where facility is what generated the message and level is the severity of the message. The possible values for facilities and levels are explained in syslog(3). The following tables provide a summary of the facilities and levels:

Table 1: Facilities

Facility Name

What Program It Represents


The authorization system: login(1), su(1), getty(8), etc.


The same as AUTH, but logged to a file readable only by selected individuals.


The cron daemon: cron(8).


System daemons, such as routed(8), that are not provided for explicitly by other facilities.


The file transfer protocol daemons: ftpd(8), tftpd(8).


Messages generated by the kernel. These cannot be generated by any user processes.


The line printer spooling system: lpr(1), lpc(8), lpd(8), etc.


The mail system.


The network news system.


Security subsystems.


Messages generated internally by syslogd(8).


Messages generated by random user processes. This is the default facility identifier if none is specified.


The uucp system. ipfw(4).


Specifies all facilities or programs except mark.


A special facility used by syslogd.

Table 2: Levels

Level Name

What It Represents


A panic condition. This is normally broadcast to all users.


A condition that should be corrected immediately, such as a corrupted system database.


Critical conditions, e.g., hard device errors.




Warning messages.


Conditions that are not error conditions, but should possibly be handled specially.


Informational messages.


Messages that contain information normally of use only when debugging a program.


Special level to disable the facility.

Let's use these tables to decipher what type of messages are sent to the console, that is, those irritating bold-white messages that show up on your first terminal. The corresponding line in /etc/syslog.conf reads as:

*.err;kern.debug;auth.notice;mail.crit  /dev/console

Note that the selector field is a bunch of "facility.levels" tied together with semicolons. Reading from left to right, this line tells syslogd to send the following types of messages to the console:

  • error messages from all programs
  • debug messages generated by the kernel
  • notices regarding logins and su's
  • critical mail conditions

You should be able to use the same logic to see what types of messages are sent to which logs in the next five lines:

*.notice;kern.debug;;mail.crit;news.err /var/log/messages
security.*    /var/log/security     /var/log/maillog      /var/log/lpd-errs
cron.*        /var/log/cron

However, to understand the rest of the file, we need to know the five possible actions listed in the following table:

Table 3: Actions

Syntax of Action

What It Does


Messages are added to the end of the specified file.


Messages are forwarded to the syslogd(8) program on the specified computer.


Messages are written to those users if they are logged in.


Messages are written to all logged-in users.


Pipes the message to the specified command.

Also note that two of the lines in the file begin with an exclamation mark and don't have an action field after them like so:

*.*              /var/log/slip.log
*.*              /var/log/ppp.log

Occasionally you'll want to log the messages of a program that isn't covered by one of the built-in facilities. To add this program to /etc/syslog.conf, type the name of the program's executable on a line by itself with a ! in front of the name. On the next line, input the selector and action fields as you normally would.

You'll find that man 5 syslog.conf has excellent examples covering just about every scenario you'll ever come across when configuring logging. If you do ever edit your syslog.conf file, you will have to send a HUP signal to syslogd to force it to read the changes. To do this:

more /var/run/

and make note of the number you receive; this is the PID (process ID) being used by the syslog daemon. Then, as the superuser:

kill -1 number

where number is the number you received above.

Pages: 1, 2, 3

Next Pagearrow

Sponsored by: