Pages: 1, 2
Also in Big Scary Daemons:
FreeBSD offers eight levels of
syslog importance. You can use these levels to tell
syslog what to record and what to discard. The levels follow, in order from most to least important.
emerg-- System panic. Messages are flashed on every terminal. The system is basically hosed, or at best horribly, horribly unstable.
alert-- This is bad, but not as bad as the
emerglevel. The system can continue to operate, but this error should be attended to immediately.
crit-- These are critical errors, such as hardware problems or serious software issues. If your hard drive has bad blocks, they'll show up as critical errors. You can continue running, if you're brave.
err-- Miscellaneous errors. They're bad, and should be fixed, but aren't going to destroy the system.
warning-- Miscellaneous warnings.
notice-- General information that should be logged, in case you need it, but probably doesn't really require action on your part.
info-- General system information.
debug-- This level is usually only of use to programmers, and occasionally to system admininistrators who are trying to figure out just why some program behaves in this way. Debugging logs can contain whatever information the programmer felt necessary to debug the code; this might include information that will violate this users' privacy.
none-- This special level means "don't log anything from this facility here." It's most commonly used when excluding information from wildcard entries.
Information sources include both a facility and a level, separated by a period. When you specify a level, the system defaults to recording messages of that level or greater. For example, look at this entry from
Messages from the mail system, with a level equal to or above info, are logged to
If you like, you can use wildcards in your information source. To log absolutely all messages from the mail system, you would use this.
To log everything from everywhere, uncomment the
This works, but it's far too full of information to be of any real use; you'll find yourself building complex
grep commands just to find what you want.
Also, this would include all sorts of private information, thanks to the debug level. You probably don't want to record that sort of thing. You can exclude authentication information with the
authpriv facility and the none level. The semicolon allows you to combine entries on a single line.
You can also use comparison operators in
/etc/syslog.conf. The valid operators are
< (less than),
= (equals), and
> (greater than). You might want to have a log for mail traffic, and another for mail debugging.
mail.info /var/log/maillog mail.=debug /var/log/maillog.debug
This way, you don't have to sort through debugging information to learn what your mail server thinks it's doing.
Similarly, you might have a program that wants to log to
local3. You can set this up as such.
You can also use a program name as an information source. If a program supports a facility, use it. If you're out of facilities, however, or if your program simply doesn't support
syslogd, you can use the name.
An entry for a name requires at least two lines. The first is the program name with a leading exclamation point. The second is the logging information. For example, look at the sample entry for logging PPP.
!ppp *.* /var/log/ppp.log
It starts by specifying the program name, and then tells
syslogd to append absolutely everything to a file. You can't be certain a random third-party program will have reasonable logging facilities, so it's safest to record everything.
Finally, we have the log message destination. The most common destination is a log file, specified by full path name, but there are other destinations.
You can send log messages to another host with the
@ symbol. The following example would dump everything your
syslog receives to the logging host on my network.
/etc/syslog.conf on the loghost will be used to send messages to their final destinations.
You can list user names, separated by commas. If they're logged in when the log message arrives, the system will write the message on its terminal.
If you want the messages to be written to all users' terminals, use a destination of "
Finally, if you want another program to handle the logs, you can use a pipe symbol to redirect the messages to that program.
Now that you have logging running, all you have to worry about is your logs eventually filling your disk. We'll cover that next time, when we discuss
Read more Big Scary Daemons columns.
Return to the BSD DevCenter.