Red Hat Knowledgebase

It is possible to edit the /etc/syslog.conf file to enable the cluster to log events to a file that is different from the /var/log/messages log file. Logging cluster messages to a separate file helps to diagnose problems more clearly.

The members use the syslogd daemon to log cluster-related events to a file, as specified in the /etc/syslog.conf file. The log file facilitates diagnosis of problems in the cluster. It is recommended to set up event logging so that the syslogd daemon logs cluster messages only from the member on which it is running. Therefore, you need to examine the log files on all members to get a comprehensive view of the cluster.

The syslogd daemon logs messages from the cluster daemons, which all default to severity level 4 (warning).

The importance of an event determines the severity level of the log entry. Important events should be investigated before they affect cluster availability. The cluster can log messages with the following severity levels, listed in order of severity level:

• EMERG - The member is unusable (emergency).
• ALERT - Action must be taken immediately to address the problem.
• CRIT - A critical condition has occurred.
• ERR - An error has occurred.
• WARN - A significant event that may require attention has occurred.
• NOTICE - A significant, but normal, event has occurred.
• INFO - An insignificant, but normal, cluster operation has occurred.
• DEBUG - Diagnostic output detailing cluster operations (typically not of interest to administrators.)

Examples of log file entries are as follows:

  
Jul 18 20:24:39 clu1 clufence[7397]: <info> STONITH: rps10 at /dev/ttyS0,\

   port 0 controls clu1

Jul 18 20:24:39 clu1 clufence[7397]: <info> STONITH: rps10 at /dev/ttyS0,\

    port 1 controls clu2

Jul 18 20:24:53 clu1 clufence[7397]: Port 0 being turned off.

Jul 18 20:24:53 clu1 clufence[7397]: <notice> STONITH: clu2 has been fenced!

Jul 18 20:51:03 clu1 clufence[30780]: <info> STONITH: rps10 at/dev/ttyS0,\

   port 0 controls clu1

Jul 18 20:51:03 clu1 clufence[30780]: <info>STONITH: rps10 at /dev/ttyS0,\

   port 1 controls clu2

Jul 18 20:51:17 clu1 clufence[30780]: Port 0 being turned on.

Jul 18 20:51:17 clu1 clufence[30780]: <notice> STONITH: clu2 is no longer fenced off.

       [1]               [2]        [3]                        [4]                  [5]
   

Each entry in the log file contains the following information:

• [1] Date and time
• [2] Hostname
• [3] Cluster resource or daemon
• [4] Severity
• [5] Message

After configuring the cluster software, optionally edit the /etc/syslog.conf file to enable the cluster to log events to a file that is different from the default log file, /var/log/messages. The cluster utilities and daemons log their messages using a syslog tag called local4. Using a cluster-specific log file facilitates cluster monitoring and problem solving.

To prevent cluster events from being logged to the /var/log/messages file, add local4.none to the following line in the /etc/syslog.conf file:

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;news.none;authpriv.none;local4.none /var/log/messages

To direct the cluster logging facility to log cluster events in the /var/log/cluster file, add lines similar to the following to the /etc/syslog.conf file:

#
# Cluster messages coming in on local4 go to /var/log/cluster
#
local4.* /var/log/cluster

To apply the previous changes, restart syslogd with the service syslog restart command. In addition, it is possible to modify the severity level of the events that are logged by the individual cluster daemons.

To rotate the cluster log file according to the frequency specified in the /etc/logrotate.conf file (the default is weekly), add /var/log/cluster to the first line of the /etc/logrotate.d/syslog file. For example:

  
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler

/var/log/boot.log /var/log/cron /var/log/cluster {

    sharedscripts

    postrotate

          /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2>

          /dev/null || true

    endscript

}