Specify an alternative special log device file instead of devlog.
The syslogd daemon reads its configuration file when it starts up, and again whenever it receives an HUP signal the signal 1, at which time it also rereads the configuration file, and then opens
only the log files that are listed in the file.
Typical rc startstop sequences to startstop the syslogd daemon are:
case 1 in start
if [ −f etcsyslog.conf −a −f usrsbinsyslogd ]; then echo syslog service starting.
if [ −f varadmmessages ] then
cp devnull varadmmessages fi
usrsbinsyslogd 1devconsole 21 fi
;; stop
[ −f etcsyslog.pid ] exit 0 syspid = cat etcsyslog.pid
if [ syspid −gt 0 ]; then echo Stopping the syslog service.
kill −15 syspid 21 | usrbingrep −v no such process fi
;; echo Usage: etcinit.dsyslog { start | stop }
;; esac
This start sequence assumes varadmmessages for the system log file.
As the syslogd daemon is started, it creates the file etcsyslog.pid or varrunsyslog.pid on some platforms if possible, containing its process identifier PID. This file can be useful in handling the
running syslogd daemon afterwards. For example, the command
kill −HUP cat etcsyslogd.pid
will recycle the daemon, i.e., to force the syslogd daemon to reread its configuration file.
9.2 System Logging Configuration
Configuring the system logging means configuring the syslogd daemon, and to configure the syslogd daemon means setting the appropriate configuration file etcsyslog.conf. Please pay
attention to the configuration file name: although the daemon name is syslogd, the configuration file name is syslog.conf there is no letter d in the filename.
9.2.1 The Configuration File etcsyslog.conf
The configuration file etcsyslog.conf contains all of the data necessary to fully specify the logging process provided by the system log daemon, syslogd. When started, or recycled, the syslogd
daemon preprocesses this file through the m4 preprocessor to obtain the correct information for
207
The etcsyslog.conf file contains an arbitrary number of configuration entries needed to fully define the system logging. Blank lines are ignored, and lines for which the first nonwhite character is a
are treated as comments.
A logging configuration entry is composed of two TAB−separated fields:
selector action
Or more specifically:
facility.level [ ; facility.level ] [ ... ] destination [, destination ] [ ... ]
The selector field contains a semicolon−separated list of priority specifications of the form:
facility.level [ ; facility.level ]
where
facility — the subsystem sending the message to: user
User processes
kern
The kernel
mail
The mail system
daemon System daemons auth
The authentication authorization system
lpr
The printer spooling system
cron
The cronat facility
local 0–7 Reserved for local use mark
For internal timestamp messages
news
Reserved for the USENET network news system
uucp
Reserved for the UUCP system
All facilities except for the mark facility
•
Level — the severity priority level of the message: emerg
For panic conditions such as catastrophic failures
alert
For conditions that should be corrected immediately
crit
For warnings about critical conditions
err
For other errors
warning For warning messages
•
208
info
For informational messages
debug
For messages during debugging very verbose logging
none
Do not log messages Please note that an entry is a logging of all messages from the specified facility, with the severity
priority level equal, or higher than the specified one. In that sense, the level debug indicates the logging of all generated messages from a specified facility. Linux introduced the characters = and
that, used as a prefix to the specified severity level, change its basic meaning. The character = indicates this severity level only, while negates the entry by indicating except this severity level
and higher. However, this enhancement remains Linux specific only.
The message logging is active only for specified entries; nonspecified facilities within the configuration file not included in any configuration entry are simply ignored by the syslogd
daemon. In that sense, the level none should be combined with other facilities and severity levels for a more accurate and condensed specification of a logging selector; for example:
.debug;mail.none
will send all messages except mail messages to the specified destination.
The action field contains a comma−separated list of the logging destinations where to forward the messages for logging:
destination The file, device, username, or hostname to forward messages to; values for this field can have one of four forms:
A filename, beginning with a leading slash, which indicates that messages specified by the selector are to be written to the specified file the file will be opened in the
append mode. 1.
The name of a remote host, prefixed with an , as in hostname, which indicates that messages specified by the selector are to be forwarded to the syslogd daemon
on the dedicated remote system. The hostname loghost is an alias given to the system that is supposed to be the logging server. Every system is supposed to be
the loghost by default, which is defined in the local etchosts file. It is also possible to specify one system on a network to be a loghost by making the appropriate host
name entries in the localetchosts files over included systems, or in DNS, or NIS. The usual way to configure the syslogd daemon on a loghost is: if the local machine
is designated to be a loghost, then logging messages are written to the appropriate files; otherwise, they are sent to the remote loghost on the network.
2.
A comma−separated list of usernames, which indicates that messages specified by the selector are to be forwarded to the specified users if they are logged in.
3.
An asterisk , which indicates that messages specified by the selector are to be forwarded to all logged−in users.
4. •
A few examples: To log all mail subsystem messages except the debug ones, and all notice or higher
messages into the file varlognotice:
.notice;mail.info varlognotice
•
To log all critical messages into the file varlogcritical: •
209
To forward all kernel messages and 20−minute marks onto the system console:
kern,mark.debug devconsole
• To forward kernel messages of err error severity level, or higher, to the system named
hostname:
kern.err hostname
•
To forward emergency messages to all users who are currently logged in to the system:
.emerg
• To inform the users root and operator if currently logged in of any alert and emergency
messages:
.alert root,operator
•
Two typical configuration files are shown next. The first example Solaris 2.x corresponds to a system with higher logging requirements; the configuration data are processed by the preprocessor
m4, and depending on the actual system logging status if the system is the loghost, or not: LOGHOST =YES or NO, the system logging configuration is defined.
cat etcsyslog.conf
ident syslog.conf 1.4 Solaris 2.x syslog configuration file.
This file is processed by m4 so be careful to quote names that match m4 reserved words. Also, within ifdefs, arguments
containing commas must be quoted. .err;kern.notice;auth.notice devconsole
.err;kern.debug;daemon.notice;mail.crit varadmmessages .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 ifdefLOGHOST, varlogauthlog, loghost mail.debug ifdefLOGHOST, varlogsyslog, loghost
non−loghost machines will use the following lines to cause user log messages to be logged locally.
ifdefLOGHOST,, user.err devconsole
user.err varadmmessages user.alert root, operator
user.emerg
Briefly, the first section defines unconditionally: Forwarding to the system console all messages of a severity level equal to or higher than
err, and kernel and authentication messages greater than level notice •
Logging in the varadmmessages file all messages of a severity level equal to or higher than err, except for kernel, daemon, and mail messages where the threshold severity level
is defined differently •
The messages to forward to the defined user operator if defined on the system at all, and if the user is logged in at the time
• 210
Forwarding the emergency messages to all logged−in users •
The next section entries are presented in bold defines a conditional logging configuration. The m4 macro statement:
ifdefLOGHOST,VAR1,VAR2
generates the output VAR1, or VAR2 depending on the status of the LOGHOST.
For example:
mail.debug ifdefLOGHOST, varlogsyslog, loghost
specifies the file varlogsyslog as a logging destination for all mail messages if the system is the loghost, and if it is not, forwards messages to the remote loghost.
Please note that the similar configuration entry for the authentication subsystem is commented out, and first should be activated uncommented.
The last section, again the m4 preprocessor ifdef macro, has an output only if the local system is not the loghost; otherwise this part is ignored an empty ifdef output. If active, users processes are
joined to all other processes specified in the first part of the configuration file some UNIX platforms distinguish users processes from all other processes. The bottom line in both cases is the same,
because defined user processes are already covered by the first part of the configuration file user processes are not excluded from all processes.
The second example HP−UX 10.20 is easier to understand and still quite adequate for many implementations; however, it provides only local logging:
cat etcsyslog.conf
Revision: 74.1 syslogd configuration file.
See syslogd1M for information about the format of this file. mail.debug varadmsyslogmail.log
.info;mail.none varadmsyslogsyslog.log .alert devconsole
.alert root .emerg;user.none
The last entry illustrates the meaning of the none level, which defines the following: Send system panic messages from all processes, except from users processes, to all logged−in users
9.2.2 Linux Logging Enhancements
