The nodes were killed as a result of a condition called "AISONLY"
resulting from the ntp timeofday change which caused a change of the
time of greater then 10 seconds.
Totem uses gettimeofday() to determine the time of day difference
between two time periods. If the time period is greater then 10
The only other thing I can think of is that I started NTPd and there was
likely a big time adjustment as it had not been running.
Sep 17 10:27:32 ntpd[1118]: synchronized to 206.222.28.90, stratum 2
Sep 17 15:53:38 ntpd[1118]: time reset +18217.299628 s
Sep 17 15:53:38 ntpd[1118]: kernel time sy
On Tue, Sep 18, 2007 at 09:34:45AM -0500, Chris Harms wrote:
> It said something about an out of memory condition. This was logged
> just prior to where it would have panicked:
>
> groupd[9639]: found uncontrolled kernel object rgmanager in /sys/kernel/dlm
> groupd[9639]: local node must be res
It said something about an out of memory condition. This was logged
just prior to where it would have panicked:
groupd[9639]: found uncontrolled kernel object rgmanager in /sys/kernel/dlm
groupd[9639]: local node must be reset to clear 1 uncontrolled instances
of gfs and/or dlm
openais[9625]:
On Mon, 2007-09-17 at 17:50 -0500, Chris Harms wrote:
> Is there an easy way to disable GFS and related kernel modules if one
> does not need GFS? We are running the 5.1 Beta 1 version of the cluster
> and had a mysterious crash of the cluster suite. There were issues with
> the GFS and dlm mo
Chris Harms napisał(a):
> Is there an easy way to disable GFS and related kernel modules if one
> does not need GFS? We are running the 5.1 Beta 1 version of the cluster
> and had a mysterious crash of the cluster suite. There were issues with
> the GFS and dlm modules. The kernel panicked on sh
Is there an easy way to disable GFS and related kernel modules if one
does not need GFS? We are running the 5.1 Beta 1 version of the cluster
and had a mysterious crash of the cluster suite. There were issues with
the GFS and dlm modules. The kernel panicked on shutdown.
Thanks,
Chris
--
L
