The syslogd Daemon The Concept of System Logging

err For other errors warning For warning messages notice For conditions that are not error conditions, but may require special handling info For informational messages debug For messages that are normally used only when debugging a program none Do not log messages; use only in combination with other levels The listed facilities and severity levels will be discussed further when we return to the system−logging configuration. The monitoring and detection of the listed conditions for when a corresponding message should be generated are not a part of the logging subsystem itself; rather, messages are −−generated within processes themselves and redirected toward the syslogd daemon for appropriate logging. A special device file devlog is used for the interprocess communication with the syslogd daemon, which is continuously listening for generated messages. Once a message is received, the syslogd daemon acts according to the specified configuration data related to the logging facility, the message severity level, and the logging destination. From the system logging standpoint, the syslogd daemon is a core of the overall logging procedure, and it deserves to be discussed in greater detail.

9.1.1 The syslogd Daemon

The syslogd daemon logs all system messages; it reads and forwards system messages to the appropriate log files andor users, depending upon the severity priority level of the message and the system facility from which the message originates. The configuration file etcsyslog.conf specifies where messages are forwarded. In addition, the syslogd daemon periodically generates and logs mark timestamp messages mark−interval is specified in minutes; the default is 20 minutes at an info logging priority level; this facility is identified as mark in the etcsyslog.conf file. The presence of the mark messages in the log files is proof of the daemons activity: the syslogd daemon is alive, active, and ready to log any received error or other message. Only one syslogd daemon can be running at one point in time; an attempt to start another daemon will fail. To check for the syslogd process: ps −ef | grep syslogd | grep −v grep root 532 1 0 Apr 30 ? 0:05 usrsbinsyslogd The syslogd daemon can be started with several options: usrsbinsyslogd [ −d ] [ −D ] [ −f configfile ] [ −m markinterval ] [ −p path ] where the options are: −d Turn on debugging. This option should only be used interactively and not in the start−up script. −D Prevent the kernel from directly printing its messages on the system console. In this case syslogd is responsible for routing all kernel messages. −f configfile Specify an alternate configuration file. −m Specify the interval, in minutes, between mark messages. 206 Specify an alternative special log device file instead of devlog. The syslogd daemon reads its configuration file when it starts up, and again whenever it receives an HUP signal the signal 1, at which time it also rereads the configuration file, and then opens only the log files that are listed in the file. Typical rc startstop sequences to startstop the syslogd daemon are: case 1 in start if [ −f etcsyslog.conf −a −f usrsbinsyslogd ]; then echo syslog service starting. if [ −f varadmmessages ] then cp devnull varadmmessages fi usrsbinsyslogd 1devconsole 21 fi ;; stop [ −f etcsyslog.pid ] exit 0 syspid = cat etcsyslog.pid if [ syspid −gt 0 ]; then echo Stopping the syslog service. kill −15 syspid 21 | usrbingrep −v no such process fi ;; echo Usage: etcinit.dsyslog { start | stop } ;; esac This start sequence assumes varadmmessages for the system log file. As the syslogd daemon is started, it creates the file etcsyslog.pid or varrunsyslog.pid on some platforms if possible, containing its process identifier PID. This file can be useful in handling the running syslogd daemon afterwards. For example, the command kill −HUP cat etcsyslogd.pid will recycle the daemon, i.e., to force the syslogd daemon to reread its configuration file.

9.2 System Logging Configuration