IBM E027SLL-H - Tivoli Monitoring - PC, Руководство по устранению неисправностей

Страница: 142 / 310

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/Timekeeping-
In-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