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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
ctdb_sock_addr values are hashed in some contexts. This means that
all of the memory used for the ctdb_sock_addr should be consistent
regardless of how parsing is done. The first 2 cases are just sanity
checks but the 3rd case involving an IPv4-mapped IPv6 address is the
real target of this test addition.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13839
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@samba.org>
(cherry picked from commit d9286701cd9253bf3b42cac3d850ae8c23743e6d)
Failed to kill the tcp connection that using IPv4-mapped IPv6 address
(e.g. ctdb_killtcp eth0 ::ffff:192.168.200.44:2049
::ffff:192.168.200.45:863).
When the ctdb_killtcp is used to kill the tcp connection, the IPs and
ports in the connection will be parsed to conn.client and conn.server
(call stack: main->ctdb_sock_addr_from_string->ip_from_string). In
the ip_from_string, as we are using IPv4-mapped IPv6 addresses, the
ipv6_from_string will be used to parse ip to addr.ip6 first. The next
step the ipv4_from_string will be used to reparse ip to addr.ip.
As a result, the data that dump from conn.server is "2 0 8 1 192 168
200 44 0 0 0 0 0 0 0 0 0 0 255 255 192 168 200 44 0 0 0 0", the data
from conn.client is "2 0 3 95 192 168 200 45 0 0 0 0 0 0 0 0 0 0 255 255
192 168 200 45 0 0 0 0". The connection will be add to conn_list by
ctdb_connection_list_add. Then the reset_connections_send uses conn_list
as parameter to start to reset connections in the conn_list.
In the reset_connections_send, the database "connections" will be
created. The connections from conn_list will be written to the
database(call db_hash_add), and use the data that dump from conn_client
and conn_server as key.
In the reset_connections_capture_tcp_handler, the
ctdb_sys_read_tcp_packet will receive data on the raw socket. And
extract the IPs and ports from the tcp packet. when extracting IP and
port, the tcp4_extract OR tcp6_extract will be used. Then we got the
new conn.client and conn.server. the data that dump from the
conn.server is "2 0 8 1 192 168 200 44 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0", the data from conn.client is "2 0 3 95 192 168 200 45 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0". Finally, we use the data as key to check
if this connection is one being reset(call db_hash_delete). The
db_hash_delete will return ENOENT. Because the two key that being used
by db_hash_delete and db_hash_add are different.
So, the TCP RST will be NOT sent for the connection forever. We should
initialize addr struct to zero before reparsing as IPV4 in the
ip_from_string.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13839
Signed-off-by: Zhu Shangzhong <zhu.shangzhong@zte.com.cn>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@samba.org>
(cherry picked from commit 539b5ff32b32b7c75dfaaa119e41f5af6ff1e6fc)
This makes testing easier.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13520
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit 3bf753e830c20183ef4f3278880d3be362e53bef)
C library buffering API can behave in unexpected fashion if underlying
fd for stdin, stdout or stderr is closed and re-opened.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13520
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit c9b42d27e6cf9e6ae36f44970f0a388edc737a7a)
... instead of applying banning credits.
There have been a couple of cases where recovery repeatedly takes just
over 2 minutes to fail. Therefore, banning credits expire between
failures and a continuously problematic node is never banned,
resulting in endless recoveries. This is because it takes 2
applications of banning credits before a node is banned, which
generally involves 2 recovery failures.
The recovery helper makes up to 3 attempts to recover each database
during a single run. If a node causes 3 failures then this is really
equivalent to 3 recovery failures in the model that existed before the
recovery helper added retries. In that case the node would have been
banned after 2 failures.
So, instead of applying banning credits to the "most failing" node,
simply ban it directly from the recovery helper.
If multiple nodes are causing recovery failures then this can cause a
node to be banned more quickly than it might otherwise have been, even
pre-recovery-helper. However, 90 seconds (i.e. 3 failures) is a long
time to be in recovery, so banning earlier seems like the best
approach.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13670
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): Mon Nov 5 06:52:33 CET 2018 on sn-devel-144
(cherry picked from commit 27df4f002a594dbb2f2a38afaccf3e22f19818e1)
The startup_fd should not be propagated to the child processes created
from a daemon. It should only be used in the daemon code to return the
status of the startup. Another use of startup_fd is to notify the
parent if the daemon process has exited.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13659
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit 80549927bc1741a4b8af8b8e830de4d37fa0c4a8)
ctdbd enters a broken state if eventd goes away. A clean shutdown is
not possible because that involves running events. Restarting eventd
is possible but this might mask a serious problem and it is possible
that eventd might keep on disappearing. Just exit.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13659
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit c9e1603a5d0c1a216439d4a2b0e7cdc05181e898)
Since no records are deleted from RB tree during step 1, there is no
need for the check. Run step 2 unconditionally.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13641
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit e15cdc652d76b37c58cd114215f00500991bc6b4)
If a node fails to delete a record in TRY_DELETE_RECORDS control during
vacuuming, then it's possible that other nodes also may fail to delete a
record. So instead of deleting the record from RB tree on first failure,
keep track of the remote failures.
Update delete_list.remote_error and delete_list.left statistics only
once per record during the delete_record_traverse.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13641
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit ef052397173522ac2dd0d0bd9660a18a13a3e4fc)
The 3-phase deletion of vacuumed records was introduced to overcome
the problem of record(s) resurrection during recovery. This problem
is now handled by avoiding the records from recently INACTIVE nodes in
the recovery process.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13641
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit 202b9027ba44eee33c2fde2332126be10f719423)
Ensure that deleted records and vacuumed records are not resurrected
from recently inactive nodes.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13641
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit dcc9935995a5a7b40df64653a605d1af89075bd1)
This avoids unnecessary work during recovery to pull records from nodes
that were INACTIVE just before the recovery.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13641
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit 040401ca3abfa266261130f6c5ae4e9718f19cd7)
If a node becomes INACTIVE, then all the records in volatile databases
are invalidated. This avoids the need to include records from such
nodes during subsequent recovery after the node comes out INACTIVE state.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13641
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit 71896fddf10a92237d332779ccbb26c059caa649)
This allows the attempt to be cancelled if an election is lost and an
unlock is done before the attempt is completed.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13617
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Autobuild-User(master): Martin Schwenke <martins@samba.org>
Autobuild-Date(master): Tue Sep 18 02:18:30 CEST 2018 on sn-devel-144
(cherry picked from commit 486022ef8f43251258f255ffa15f1a01bc6aa2b7)
Autobuild-User(v4-8-test): Karolin Seeger <kseeger@samba.org>
Autobuild-Date(v4-8-test): Thu Sep 20 14:05:59 CEST 2018 on sn-devel-144
If the recovery lock is in the process of being taken then free the
cluster mutex handle but leave the recovery lock handle in place.
This allows ctdb_recovery_lock() to fail.
Note that this isn't yet live because rec->recovery_lock_handle is
still only set at the completion of the attempt to take the lock.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13617
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit b1dc5687844e90b0e3c39cb46a1116c86118fbf4)
This makes upcoming changes simpler.
Update to modern debug macro while touching relevant line.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13617
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit a755d060c13b65dfb6d73979aaf111c489882bfb)
... not just cluster mutex handle.
This makes the recovery lock handle long-lived and with allow the
releasing code to cancel an in-progress attempt to take the recovery
lock.
The cluster mutex handle is now allocated off the recovery lock
handle.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13617
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit c52216740bd81b68876de06e104822bbbca86df9)
At the moment this is still local and is freed after the mutex is
successfully taken.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13617
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit a53b264aee7d620ee8ecf9114b0014c5bb678484)
This will be a longer lived structure.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13617
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit af22f03dbe9040f5f743eb85bb50d411269bbab4)
If the master changed while trying to take the lock then fail gracefully.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13617
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit c516e58ce92c420dc993bd9b7f1433641bd764bd)
If SIGTERM is received and the tevent signal handler setup in the
recovery daemon is still enabled then the signal is handled and a
corresponding event is queued. The child never runs an event loop so
the signal is effectively ignored.
Resetting the SIGTERM handler isn't enough. A signal can arrive
before that.
Block SIGTERM before forking and then immediately unblock it in the
parent.
In the child, unblock SIGTERM after the signal handler is reset. An
explicit unblock is needed because according to sigprocmask(2) "the
signal mask is preserved across execve(2)".
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13617
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit e789d0da57fc3fc6d22bfa00577a2e65034ca27a)
If SIGTERM is received and the tevent signal handler setup in the
recovery daemon is still enabled then the signal is handled and a
corresponding event is queued. The child never runs an event loop so
the signal is effectively ignored.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13617
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 5a6b139884f08ee2ee10f9d16fe56ad8fb5352a6)
Confirmation is now received from eventd that it is accepting
connections, so this is no longer needed.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13592
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit b430a1ace69bcef3336907557ab5bf04271c1110)
The current method of retrying the connection to eventd means that
messages get logged for each failure.
Instead, pass a pipe file descriptor to eventd and wait for it to
write 0 to the pipe to indicate that it is ready to accept client
connections.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13592
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 62ec1ab1470206d6a2cf300f30ca0b4a39413a38)
Signed-off-by: Martin Schwenke <martin@meltin.net>
The pipe will soon be needed earlier, so initialise it earlier.
Ensure the file descriptors are closed on error.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13592
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit c446ae5e1382d5e32c33ce92243daf6b4338e15a)
Other errors free argv, so do it here too.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13592
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit e357b62fe556609750bdb8d27cf48dfb85c62ec8)
The daemon writes 0 into the specified file descriptor when it is up
and listening. This can be used to avoid loops in clients that
attempt to connect until they succeed.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13592
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit dc6040c121c65d5551c686f3f1be2891795f48aa)
Kill the ctdb_mutex_ceph_rados_helper with SIGKILL and then confirm
that the lock is automatically released following expiry.
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Samuel Cabrero <scabrero@suse.de>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Autobuild-User(master): David Disseldorp <ddiss@samba.org>
Autobuild-Date(master): Thu Aug 9 16:26:36 CEST 2018 on sn-devel-144
(cherry picked from commit 4abf348ec4cbb78d3216d5e8c5f3020d4499f10a)
RADOS locks without expiry persist indefinitely. This results in CTDB
deadlock during failover if the recovery master dies unexpectedly, as
subsequently elected recovery master nodes can't obtain the recovery
lock.
Avoid deadlock by using a lock expiration time (10s by default), and
renewing it periodically.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13540
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Samuel Cabrero <scabrero@suse.de>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit ce289e89e5c469cf2c5626dc7f2666b945dba3bd)
In preparation for adding a lock refresh timer.
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Samuel Cabrero <scabrero@suse.de>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 91a89c146453ca203a83dc2ba555bb93276c4d7f)
Set a handler for SIGINT to release the lock.
Signed-off-by: Samuel Cabrero <scabrero@suse.de>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 85706bd27535eaa4ec653f99b1910fbd8f2aab88)
ceph-common linkage is needed with new versions of Ceph.
Also respect the --libcephfs_dir=<path> parameter when provided.
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit bd64af6b8861f892e6ae2840a493f037d1e0a06c)
This is in addition to af697008531.
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): Thu Jul 5 15:22:16 CEST 2018 on sn-devel-144
(cherry picked from commit a30ac853ff9bca023c53ad98775eabb23156c566)
Autobuild-User(v4-8-test): Karolin Seeger <kseeger@samba.org>
Autobuild-Date(v4-8-test): Tue Jul 10 15:09:25 CEST 2018 on sn-devel-144
Setting DEBUGLEVEL before calling debug_init() causes segmentation
violation with gcc8. DEBUGLEVEL_CLASS is statically initialized to
debug_class_list_initial which is defined as const. Only after
debug_init() is called, DEBUGLEVEL_CLASS becomes a talloc'd array.
So before modifying DEBUGLEVEL, ensure debug_init() is called via
setup_logging(). (debug_init is a static function.)
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit af697008531bd74546656841dd3a1ed92522fc57)
Support backward compatibility by checking for __pmID_int type, which
was previously in <pcp/impl.h>. In the new version, this type is not
defined anymore and there is no need to include <pcp/impl.h>.
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 Mar 2 00:38:52 CET 2018 on sn-devel-144
(cherry picked from commit 426e4a5a20cff73a80d80b46f15826deac3f934f)
The comment immediately above this code says "don't allow local
clients to attach" and then looks up the client ID regardless of
whether the request is local or remote.
This means that an intentional remote attach from a client will not
work correctly. No real client should ever do that since clients
attach so they an access databases locally. Perhaps some sanity
checks should be added.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13500
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 63255ef92552da92956c05160f33622d0bbc3a28)
