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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
so that the dependencies are right
or else the dependencies all end up in the devel package and not the main
ctdb package
(This used to be ctdb commit 6e4347eb8e62c28987820f6e58626271c900b011)
This can cause ctdbd to spin at 100% in the eventsystem,
creating a timed event that will immediately trigger again
and again.
On uniprocessors this cause the eventscript we are actually waiting for to
basically become cpu starved and never complete.
(This used to be ctdb commit 92c8408fba957a8ded13f7e285da290502735234)
revert the defauls case back to only showing the ip and node
and only display the extra info if -v verbose output is requested
(This used to be ctdb commit 6488651aa7e105c57324f4a300760a010d098fbb)
port.
Default is to continue to show all tickles, but if a second argument
is given, only tickles for that port will be shown.
(This used to be ctdb commit 5b985eb2cbbb92bf6ccfcacd633d793bcd4e3ec1)
so set the TALLOC_DEPRECATED sympol to allow use of this call
from ctdb_client.c
(This used to be ctdb commit 3afa5d945a56952a7f211af068d671945de960e5)
sometimes (very rarely) fails to restart the service.
Add a function to restart NFSd on SLES and RHEL-like systems.
If we detect the system is unhealthy due to kNFSd not running,
try to restart the service again "service nfs restart" and
hope for the best.
CQ1019372
(This used to be ctdb commit 25c4ce7e919f13226219f036bcffd2be76b2f06c)
Add a new "ctdb deltickle" command to delete tickles from the database.
This can ONLY be used for tickles created by "ctdb addtickle".
Push any "addtickle/deltickle" updates to other nodes every TickleUpdateInterval seconds'
(This used to be ctdb commit acded034e2f0dcae4c2c9e54e16a001caf23caec)
This means we can distinguish which child is logging, esp. via syslog where we have no pid.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 68b3761a0874429b90731741f0531f76dcfbb081)
After 5 attempts to send a RST to a client without any response, we free
"con"; this is done during a traverse. This frees the node we are walking
through (the node is made a child of "con" down in rb_tree.c's
trbt_create_node() (Valgrind would catch this, as Martin confirmed).
So, we create a temporary parent and reparent onto that; then we free
that parent after the traverse, thus deleting the unwanted nodes.
CQ:S1019041
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 08f7f85477610a4916c1ec866aa467b28f1bbec3)
The existing code wasn't working as designed in the start event. It
should work here.
BZ: 62613
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit aeb70c7e7822854eb87873a5c7783e27e6e72318)
We shouldn't even think about vacuuming when we've frozen the database
(which is earlier than when we set CTDB_RECOVERY_ACTIVE)
CQ:S1018154 & S1018349
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit d8df6835a931082af232c4b94f1dede6f16169f9)
Martin Schwenke discovered that 517f05e42f17766b1e8db8f1f4789cbad968e304
("freeze: abort vacuuming when we're going to freeze.") used ctdb_db for
a logging message which is in fact uninitialized, causing a crash (even
if it wasn't actually logged).
Initialize it properly. Also fix incorrect format in another logging
message introduced in that same change.
CQ:S1019093
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 8e518950ba281502318d6300f7a5ec6cdf6b5674)
There are some reports of freeze timeouts, and it looks like vacuuming might
be the culprit. So we add code to tell them to abort when a freeze is
going on.
(This is based on the 1.0.112 branch version 517f05e42f, but far
simpler since tdb is now robust against processes being killed during
transaction commit)
CQ:S1018154 & S1018349
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit f5d7dc679501e607c2c83a248a89d3cada9df146)
This can be used to set ctdbd up to generate a tickle for non-samba
services.
(samba contains code to set tickles up automatically)
(This used to be ctdb commit 7ef2cddad5326fdcc26138906948342039829495)
In Samba this is now called "tevent", and while we use the backwards
compatibility wrappers they don't offer EVENT_FD_AUTOCLOSE: that is now
a separate tevent_fd_set_auto_close() function.
This is based on Samba version 7f29f817fa939ef1bbb740584f09e76e2ecd5b06.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 85e5e760cc91eb3157d3a88996ce474491646726)
This is based on SAMBA as at revision 2de63aa2801a907905b3e05557074af5b896d486.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit cecd93be0a0aab868430dd43f8276bfb4e35f02e)
(Imported from SAMBA 11ab43084b10cf53b530cdc3a6036c898b79ca38)
We saw tdb_lockall() take 71 seconds under heavy load; this is because Linux
(at least) doesn't prevent new small locks being obtained while we're waiting
for a big log.
The workaround is to do divide and conquer using non-blocking chainlocks: if
we get down to a single chain we block. Using a simple test program where
children did "hold lock for 100ms, sleep for 1 second" the time to do
tdb_lockall() dropped signifiantly. There are ln(hashsize) locks taken in
the contended case, but that's slow anyway.
More analysis is given in my blog at http://rusty.ozlabs.org/?p=120
This may also help transactions, though in that case it's the initial
read lock which uses this gradual locking routine; the update-to-write-lock
code is separate and still tries to update in one go.
Even though ABI doesn't change, minor version bumped so behavior change
can be easily detected.
CQ:S1018154
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 9ec0009443a0ac4187ce5212a5143689daa58a02)
(Import from SAMBA bc1c82ea137e1bf6cb55139a666c56ebb2226b23)
The function tdb_lockall() uses F_WRLCK internally, which doesn't work on
a fd opened with O_RDONLY. Use tdb_lockall_read() instead.
(This used to be ctdb commit a5db1122ec48d7e7384066848457c850c1a6cf3c)
Commit 207a213c/24fed55d purported to fix the problem of signals during
tdb_new_database (which could cause a spurious short write, hence a failure).
However, the code is wrong: newdb+written is not correct.
Fix this by introducing a general tdb_write_all() and using it here and in
the tracing code.
Cc: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 27ba0e5a6681063225df7244a85aa304c51c6948)
It turns out that we *do* want a separate private arg for the message
handler and the completion callback, so we change that.
We also fix the prototypes of the remove_message functions as we
implement them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 332375246eccd95da626f434f6d49dd9458a9787)
In some contexts ctdb_diagnostics generates too many errors when it is
run on heterogeneous and machine-configured clusters. In some
clusters some nodes are expected to be differently configured and also
machine-generated configured files can have comments containing
timestamps.
This adds some command-line options that can be used to reduce the
number of errors reported:
-n <nodes> Comma separated list of nodes to operate on
-c Ignore comment lines (starting with '#') in file comparisons
-w Ignore whitespace in file comparisons
--no-ads Do not use commands that assume an Active Directory Server
The -n option simply allows ctdb_diagnostics to operate on a subset of
nodes, avoiding file comparisons with and data collection on nodes
that are differently configured. For file comparisons, instead of
showing each file on the current node and then comparing other nodes
to that file, the file from the first (available or requested) nodes
is shown and then other nodes are compared to that. That has resulted
in changes in output - that is, ctdb diagnostics no longer prints
messages referencing the current node.
-c and -w are used to weaken comparisons between configuration files.
--no-ads can be used to avoid running ADS-specific commands if a
cluster uses LDAP (or other non-ADS) configuration.
This also fixes a number of bugs in related code:
* A call to onnode was losing the >> NODE ... << lines because they
now go to stderr. This was changed in onnode long ago but
ctdb_diagnostics was never updated to match.
* ctdb_diagnostics was counting lines in /etc/ctdb/nodes to determine
what nodes to operate on. For some time the nodes file has
supported syntax that makes this invalid. "ctdb listnodes -Y" is
now used to list available nodes.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit 36c8244a0f68c7c9bbee40982f230e9d14d3c0ea)
These tests currently wait for the old IPs to fail back to the test
node. This isn't guaranteed with DeterministicIPs disabled.
This changes those tests to wait until the test node gets at least 1
IP assigned.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit e9b3f5b1b51d541a911a27eb4348b368f28d185e)
Currently we do a "sleep 1" after starting and before running
set_ctdb_variables to set the tunables. This is too arbitrary and
might fail if the system is heavily loaded. This, for example, could
result in some nodes running with DeterministicIPs and some without,
in which case a different IP allocation algorithm would run depending
on who is the recmaster!
This makes the start function wait until "ctdb ping" succeeds (with 10
second timeout) before trying to run set_ctdb_variables. If a timeout
occurs then the start function attempts to kill ctdbd before exiting
with a failure.
It also cleans up the status reporting code for Red Hat and SUSE so
that the final status code is reported. Currently there are cases
where a correct status is prematurely reported before a failure
occurs.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit cdcd05662a30b51caaeeab4ac44138cac2474e0a)
Recent CTDB notice the wrap and print this message. The test needs to
cope.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit b93b60ec96d02ce4f54921e85a5c5554d1fc0c55)
They test debugging commands that no longer operate as expected.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit d33fa4d6557aab1938049f194c2de55f2c395bd2)
The test currently checks that all existing IPs plus the newly added
IP are on the test node after "ctdb addip" is run. With
DeterministicIPs enabled, if the new IP is "before" other IPs then the
other IPs may be shuffled by the deterministic IPs modulo algorithm.
This will happen on the 1st recovery after the move. Sometimes this
recovery happens before we get the list of IPs to check and sometimes
after, so the test is racy.
The fix is to simply check for the presence of the new IP and not
worry about the others. This reduces whatever value this test
had... but you can't have everything.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit 1ef7c8e64c7a39330be09ae4d00b70238133e0b5)
This test is failing in some situations. The "ctdb addip" command
works but the IP never appears in the "ctdb ip" output.
Try restricting the last octet to be between 101-199. At the moment
addresses like 10.0.2.1 are being chosen and these are often the
address of the host machine in autocluster configurations... so might
cause weirdness.
Also add some debugging if checking for the IP address times out.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit ae52cb63756bc60de8d32e01bac5d70975a1c7a0)
Group options better and make the language consistent between options.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit bc38c17e4115fae00c89d00537fdcfe621111b37)
