Introducing the syslog Function

jacky.lee

Introducing the syslog Function

The syslog function, the syslogd daemon, and input from the /etc/syslog.conf file work together to facilitate system messaging for the
Solaris 10 OS
.
The syslog function sends messages generated by the kernel and system utilities and applications to the syslogd daemon, as shown in the image. With the syslog function you can control message logging, depending on the configuration of the /etc/syslog.conf file. The daemon can:

Write messages to a
system
log
Forward messages to a centralized log host
Forward messages to a list of users
Write messages to the system console

A configuration entry in the /etc/syslog.conf file consists of two tab-separated fields: selector and action.
The selector field has two components, a facility and a level written as facility.level. Facilities represent categories of system processes that can generate messages. Levels represent the severity or importance of the message.
The action field determines where to send the message.
For example, when you place the following entry in the /etc/syslog.conf file,
error messages
for all facilities are sent to the /var/adm/messages file:*.err                           /var/adm/messages
where:
Fields in the /etc/syslog.conf File
Field
Description
*.err
Is the selector field. The asterisk (*) is the facility, and the dot (.) is the delimiter. The err field is the level of the message.
/var/adm/messages
Is the action field.
Caution: Only use tabs as
white space
in the /etc/syslog.conf file.
The Solaris OS accesses the /usr/include/sys/syslog.h file to determine the correct facility.level sequencing order.
Selector Field
The selector field is a semicolon-separated list of priority specifications in the following format:facility.level;facility.level
In the selector field syntax, facility is a system facility. The table shows values that the selector field (facility) can contain.
Selector Field (facility) Options
Field
Description
kern
Messages generated by the kernel.
user
Messages generated by user processes. This file does not list the default priority for messages from programs or facilities.
mail
The mail system.
daemon
System daemons, such as the in.ftpd and the telnetd daemons.
auth
The authorization system, including the login, su, and ttymon commands.
syslog
Messages generated internally by the syslogd daemon.
lpr
The
line printer
spooling system, such as the lpr and lpc commands.
news
Files reserved for the USENET network news system.
uucp
The
UNIX
-to-UNIX copy (UUCP) system does not use the syslog function.
cron
The cron and at facilities, including crontab, at, and cron.
local0-7
Fields reserved for local use.
mark
The time when the message was last saved. The messages are produced internally by the syslogd daemon.
*
All facilities, except the mark facility.
Note: You can use the asterisk (*) to select all facilities (for example *.err); however, you cannot use * to select all levels of a facility (for example, kern.*)
In the selector field syntax, level is the severity or importance of the message. Each level includes all the levels above (of a higher severity). The table shows the levels in descending order of severity.
Selector Field (level) Options
Level
Priority
Description
emerg
0
Panic conditions that are normally broadcast to all users
alert
1
Conditions that should be corrected immediately, such as a corrupted system
database
crit
2
Warnings about critical conditions, such as hard device errors
err
3
Errors other than hard device errors
warning
4
Warning messages
notice
5
Non-error conditions that might require special handling
info
6
Informational messages
debug
7
Messages that are normally used only when debugging a program
none
8
Messages are not sent from the indicated facility to the selected file
Note: Not all levels of severity are implemented for all facilities in the same way. For more information, refer to the online manual pages.
Action Field
The action field defines where to forward the message. This field can have any one of the following entries:
Action Field Entries
Entry
Description
/pathname
Full path name to the targeted file.
@host
The @ sign denotes that messages must be forwarded to a remote host. Messages are forwarded to the syslogd daemon on the remote host.
user1, user2
The user1 and user2 entries receive messages if they are logged in.
*
All logged in users receive messages.
Note: You must manually create the /pathname full path and file name if it does not already exist.
Entries in the /etc/syslog.conf File
The standard /etc/syslog.conf
configuration file
is:
#ident  “@(#)syslog.conf        1.5     98/12/14 SMI”   /* SunOS 5.0 */
#
# Copyright (c) 1991-1998 by Sun Microsystems, Inc.
# All rights reserved.
#
# The syslog configuration file.
#
# This file is processed by m4 so be careful to quote (” “) names
# that match m4 reserved words. Also, within ifdef’s, arguments
# containing commas must be quoted.
#
*.err;kern.notice;auth.notice                   /dev/sysmsg
*.err;kern.debug;daemon.notice;mail.crit        /var/adm/messages
*.alert;kern.err;daemon.err                     operator
*.alert                                         root
*.emerg                                         *
# If a non-loghost machine chooses to have authentication messages
# sent to the loghost machine, un-comment out the following line:
#auth.notice    ifdef(`LOGHOST’,/var/log/authlog, @loghost)
mail.debug      ifdef(`LOGHOST’,/var/log/syslog, @loghost)
#
# Non-loghost machines will use the following lines to cause “user”
# log messages to be logged locally.
#
ifdef(`LOGHOST’,,
user.err                 /dev/sysmsg
user.err                 /var/adm/messages
user.alert                           `root, operator’
user.emerg                              *
)
The Demo shows how the syslogd daemon, the m4 macro
processor
, and the /etc/syslog.conf file interact in conceptual phases to determine the correct message routing.
These conceptual phases are described as:
The syslogd daemon runs the m4 macro processor.
The m4 processor reads the /etc/syslog.conf file, processes any m4 statements in the input, and passes the output to the syslogd daemon.
The syslogd daemon uses the configuration information output by the m4 processor to route messages to the appropriate places.
The syslogd daemon does not read the /etc/syslog.conf file directly. The syslogd daemon obtains its information as follows:
The syslogd daemon starts the m4 processor, which parses the /etc/syslog.conf file for m4 commands that it can interpret.
If the m4 processor does not recognize any m4 commands on a line, it passes the output back to the syslogd daemon as a two-column output.
The syslogd daemon then uses the two-column output to route messages to the appropriate destination.
If the m4 processor encounters an ifdef statement within the /etc/syslog.conf file, the ifdef statement is evaluated for a True or False condition. The message routing then occurs relative to the output of the test.
Operation Phase 1
In the following examples, the syslogd daemon is running on the host1 system. This section contains two examples of the host1 system’s /etc/hosts file.
These /etc/hosts file examples are excerpts of the /etc/hosts/ file.
Example A /etc/hosts:192.9.200.1 host1 loghost
192.9.200.2 host2
Example B /etc/hosts:192.9.200.1 host1
192.9.200.2 host2 loghost
When the syslogd daemon starts at system boot, the syslogd daemon evaluates the /etc/hosts file, and checks the Internet Protocol (IP) address associated with the hostname as compared to the IP address associated with loghost.
In Example A, host1 and loghost are both associated with IP address 192.9.200.1. Therefore, the syslogd daemon runs the first command line: /usr/ccs/bin/m4 -D LOGHOST, causing the m4 LOGHOST variable to be defined as TRUE during the parsing of the /etc/syslog.conf file.
In Example B, host1 is associated with IP address 192.9.200.1, while host2 and loghost are both associated with IP address 192.9.200.2. In this example, the syslogd daemon runs the second command line, /usr/ccs/bin/m4 (no -D LOGHOST), causing the m4 LOGHOST variable to be undefined during the parsing of the /etc/syslog.conf file.
Operation Phase 2
In the phase 2, the m4 macro processor parses the /etc/syslog.conf file. For each line that is parsed, the m4 processor searches the line for m4 statements, such as an ifdef statement. If no ifdef statement is encountered on the line, the m4 processor passes the line to the syslogd daemon.
If the m4 processor finds a line with an ifdef statement, the line is evaluated as follows:

• The ifdef (`LOGHOST’, truefield, falsefield) command checks to see if the variable LOGHOST is defined.
  
• If the variable LOGHOST is defined, the entries from the truefield field are used; otherwise, entries from the falsefield field are used.

For example: mail.debug ifdef(`LOGHOST’, /var/log/syslog, @loghost)
If the variable LOGHOST variable is defined in phase 1, then the m4 processor returns:
mail.debug /var/log/syslog
If the LOGHOST variable was evaluated as FALSE in phase 1, then the m4 processor returns:
mail.debug @loghost
In either case, the output has an entry in the selector field and an entry in the action field. The m4 processor then passes the output to the syslogd daemon.
Operation Phase 3
For each line parsed in the /etc/syslog.conf file from phase 2, the m4 processor produces output in a two-column field: a selector field and an action field. The output is sent to the syslogd daemon, which uses the information to route messages to their appropriate destinations. After the information is configured, the syslogd daemon continues to run with this configuration.


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/36549/showart_469000.html