|
|
xdmcp dies in sco600
|
|
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)
