IBM E027SLL-H Troubleshooting Guide - Page 142

v During startup, do not start any user interaction when there is not a connected console. v Ensure that a korn shell [ksh] is available. In general, any shell can be used for .profile except csh, which has problems with output redirection. v Eliminate any logic that can create an error associated with undefined variable evaluation; or use korn file controls to suppress the errors. v Set the PATH statements to what is needed for the environment. v Ensure that the .profile completes and does not loop. If any of these requirements are violated, then the results can be failure to start or even failure for normal server processes to start. The .profile should be simple and clear. This might require creating a special user ID for this purpose to avoid impacting other users. Heartbeat issues when running on a Linux guest using VMware When the Linux operating system is run as a guest using VMware, it is possible for the clock of the Linux guest to run faster or slower than real world time. If any IBM Tivoli Monitoring products are installed on Linux guests whose clocks are not running correctly, the result can be erratic system behavior. For example, if the Linux OS monitoring agent is installed on a Linux operating system guest whose clock is running too slow, heartbeats from the agent are not produced on time. This results in the agent continuously going OFFLINE and ONLINE at the Tivoli Enterprise Monitoring Server because the heartbeats arrive after the time interval has expired. The VMware company is aware of this issue, and has written several articles that address this problem. Search on "linux guest clock" in the VMware Knowledge Base (http://kb.vmware.com/selfservice/microsites/microsite.do). See also IBM Service Management Connect (http://www.vmware.com/files/pdf/TimekeepingIn-VirtualMachines.pdf) How to tell if you have this problem: A simple way for determining whether your Linux guest has a clock problem is to benchmark it against a real world clock. Here is an example of a procedure that you can use: 1. From a Linux shell prompt, type "date" to get the current system date and time. While you are pressing Enter, look at a "real" clock (wall clock, watch, etc...) to get the real world time in minutes and seconds. Record the time from both your Linux guest and the "real" clock. Example: Real Clock = 10:30:00, Linux Clock = 10:20:35 2. After 10 real time minutes have expired, type the "date" command again (you should type the "date" command ahead of time, so you only have to press Enter when 10 minutes have elapsed). Record the new times from both your Linux guest and "real" clock. Example: Real Clock = 10:40:00, Linux Clock = 10:26:35 3. Compute the elapsed time for both your Linux guest and "real" clock. If the elapsed times are not the same, your Linux guest has a clock problem. Since we waited exactly 10 minutes using the "real" clock, we would expect that the elapsed time for the Linux clock would also be 10 minutes. Using the above figures, we can see that the elapsed time for the Linux guest is 6 minutes (10:26:35 - 10:20:35). Since this is less than the real world time, this means that 124 IBM Tivoli Monitoring: Troubleshooting Guide