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)