|Red Hat Cluster Manager: The Red Hat Cluster Manager Installation and Administration Guide|
|Prev||Chapter 3. Cluster Software Installation and Configuration||Next|
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 will help to diagnose problems more clearly.
The cluster systems 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 system on which it is running. Therefore, you need to examine the log files on both cluster systems to get a comprehensive view of the cluster.
The syslogd daemon logs messages from the following cluster daemons:
cluquorumd — Quorum daemon
clusvcmgrd — Service manager daemon
clupowerd — Power daemon
cluhbd — Heartbeat daemon
clumibd — Administrative system monitoring daemon
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 cluster system is unusable.
alert — Action must be taken immediately to address the problem.
crit — A critical condition has occurred.
err — An error has occurred.
warning — A significant event that may require attention has occurred.
notice — An event that does not affect system operation has occurred.
info — An normal cluster operation has occurred.
debug — Diagnostic output detailing normal cluster operations.
The default logging severity levels for the cluster daemons are warning and higher.
Examples of log file entries are as follows:
May 31 20:42:06 clu2 clusvcmgrd: <info> Service Manager starting May 31 20:42:06 clu2 clusvcmgrd: <info> mount.ksh info: /dev/sda3 \ is not mounted May 31 20:49:38 clu2 clulog: <notice> stop_service.ksh notice: \ Stopping service dbase_home May 31 20:49:39 clu2 clusvcmgrd: <notice> Service Manager received \ a NODE_UP event for stor5 Jun 01 12:56:51 clu2 cluquorumd: <err> updateMyTimestamp: unable to \ update status block. Jun 01 12:34:24 clu2 cluquorumd: <warning> Initiating cluster stop Jun 01 12:34:24 clu2 cluquorumd: <warning> Completed cluster stop Jul 27 15:28:40 clu2 cluquorumd: <err> shoot_partner: successfully shot partner.     
Each entry in the log file contains the following information:
 Cluster system on which the event was logged
 Subsystem that generated the event
 Severity level of the event
 Description of the event
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 log cluster events to both the /var/log/cluster and /var/log/messages files, 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 prevent the duplication of messages and log cluster events only to the /var/log/cluster file, add lines similar to the following to 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 apply the previous changes, you can invoke the killall -HUP syslogd command, or restart syslog with a command similar to /etc/rc.d/init.d/syslog restart.
In addition, it is possible to modify the severity level of the events that are logged by the individual cluster daemons. See the Section called Modifying Cluster Event Logging in Chapter 8 for more information.