>>> Chris Walker schrieb am 18.12.2018 um 17:13 in Nachricht
:
[...]
> 2. As Ken mentioned, synchronize the starting of Corosync and Pacemaker. I
> did this with a simple ExecStartPre systemd script:
>
> [root@bug0 ~]# cat /etc/systemd/system/corosync.service.d/ha_wait.conf
> [Service]
> Exec
Hi!
I just noticed that in SLES12 SP3 there is a syslog-ng RA, but it seems there
is no syslog-ng package available, and "$SYSLOG_NG_EXE" is not set any more.
Thus that RA is unusable IMHO.
I was running a non-priviledged syslog-ng with ist own log files on a high-port
in SLES11, but it seems t
Hi All,
In clusters that do not use STONITH, actions to erase attributes to each other
occurred.
The problem occurs when the load on the CPU goes up and the token of corosync
does not stabilize.
I confirmed that the problem will occur with a simple configuration.
Step1) Configure the cluster.
Chris,
Thanks a lot for the info. I'll explore both options.
_Vitaly
> On December 18, 2018 at 11:13 AM Chris Walker wrote:
>
>
> Looks like rhino66-left was scheduled for fencing because it was not present
> 20 seconds (the dc-deadtime parameter) after rhino66-right started Pacemaker
> (star
Looks like rhino66-left was scheduled for fencing because it was not present 20
seconds (the dc-deadtime parameter) after rhino66-right started Pacemaker
(startup fencing). I can think of a couple of ways to allow all nodes to
survive if they come up far apart in time (i.e., father apart than d
Ulrich,
Thank you very much for suggestion.
My guess is that node 2 is considered unclean because both nodes were rebooted
without pacemaker knowledge after installation. For our appliance it should be
OK as we are supposed to survive multiple hardware and power failures. So this
case is just an