Hi Andrew,
I registered these contents with Bugzilla as enhancement of the functions.
* http://developerbugs.linux-foundation.org/show_bug.cgi?id=2501
Thanks,
Hideo Yamauchi.
--- renayama19661...@ybb.ne.jp wrote:
Hi Andrew,
Thank you for comment.
Is the change of this attrd and
Hi Andrew,
Thank you for comment.
Is the change of this attrd and crmd difficult?
I dont think so.
But its not a huge priority because I've never heard of attrd actually
crashing.
So while I agree that its theoretically a problem, in practice no-one
is going to hit this in
On Fri, Oct 1, 2010 at 4:00 AM, renayama19661...@ybb.ne.jp wrote:
Hi Andrew,
Thank you for comment.
During crmd startup, one could read all the values from attrd into the
hashtable.
So the hashtable would only do something if only attrd went down.
If attrd communicates with crmd at the
Hi Andrew,
Thank you for comment.
During crmd startup, one could read all the values from attrd into the
hashtable.
So the hashtable would only do something if only attrd went down.
If attrd communicates with crmd at the time of start and reads the data of the
hash table, the problem
seems
On Mon, Sep 27, 2010 at 7:26 AM, renayama19661...@ybb.ne.jp wrote:
Hi,
When I investigated another problem, I discovered this phenomenon.
If attrd causes process trouble and does not restart, the problem does not
occur.
Step1) After start, it causes a monitor error in UmIPaddr twice.
Hi Andrew,
Thank you for comment.
The problem here is that attrd is supposed to be the authoritative
source for this sort of data.
Yes. I understand.
Additionally, you don't always want attrd reading from the status
section - like after the cluster restarts.
The problem seems to be able
Hi,
When I investigated another problem, I discovered this phenomenon.
If attrd causes process trouble and does not restart, the problem does not
occur.
Step1) After start, it causes a monitor error in UmIPaddr twice.
Online: [ srv01 srv02 ]
Resource Group: UMgroup01
UmVIPcheck
