Among two cases where I have seen this error messages I solved one.
On one cluster these dedicated interfaces were connected to a switch
instead of being connected directly.
Though I still don't know what caused these errors on another system
(the logs in the previous email).
Hi,
First, hopefully I am posting this in the right email thread! :)
So in a 2 node cluster, we add resources (2 for now, one in each node) for
monitoring, which is located one in each node. What we expect is any change
in the event type (start/stop) for the resource, we get an alert (which
curren
On 04/21/2017 07:14 AM, Vladislav Bogdanov wrote:
> 20.04.2017 23:16, Jan Wrona wrote:
>> On 20.4.2017 19:33, Ken Gaillot wrote:
>>> On 04/20/2017 10:52 AM, Jan Wrona wrote:
Hello,
my problem is closely related to the thread [1], but I didn't find a
solution there. I have a reso
On 04/21/2017 07:52 AM, Lentes, Bernd wrote:
>
>
> - On Apr 21, 2017, at 11:38 AM, Bernd Lentes
> bernd.len...@helmholtz-muenchen.de wrote:
>
>> - On Apr 21, 2017, at 1:24 AM, Ken Gaillot kgail...@redhat.com wrote:
>>
>>> On 04/20/2017 02:53 PM, Lentes, Bernd wrote:
>>
>>>
>>> target-ro
On 04/21/2017 04:38 AM, Lentes, Bernd wrote:
>
>
> - On Apr 21, 2017, at 1:24 AM, Ken Gaillot kgail...@redhat.com wrote:
>
>> On 04/20/2017 02:53 PM, Lentes, Bernd wrote:
>
>>
>> target-role=Stopped prevents a resource from being started.
>>
>> In a group, each member of the group depends o
The nodes are called node-0 and node-1.
It is not happening regularly. It rather happens occasionally.
Among about 50 two-node clusters we have in house I've seen this issue
in journal of 2 clusters.
I looked at logs and the pattern I see is this: stop Pacemaker and
Corosync on node-1, and then st
- On Apr 21, 2017, at 11:38 AM, Bernd Lentes
bernd.len...@helmholtz-muenchen.de wrote:
> - On Apr 21, 2017, at 1:24 AM, Ken Gaillot kgail...@redhat.com wrote:
>
>> On 04/20/2017 02:53 PM, Lentes, Bernd wrote:
>
>>
>> target-role=Stopped prevents a resource from being started.
>>
>>
20.04.2017 23:16, Jan Wrona wrote:
On 20.4.2017 19:33, Ken Gaillot wrote:
On 04/20/2017 10:52 AM, Jan Wrona wrote:
Hello,
my problem is closely related to the thread [1], but I didn't find a
solution there. I have a resource that is set up as a clone C restricted
to two copies (using the clone
Seems that replacing inf: with 0: in some colocation constraints fixes the
problem, but still cannot understand why it worked for one node and not for
the other.
On 20.4.2017 12:16:02 Klechomir wrote:
> Hi Klaus,
> It would have been too easy if it was interleave.
> All my cloned resoures have i
- On Apr 21, 2017, at 1:24 AM, Ken Gaillot kgail...@redhat.com wrote:
> On 04/20/2017 02:53 PM, Lentes, Bernd wrote:
>
> target-role=Stopped prevents a resource from being started.
>
> In a group, each member of the group depends on the previously listed
> members, same as if ordering and
On 04/21/2017 10:10 AM, Kristoffer Grönlund wrote:
> Ken Gaillot writes:
>
I think it works differently: One task periodically reads ist mailbox slot
for commands, and once a comment was read, it's executed immediately. Only
>>> if
the read task does hang for a long time, the watc
Hi folks,
We have a lot of our two-node systems running in our server room.
I noticed that some of them occasionally have this entries in the syslog:
So it is not happening regularly? Nodes sees each other?
Because if nodes sees each other it looks like bug in corosync crypto
(or with very lo
Ken Gaillot writes:
>>> I think it works differently: One task periodically reads ist mailbox slot
>>> for commands, and once a comment was read, it's executed immediately. Only
>> if
>>> the read task does hang for a long time, the watchdog itself triggers a
>> reset
>>> (as SBD seems dead).
13 matches
Mail list logo