syslog(8) System Manager's Manual syslog(8)
Name
syslog - 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 config-
ures 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. Priori-
ties 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 hardware failure.
LOG_SALERT Messages of this priority should be issued only when immediate attention is needed by a qualified system person, for example,
when some valuable system resource disappears. These messages are sent to a list of system people.
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 information''; 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 priority.
The configuration file is in two sections separated by a blank line. The first section defines files that will log into. Each line con-
tains a single digit which defines the lowest priority (highest numbered priority) that this file will receive, an optional asterisk which
guarantees that something gets output at least every 20 minutes, and a pathname. 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 recon-
figure (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 privileged programs.
Actually, can not deal with kernel error messages in the current implementation.
Files
Configuration file
Process id
See Also
syslog(3)
syslog(8)