IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
fallback to the old-style ipv4-only controls if the new-style ipv4/ipv6
control fails.
this allows a 1.0.59+ (ipv4/ipv6) ctdb daemon being recmaster to be
compatible with
pre-1.0.59 versions of ctdb that are ipv4 only.
(This used to be ctdb commit 8e912abc2c68f5fe7b06c600ba6fec1a6900127c)
older ipv4-only version of these controls.
We need this so that we are backwardcompatible with old versions of ctdb
and so that we can interoperate with a ipv4-only recmaster during a
rolling upgrade.
(This used to be ctdb commit 6b76c520f97127099bd9fbaa0fa7af1c61947fb7)
Hi,
I have attached a patch necessary as debian log dir (/var/log) is not
a subdir of VARDIR (/var/lib on rpm systems, /var/lib/ctdb on debian).
As I don't know much about autotools and friends, this patch may be
hacky.
This is part of the process to minimize diff between distributions.
(This used to be ctdb commit dc9cd4779db4a89697731e4cf415be51067a07c1)
instead of shutting down/restarting the entire tcp layer
just bounce all outgoing connections and reconnect
(This used to be ctdb commit e701a531868149f16561011e65794a4a46ee6596)
matches commit 7aae6dd80e265aa9402ed507caaff4a5dba55069 in the kernel.
Many thanks to Jim Houston for pointing out this fix to us
(This used to be ctdb commit 85f6032cbdb197f3a003d86f086afa2cee898a4d)
correctly by measuring how long it was since the last successful
communication with the recovery daemon was recorded.
After a certain timeout the ctdb daemon would deem the recovery daemon
as inoperable and shut down.
If the system clock is suddenly changed forward by many (60 or more)
seconds this could cause the timeout to trigger prematurely/immediately
where ctdb would incorrectly think that more than 60 seconds had passed
since last successful communications and thus abort.
Instead of cehcking for one timeout occuring, only deem the recovery
daemon to be "down" and trigger a shutdown if communications have
timedout for three intervals in a row.
(This used to be ctdb commit 196968c552e6ebcb57389d769a4b25f42fa8bc5d)
Fix a slow memory leak in the recovery daemon if there is a recoery
triggered during the public ip reassignment process
(This used to be ctdb commit 0aca4daf908b76d6013ff3dfad41beb9114fc1a3)
"connected". Allow "rm" or "recmaster" to be a nodespec for the
recovery master. Better error handling for interaction with ctdb
client.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit 1d5d13345086201fe55517aea5f8674ff3db1090)
"connected". Allow "rm" or "recmaster" to be a nodespec for the
recovery master. Better error handling for interaction with ctdb
client.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit 05bdafed82106a0d8bfa53cd730eb3e1db68a51f)
nodespecs. Since we're now explicitly using bash, use local variables
when sensible.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit d1aa7953450de6ae215589404fb19e05edd3906f)
nodespecs. Since we're now explicitly using bash, use local variables
when sensible.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit 16626eaf9c63adfe780e8f51f9cd97810647e731)
we currently only monitor that the dameons are running by kill(0, pid)
and verifying the the domain socket between them is ok.
this is not sufficient since we can have a situation where the recovery
daemon is hung.
this new code monitors that the recovery daemon is operating.
if the recovery hangs, we log this and shut down the main daemon
(This used to be ctdb commit cd69d292292eaab3aac0e9d9fc57cb621597c63c)
Let the event complete successfully. the local recovery daemon will check that we have the address and reissue takip othervise.
There are several reasons why "ip addr add " can fail, one is a misconfiguration
anothe ris that for ipv6 the stack is a lot more picky than for ipv4. for examplke this WILL fail in ipv6 if there is a duplicate ip address on the network.
thus this check could cause rolling-recoveries which is why it has to go
(This used to be ctdb commit 12bc85c90a640a72ff538c003eb81da9dd1f2e3f)
