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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This reverts commit 19318d28354190a9cfafa1696e41c90351f85af9.
With this commit, a shutdown that occurs while the startup event is
running can cause an abort because the startup callback will try to
decrease the run state from SHUTDOWN to RUNNING.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Monitoring is skipped when not in run state RUNNING, so remove the
dependency on the monitoring code.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Monitoring can fail during recovery due to databases (e.g. registry)
being unavailable. This has been avoided by explicitly disabling
monitoring around recovery via the START_RECOVERY and END_RECOVERY
controls. With this approach only there is still a window between
enabling recovery mode and START_RECOVERY when monitoring could be
attempted. However, explicitly disabling monitoring is unnecessary
because monitoring is not done when a node is in recovery.
So remove the explicit disable/enable of monitoring and rely on
monitoring being skipped when recovery mode is active.
The only possible change of behaviour with this change is that there
is now a window between setting recovery mode to normal and the
END_RECOVERY control where monitoring is enabled. However, at this
point databases would be available and the "recovered" event will
cancel any in-progress monitoring.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This is currently handled by explicitly disabling monitoring in
various places. However, those places shouldn't need to know about
monitoring but it is OK for monitoring to know about global node
states.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13029
If a call request for a key (migration request) is in flight, then all
the subsequent call requests for the same key are deferred. In that case,
the data corresponding to key read from the local tdb is useless and there
is no need to keep it around. Once the deferred call is reprocessed,
the data corresponding to that key will be fetched again.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
This doesn't belong in the monitoring/startup code and it is already
done in the 10.interface "init" event.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Recovery and takeover are run via helper from recovery daemon. While the
helpers are running, it's possible for the current node to lose election.
If that happens, abort the currently running recovery/takeover helper.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13021
Once the recovery starts and databases are frozen, then all the record
access is postponed till the recovery is complete except reading the
database sequence number. Database access for reading sequence number
is done via a control which does not check if the databases are frozen
or not.
If the database is frozen and if the freeze transaction is not started
(this can happen when a node is inactive, or during recovery when the
database is frozen but the transaction has not yet started), then trying
to read sequence number will cause ctdb daemon to deadlock.
Before reading the sequence number, check if the database access is
allowed.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Only check processes that are CTDB clients.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13012
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
This removes the static declaration and adds prototype declarations
of ctdb_event_header marshalling functions to avoid compiler warnings.
These functions will be removed.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Only create PID file when actually starting the daemon, rather than
when setting up the context. This will facilitate future changes.
Tweak test to confirm that PID file is no longer created during setup.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12978
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Autobuild-User(master): Martin Schwenke <martins@samba.org>
Autobuild-Date(master): Fri Aug 25 13:32:58 CEST 2017 on sn-devel-144
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Autobuild-User(master): Martin Schwenke <martins@samba.org>
Autobuild-Date(master): Mon Aug 14 13:00:16 CEST 2017 on sn-devel-144
This causes any tracked connections for the IP address to be lost.
When doing a takeip, the server sends a tickle ACK to the client, the
client responds with a valid ACK and the server's TCP stack responds
with a reset because the connection does not exist. However, in the
updateip, case the connection *does* exist, so the tickle *does not*
cause the connection to be reset.
ctdb_announce_vnn_iface() clears the list of tracked TCP connections
while sending the tickle ACKs. So, if there are no reconnects as in
the takeip case, then the list of connections is simply lost.
The "updateip" event in the 10.interface event script already sends
gratuitous ARPs and tickles connections in both directions. This
ensures that traffic continues after packets may have been dropped
when the script temporarily blocks traffic to the IP address.
All of this means that the call to ctdb_announce_vnn_iface() can just
be deleted.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This allows to differentiate between the two database models.
ctdb_db_persistent() - replicated and permanent
ctdb_db_volatile() - distributed and temporary
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
There is no need for with_jenkinshash and with_mutexes flags, since the
tdb_flags are now calculated based on database type.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
