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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
From Michael Anderson,
initialize the inqueue element of the ctdb structure to NULL,
else it might be used uninitialized and cause a segv.
(This used to be ctdb commit 775d02180b825ae32d6536eaf2059884d5fed9f4)
Add an input queue where we keep received pdus we have not yet processed
This allows us to perform SYNC calls from an ASYNC callback
(This used to be ctdb commit c111e98d3ad7bd3d09f4081e9bb1443d3722672f)
This function returns a pointer to a nodemap structure.
The returned structure must later be freed by calling ctdb_free_nodemap().
Move the definition of ctdb_sock_addr from ctdb_client.h to ctdb_protocol.h
Move the definition of the node flags, ctdb_node_and_flags and ctdb_node_map from ctdb_private.h to ctdb_protocol.h
Add both sync and async example for ctdb_getnodemap to the test application libctdb/tst.c
(This used to be ctdb commit 31c10eb2b337fd7d8a97a1f9e69b0e7570fec71d)
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)
This is a script which starts up a fake ctdbd and runs the libctdb
test suite.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 67ca040b07713d83385db63489c887f7156b7853)
Once we do operations which alter the TDBs, we need to restore them to
pristine state after a failed child dies.
The method used here is a terrible hack: it should at least do a
tdb_lockall() on the database before blatting it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit d48ec16bd2b4932442d95fc43bea52baa0425501)
Sometimes you just want to test that the basic test case is sane,
without all the failure paths being tested.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit be7c0bffb0d924c3e72753045d5b85ce90407579)
We include the file and line which called the functions, so the printed
failure path now looks like:
[malloc(ctdb.c:144)]:1:S[socket(ctdb.c:168)]:1:S...
The form is:
[ <function> ( <caller> ) ] : <input line> : <result>
<function> is the function which is called (eg. malloc).
<caller> is the file and line number which called <function>.
<input line> is the 1-based line number in the input which we were up to.
<result> is 'S' (success) or 'F' (failure).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 5fb6da30b5b5a8b761c8ab9a8124b87b759ef055)
Make children log through a pipe to the parent, which then spits it out
only if the child has a problem.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 8ac006cf6c6cbfd3fe1606178eb0f0127d33f632)
This introduces 'ctdb-test', a program for testing libctdb. It takes
commands on standard input (with reduced functionality) or an input file.
It still needs some cleaning up, but you can uncover a bug in libctdb
today simply by running a simple attachdb test:
$ ctdb-test tests/attachdb1.txt
It will print out a crash, and the path of successful and failed
operations which lead to it:
...
Child signalled 11 on failure path: [malloc]:1:S[socket]:1:S[connect]:1:S[malloc]:1:S[malloc]:1:S[malloc]:1:S[malloc]:4:S[malloc]:4:F
Feed that failure path into ctdb-test using --failpath (under a debugger):
gdb --args ctdb-test tests/attachdb1.txt --failpath=[malloc]:1:S[socket]:1:S[connect]:1:S[malloc]:1:S[malloc]:1:S[malloc]:1:S[malloc]:4:S[malloc]:4:F
And you hit the exact error.
It is based on the fork-to-fail model of nfsim. The relevant parts are
from page 154 of the proceedings of 2005 Ottawa Linux Symposium Volume II:
http://www.linuxsymposium.org/2005/linuxsymposium_procv2.pdf
Or our presentation of same (from slide 21):
http://ozlabs.org/~jk/projects/nfsim/nfsim.sxi
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit b4aab4199a57898877b6545a54f212087ed4b35a)
Because this doesn't use a generic callback, it's not quite as trivial
as the other sync wrappers.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 1f20b938d46d4fcd50d2b473c1ab8dc31d178d2d)
These are important for testing, since we can easily tell if we
leak memory if there are outstanding allocations after calling
these.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 18a212aa40d0ff9ff59775c6fcf9dc973e991460)
Found by nfsim.
I knew about this, but as we stop when it happens anyway I didn't fix
it. But it bugs nfsim, so fix it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 936b02443d36306407d6a26e8037cf31e3190b32)
Since I made this mistake myself, we should check for it.
We could have one function that does both, but from a user's point of
view they are very different and it's quite possibly a bug if they
think the request is finished/unfinished when it's not.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 70f6ed2634fb10749cdad3deffa96a1aa439c235)
A simple connector function, made a bit more complex because TDB adds
a '\n' and we don't.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit ae5b89dca00ca080c70868430fa54ba07bd6f5f4)
The code on which this is based could alter the header: a normal client
can't. If we use this differently later we can change this. For the
moment it's a nice extra check.
We optimize out the record write altogether when the record hasn't
changed, rather than just suppressing the seqnum update.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 2638dbae7bf1a35ed37802e35e179e435a5d622a)
I missed some int->bool conversions previously, particularly the
return of ctdb_writerecord().
By always handing functions ctdb_connection or ctdb_db, we keep it
consistent with the rest of the API and can do extra lock consistency
checks.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 3f939956ddd693cba6ea5c655288f4f5ca95f768)
Now we have more messages, it seems to make sense to document their usage
and make them consistent.
In particular, LOG_CRIT for internal libctdb problems, LOG_ALERT for
API misuse.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit a6fed3f577c7ec51df38ed15ecb9db6ea2ae7c8f)
Rather than using a binary, we use a magic value for locking. We also
split out the "dont have the lock yet" from the "do have the lock"
paths for clarity and extra checking.
This should detect a superset of the previous case, even if they free
(and reuse) the lock memory.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit dc081d40051b9204bb38e4de7dfe8d78656593d0)
Verify that the lock is still held and refuse the write otherwise.
We have to guarantee that we dont write to an unlocked record.
If we write to a record after it has been released, the record may have
already migrated off the node, in which case we get a DMASTER split brain for this record. (These application bugs are incredibly hard to track down)
(This used to be ctdb commit f62c7e44dc303f274bbc1dd59fad2167e72a2af0)
This allows us to keep the datastructure valid after the lock has been released by the application and we can trap and warn when the application is accessing the lock after it has been released. I.e. application bugs.
(This used to be ctdb commit 463a266205f145cd9c4c36b9c59d3747eeef0e2e)
Full documentation for all the functions.
This looks longer than it is, because it sorts them into async and
sync parts, and also renames some formal parameters.
Added TODO to libctdb directory to track our plans.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 108e9c2450876a9f8821aa7efd5be971eee5afd3)
Return bool instead of -1/0; that's what the young kids are doing
these days!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit e285b5d5a9d4fbc4f75dbb237d2fcdbd84f2d605)
In particular, this stops them grabbing two (with wrappers so we can
enhance this logic once we support threads), and warns them if they
re-enter ctdb_service() holding a lock (you are not supposed to block!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit c620cfbad3b5f0d6330ef47f572d4ade08e169e8)
This is based on Ronnie's work, merged with mine. That means
errors are all my fault.
Differences from Ronnie's:
1) use syslog's LOG_ levels directly.
2) typesafe arg to log function, and use it (eg stderr) in helper function.
3) store fn in ctdb context, and expose ctdb_log_level directly thru API.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 86259aa395555aaf7b2fae7326caa2ea62961092)
This is going to help for logging, since we want it there.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 0786152472bc43efae4c896f7c6c07c6e080b9b2)
Make the use of ctdb_release_lock() mandatory from the callback.
Split ctdb_release_lock() in two, release the tdb lock in the
ctdb_release_lock() function and move the freeing of the lock structure to ctdb_free_lock() which is private to libctdb.
When the callback returns, verify that the callback has actually released the lock and warn (FIXME) if not.
Update ctdb_writerecord to warn and fail (FIXME) if writing while the lock is not held.
(This used to be ctdb commit 87dc18a3a051da04685f14529c53c428d37c2912)
and psss it through the callback via private_data.
add a comment that the callback may sometimes have already been invoked
when the ctdb_readrecordlock_async() call returns
and that the application can use *private_data IF the application
needs to know if the callback has already triggered or not.
(This used to be ctdb commit 0ba458a91ba510215a9c8770286a68e19911515f)
After discussion with Ronnie, we decided to revisit this interface. We use
the name ctdb_readrecordlock_async, as it is *not* always a send, and we
use a specific callback to avoid the "fake request" creation on the fast
path.
The request itself is never exposed: this means it can't be cancelled,
but we can revisit that later if need be.
This makes both use and implementation simpler.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 03b5546ae45a60ab41eb4f7159a45bfdbf959888)
When attachdb failed, we were handing the db, not the user-supplied
arg to the callback.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 8626b6d7d4e5c747b6bac9d5e5b2cd302b6e144c)
PDUs are padded to 8 byte boundary. If padding is used, memset it to 0
to keep valgrind happy.
(This used to be ctdb commit 8818d5c483558c0faa6a3923ed5e675fdcfc13af)
change all calls to new_ctdb_request() to use the offset macro to calculate the correct size (instead of allocating one byte too many and hoping the alignment padding saves us.)
(This used to be ctdb commit 07b395258ab08218e8eed3b4a52654925b85275c)
Previously we could hang in poll with the callback pending (since we
fake it): explicitly call it immediately.
Note: I experienced corruption using DLIST_ADD_END (ctdb->pnn was blatted
when adding to the message_handler list). I switched them all to DLIST_ADD,
but maybe I'm using it wrong?
(This used to be ctdb commit 3727165f0d206999d2cfc2800ff8868640868c7c)
