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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
These variables are used for state information related to freezing
databases. Instead use the API functions to check if the databases
are frozen.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Use ctdb->freeze_mode only in ctdb_freeze.c and use the functions to
check if databases are frozen everywhere else.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
The pending calls are migration requests received from clients (over unix
domain socket) which are under processing. After a recovery is finished,
any requests which are under processing will be dropped since they do
not belong to the current generation. All the pending call requests
are resent with new generation to restart record migrations.
This is in preparation for parallel database recovery.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
This iterator only iterates through databases of specified priority.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Just use ctdb_tcp_connection. It is the same. There are no external
users.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Volker Lendecke <vl@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Thu Sep 3 22:12:02 CEST 2015 on sn-devel-104
When the ctdb statistics is reset, reset per database statistics to keep
it consistent with ctdb statistics.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Some code involved in releasing IPs is not re-entrant. Memory
corruption can occur if, for example, overlapping attempts are made to
ban a node. We haven't been able to recreate the corruption but this
should protect against it.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This calls release_all_ips() only once on the first ban. If the node gets
banned again due to event script timeout while running release_all_ips(),
then avoid calling release_all_ips() in re-entrant fashion.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
No use dying or failing eventscripts if someone sends a random
SIGUSR1.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Tue Jul 21 11:00:17 CEST 2015 on sn-devel-104
Due to the missing cast of uint64_t, CONTROL_GET_DB_SEQNUM always returned
seqnum <= 256.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11398
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Tue Jul 14 13:03:25 CEST 2015 on sn-devel-104
Before commit cbffbb7c2f406fc1d8ebad3c531cc2757232690e this was
possible and some users depend on this behaviour.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Warn specifically about cancellation instead of printing a generic
error message. Also pass back an error message for the tool - it
could just rely on the status but it already looks at the error
message.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
The eventscript state should never be freed externally, so it should
never be allocated off a temporary context. It will either be freed
by the handler or in the cancellation code.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Pair-programmed-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Martin Schwenke <martin@meltin.net>
This has not been used for a long time.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Fri Jul 10 23:41:18 CEST 2015 on sn-devel-104
==20761== Invalid read of size 8
==20761== at 0x11BE30: ctdb_ctrl_dbstatistics (ctdb_client.c:1286)
==20761== by 0x12BA89: control_dbstatistics (ctdb.c:713)
==20761== by 0x1312E0: main (ctdb.c:6543)
==20761== Address 0x713b0d0 is 0 bytes after a block of size 560 alloc'd
==20761== at 0x4C27A2E: malloc (vg_replace_malloc.c:270)
==20761== by 0x5CB0954: _talloc_memdup (talloc.c:615)
==20761== by 0x11395C: ctdb_control_recv (ctdb_client.c:1146)
==20761== by 0x11BDD7: ctdb_ctrl_dbstatistics (ctdb_client.c:1265)
==20761== by 0x12BA89: control_dbstatistics (ctdb.c:713)
==20761== by 0x1312E0: main (ctdb.c:6543)
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
It is important to know when ctdbd is started with --start-as-stopped
or --start-as-disabled. Given that this only happens once it makes
sense to promote these debug items to NOTICE level.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
If a node was previously recovery master (say, 20 years ago) and it
becomes recovery master again then, if IP assignments have changed,
verify_remote_ip_allocation() can produce messages like the following
when called during recovery:
ctdbd: recoverd:Inconsistent IP allocation - node 0 thinks 10.1.1.1 is held by node 0 while it is assigned to node 1
When a node loses an election it should clear all data specific to it
being the recovery master.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This needs to be cleared to avoid stale data when a new recovery
master is elected.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This was used to unlink the socket at daemon exit, which
was removed in ctdb commit b18356764cd49d934eab901e596bb75c6e3ecdf8
(Samba master commit 42591560506c7fee977975e261e4790ae1a0f97f).
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Thu Jun 25 18:29:59 CEST 2015 on sn-devel-104
This reverts commit 257311e337065f089df688cbf261d2577949203d.
That commit was due to a misunderstanding, and it
does not fix what it was supposed to fix.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
The caller should not dereference lock_ctx after invoking
process_callbacks(), it might be destroyed already.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11293
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Fri Jun 12 15:28:57 CEST 2015 on sn-devel-104
We should not dereference lock_ctx after invoking the callback
in the auto_mark == false case. The callback could have destroyed it.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11293
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Let ctdb_lock_request_destructor() take care of the proper cleanup.
If the request if freed from the callback function, then the lock context
should not be freed. Setting request->lctx to NULL takes care of that
in the destructor.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11293
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
There is already code in the destructor to correctly remove it from the
pending or the active queue. This also ensures that when lock context
is in pending queue and if the lock request gets freed, the lock context
is correctly removed from the pending queue.
Thanks to Stefan Metzmacher for noticing this and suggesting the fix.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11293
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
The code was added to ctdb_lock_context_destructor() to ensure that
the if a lock_ctx gets freed first, the lock_request does not have a
dangling pointer. However, the reverse is also true. When a lock_request
is freed, then lock_ctx should not have a dangling pointer.
In commit 374cbc7b0ff68e04ee4e395935509c7df817b3c0, the code for second
condition was dropped causing a regression.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11293
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
If the lock request is freed from within the callback, then setting
lock_ctx->request to NULL in ctdb_lock_context_destructor will end up
corrupting memory. In this case, lock_ctx->request could be reallocated
and pointing to something else. This may cause unexpected abort trying
to dereference a NULL pointer.
So, set lock_ctx->request to NULL before processing callbacks.
This avoids the following valgrind problem.
==3636== Invalid write of size 8
==3636== at 0x151F3D: ctdb_lock_context_destructor (ctdb_lock.c:276)
==3636== by 0x58B3618: _talloc_free_internal (talloc.c:993)
==3636== by 0x58AD692: _talloc_free_children_internal (talloc.c:1472)
==3636== by 0x58AD692: _talloc_free_internal (talloc.c:1019)
==3636== by 0x58AD692: _talloc_free (talloc.c:1594)
==3636== by 0x15292E: ctdb_lock_handler (ctdb_lock.c:471)
==3636== by 0x56A535A: epoll_event_loop (tevent_epoll.c:728)
==3636== by 0x56A535A: epoll_event_loop_once (tevent_epoll.c:926)
==3636== by 0x56A3826: std_event_loop_once (tevent_standard.c:114)
==3636== by 0x569FFFC: _tevent_loop_once (tevent.c:533)
==3636== by 0x56A019A: tevent_common_loop_wait (tevent.c:637)
==3636== by 0x56A37C6: std_event_loop_wait (tevent_standard.c:140)
==3636== by 0x11E03A: ctdb_start_daemon (ctdb_daemon.c:1320)
==3636== by 0x118557: main (ctdbd.c:321)
==3636== Address 0x9c5b660 is 96 bytes inside a block of size 120 free'd
==3636== at 0x4C29D17: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3636== by 0x58B32D3: _talloc_free_internal (talloc.c:1063)
==3636== by 0x58B3232: _talloc_free_children_internal (talloc.c:1472)
==3636== by 0x58B3232: _talloc_free_internal (talloc.c:1019)
==3636== by 0x58B3232: _talloc_free_children_internal (talloc.c:1472)
==3636== by 0x58B3232: _talloc_free_internal (talloc.c:1019)
==3636== by 0x58AD692: _talloc_free_children_internal (talloc.c:1472)
==3636== by 0x58AD692: _talloc_free_internal (talloc.c:1019)
==3636== by 0x58AD692: _talloc_free (talloc.c:1594)
==3636== by 0x11EC30: daemon_incoming_packet (ctdb_daemon.c:844)
==3636== by 0x136F4A: lock_fetch_callback (ctdb_ltdb_server.c:268)
==3636== by 0x152489: process_callbacks (ctdb_lock.c:353)
==3636== by 0x152489: ctdb_lock_handler (ctdb_lock.c:468)
==3636== by 0x56A535A: epoll_event_loop (tevent_epoll.c:728)
==3636== by 0x56A535A: epoll_event_loop_once (tevent_epoll.c:926)
==3636== by 0x56A3826: std_event_loop_once (tevent_standard.c:114)
==3636== by 0x569FFFC: _tevent_loop_once (tevent.c:533)
==3636== by 0x56A019A: tevent_common_loop_wait (tevent.c:637)
==3636== by 0x56A37C6: std_event_loop_wait (tevent_standard.c:140)
==3636== by 0x11E03A: ctdb_start_daemon (ctdb_daemon.c:1320)
==3636== by 0x118557: main (ctdbd.c:321)
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11293
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
For all the records listed in VACUUM_FETCH, migration requests are sent
immediately without waiting. This means there can only be a single
VACUUM_FETCH processing active at a time.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Michael Adam <obnox@samba.org>
With the processing of one element factored out,
it is more natural to have the actual loop inside the
handler function. This also makes the talloc/free
bracked around the loop more obvious.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
