NAME

syslog − log systems messages

SYNOPSIS

/usr/etc/in.syslog [ −mN ] [ −fname ] [ −d ] [ −p port ]

DESCRIPTION

Syslog reads a datagram socket and logs each message it reads into a set of files described by the configuration file /etc/syslog.conf.  Syslog configures when it starts up and whenever it receives a hangup signal.  Syslog logs to the host specified by ‘loghost’ in the /etc/hosts file.  For details on running syslog in a Sun network environment, see the section, “System Log Configuration” in the System Set-up and Operation chapter of the System Installation and Maintenance Guide. 

Each message logged consists of one line.  A message can contain a priority code, marked by a digit in angle braces at the beginning of the line.  Priorities are defined in <syslog.h>, as defined in the list below.  LOG_ALERT is prioity 1 (the highest priority) while LOG_DEBUG is priority 9 (the lowest priority). 

LOG_ALERTthis 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_SALERTmessages 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.  They get sent to a list of system people. 

LOG_EMERGEmergency 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_ERRthese represent error conditions, such as soft disk failures, etc. 

LOG_CRITsuch 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_WARNINGissued when an abnormal condition has been detected, but recovery can take place. 

LOG_NOTICEsomething that falls in the class of “important information;” this class is informational but important enough that you don’t want to throw items in it away casually.  Messages without any priority assigned to them are typically mapped into this priority. 

LOG_INFOinformation 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_DEBUGit may be useful to log certain debugging information.  Normally this will be thrown away. 

It is expected that the kernel will not log anything below LOG_ERR priority. 

The syslog configuration file, etc/syslog.conf, consists of two sections separated by a blank line.  The first section defines files that syslog will log into.  Each line contains 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 configuration file:

 5∗/dev/tty8
8/usr/spool/adm/syslog
3/usr/adm/critical
 eric
kridle
kalash
 

logs all messages of priority 5 or higher onto the system console, including timing marks every 20 minutes; all messages of priority 8 or higher into the file /usr/spool/adm/syslog; and all messages of priority 3 or higher into /usr/adm/critical.  The users ‘eric’, ‘kridle’, and ‘kalash’ will be informed on any subalert messages. 

OPTIONS

−mNSet the mark interval to N (default 20 minutes). 

−fname
Specify an alternate configuration file.

−dTurn on debugging (if compiled in). 

−pport
Port number where syslog listens for incoming datagrams.  The default port is defined in the ‘syslog/udp’ entry in the /etc/services file. 

To bring syslog down, it should be sent a terminate signal.  It logs that it is going down and then waits approximately 10 seconds for any additional messages to come in. 

There are some special messages that cause control functions.  ‘<∗>N’ sets the default message priority to N.  ‘<$>’ causes syslog 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. 

Syslog creates the file /etc/syslog.pid if possible containing a single line with its process id.  This can be used to kill or reconfigure syslog. 

FILES

/etc/hosts − the hosts file
/etc/syslog.conf − the configuration file
/etc/syslog.pid − the process id
/etc/services − to find the syslog server’s port number. 

BUGS

LOG_ALERT and LOG_SALERT messages should only be allowed to privileged programs. 

Actually, syslog is not clever enough to deal with kernel error messages in the current implementation. 

SEE ALSO

syslog(3), kill(2)

Sun Release 2.0  —  Last change: 1 February 1985