syslog(8)syslog(8)Namesyslog - log systems messages
Syntax
/etc/syslog [ -mN ] [ -fname ] [ -d ]
Description
The command reads a datagram socket and logs each line it reads into a
set of files described by the configuration file The command configures
when it starts up and whenever it receives a hangup signal.
Each message is one line. A message can contain a priority code,
marked by a digit in angle braces at the beginning of the line. Prior‐
ities are defined in < syslog.h >, as follows:
LOG_ALERT This priority should essentially never be used. It
applies only to messages that are so important that every
user should be aware of them, for example, a serious hard‐
ware failure.
LOG_SALERT Messages of this priority should be issued only when imme‐
diate attention is needed by a qualified system person,
for example, when some valuable system resource disap‐
pears. These messages are sent to a list of system peo‐
ple.
LOG_EMERG Emergency messages are not sent to users, but represent
major conditions. An example might be hard disk failures.
These could be logged in a separate file so that critical
conditions could be easily scanned.
LOG_ERR These messages represent error conditions, such as soft
disk failures, etc.
LOG_CRIT Such messages contain critical information, but which can
not be classed as errors, for example, `su' attempts.
Messages of this priority and higher are typically logged
on the system console.
LOG_WARNING These messages are issued when an abnormal condition has
been detected, but recovery can take place.
LOG_NOTICE These messages fall into the class of ``important informa‐
tion''; this class is informational but important enough
that you don't want to throw it away casually. Messages
without any priority assigned to them are typically mapped
into this priority.
LOG_INFO These are information level messages. These messages
could be thrown away without problems, but should be
included if you want to keep a close watch on your system.
LOG_DEBUG These messages may be useful to log certain debugging
information. Normally this information is thrown away.
It is expected that the kernel will not log anything below LOG_ERR pri‐
ority.
The configuration file is in two sections separated by a blank line.
The first section defines files that will log into. Each line contains
a single digit which defines the lowest priority (highest numbered pri‐
ority) that this file will receive, an optional asterisk which guaran‐
tees that something gets output at least every 20 minutes, and a path‐
name. The second part of the file contains a list of users that will
be informed on SALERT level messages. For example, the following logs
all messages of priority 5 or higher onto the system console, including
timing marks every 20 minutes:
5*/dev/console
8/usr/spool/adm/syslog
3/usr/adm/critical
eric
kridle
kalash
This example logs all messages of priority 8 or higher into the file
and all messages of priority 3 or higher into The users ``eric'',
``kridle'', and ``kalash'' will be informed on any subalert messages.
The flags are:
-m Set the mark interval to N (default 20 minutes).
-f Specify an alternate configuration file.
-d Turn on debugging (if compiled in).
To bring down, it should be sent a terminate signal. It logs that it
is going down and then waits approximately 30 seconds for any addi‐
tional messages to come in.
There are some special messages that cause control functions. ``<*>N''
sets the default message priority to N. ``<$>'' causes to reconfigure
(equivalent to a hangup signal). This can be used in a shell file run
automatically early in the morning to truncate the log.
The command creates the file if possible containing a single line with
its process ID. This can be used to kill or reconfigure
Restrictions
LOG_ALERT and LOG_SUBALERT messages should only be allowed to privi‐
leged programs.
Actually, can not deal with kernel error messages in the current imple‐
mentation.
Files
Configuration file
Process id
See Alsosyslog(3)syslog(8)
