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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
... and there is no need to find out if mutexes are enabled.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
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): Wed Jun 7 20:19:06 CEST 2017 on sn-devel-144
This wraps the entire async computation for setting and removing message
handlers instead of calling multiple sync calls.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
This implements the async version of the traverse code in the ctdb tool
for catdb command.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
This function only traverses the database on local node.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Signed-off-by: Chris Lamb <chris@chris-lamb.co.uk>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
ctdb_ctrl_freeze() now only needs to send a single control since there
are no database priorities any more.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
This makes it easier to drop unused async implementation of the same.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
State is stolen onto tmp_ctx above so can't be referenced after
tmp_ctx is freed. So, state->status has to be looked at earlier.
Moving it immediately before the talloc_free(tmp_ctx) isn't sufficient
because invoking the callback appears to cause a recursive call to
ctdb_control_recv(), which also frees state.
Referencing it at the top seems safe.
==23982== Invalid read of size 4
==23982== at 0x4204AE: ctdb_control_recv (ctdb_client.c:1181)
==23982== by 0x420645: invoke_control_callback (ctdb_client.c:971)
==23982== by 0x5E675EC: tevent_common_loop_timer_delay (tevent_timed.c:341)
==23982== by 0x5E68639: epoll_event_loop_once (tevent_epoll.c:911)
==23982== by 0x5E66BD6: std_event_loop_once (tevent_standard.c:114)
==23982== by 0x5E622EC: _tevent_loop_once (tevent.c:533)
==23982== by 0x4255F7: ctdb_client_async_wait (ctdb_client.c:3385)
==23982== by 0x42578A: ctdb_client_async_control (ctdb_client.c:3442)
==23982== by 0x41B405: ctdb_get_nodes_files (ctdb.c:5488)
==23982== by 0x41B405: check_all_node_files_are_identical (ctdb.c:5530)
==23982== by 0x41B405: control_reload_nodes_file (ctdb.c:5673)
==23982== by 0x404DBA: main (ctdb.c:6008)
==23982== Address 0x7e98d9c is 108 bytes inside a block of size 168 free'd
==23982== at 0x4C2CDFB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23982== by 0x5652692: _tc_free_internal (talloc.c:1125)
==23982== by 0x5652692: _tc_free_children_internal (talloc.c:1570)
==23982== by 0x564B952: _tc_free_internal (talloc.c:1081)
==23982== by 0x564B952: _talloc_free_internal (talloc.c:1151)
==23982== by 0x564B952: _talloc_free (talloc.c:1693)
==23982== by 0x4204C9: ctdb_control_recv (ctdb_client.c:1182)
==23982== by 0x4207AA: async_callback (ctdb_client.c:3350)
==23982== by 0x4204AD: ctdb_control_recv (ctdb_client.c:1179)
==23982== by 0x420645: invoke_control_callback (ctdb_client.c:971)
==23982== by 0x5E675EC: tevent_common_loop_timer_delay (tevent_timed.c:341)
==23982== by 0x5E68639: epoll_event_loop_once (tevent_epoll.c:911)
==23982== by 0x5E66BD6: std_event_loop_once (tevent_standard.c:114)
==23982== by 0x5E622EC: _tevent_loop_once (tevent.c:533)
==23982== by 0x4255F7: ctdb_client_async_wait (ctdb_client.c:3385)
==23982== Block was alloc'd at
==23982== at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23982== by 0x564DBEC: __talloc_with_prefix (talloc.c:675)
==23982== by 0x564DBEC: __talloc (talloc.c:716)
==23982== by 0x564DBEC: _talloc_named_const (talloc.c:873)
==23982== by 0x564DBEC: _talloc_zero (talloc.c:2318)
==23982== by 0x42017F: ctdb_control_send (ctdb_client.c:1086)
==23982== by 0x425746: ctdb_client_async_control (ctdb_client.c:3431)
==23982== by 0x41B405: ctdb_get_nodes_files (ctdb.c:5488)
==23982== by 0x41B405: check_all_node_files_are_identical (ctdb.c:5530)
==23982== by 0x41B405: control_reload_nodes_file (ctdb.c:5673)
==23982== by 0x404DBA: main (ctdb.c:6008)
==23982==
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
The point of this code is almost certainly to return non-zero when
state->errormsg is set. So, return state->status if non-zero, -1
otherwise.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
There is no need to explicitly check that recovery is not active before
sending TRANS33_COMMIT control. Just try TRANS3_COMMIT control and if
recovery occurs before the control is completed, the control will fail
and it can be retried.
Make sure g_lock lock is released after the transaction is complete.
Also, add timeout to the client api.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Since g_lock checks if the process exists in case of conflicting lock,
there is no need to register srvid.
Transaction start returns a transaction handle and transaction
commit/cancel will free that handle. Since we cannot call async code
in a talloc destructor, this avoids the use of talloc destructor for
cancelling the transaction.
If user frees the transaction handle instead of calling transaction
cancel, it will leave stale g_lock lock. This stale g_lock lock will
get cleaned up on next transaction attempt.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
