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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We shouldn't set ctdb->current_monitor until we set destructor: that's
what cleans it up.
Also, free state->scripts on no-scripts exit path: it's not a child of
state because we need it in the destructor.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 843a2ed5ef85f628788b0caf7417c6b61b5c6d3f)
Previously we updated cb_status a each script finished. Since we're storing
the status anyway, we can calculate it by iterating the scripts array
itself, providing clear and uniform behavior on all code paths.
In particular, this fixes a longstanding bug when we abort monitor
scripts to run some other script: the cb_status was uninitialized. In
this case, we need to hand *something* to the callback; 0 might make
us go healthy when we shouldn't. So we use the last status (normally,
this will be the just-saved current status).
In addition, we make the case of failing the first fork for the script
and failing other script forks the same: the error is returned via the
callback and saved for viewing through 'ctdb scriptstatus'.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 5d50f0e16948d18009f6623f132113f7273efc7f)
We don't want ctdb stalling due to paging; this can be far worse than
scheduling delays. But if we simply do mlockall(MCL_FUTURE), it
increases the risk that mmap (ie. tdb open) or malloc will fail,
causing us to abort.
This patch is a compromise: we mlock all current pages (including
10k of future stack for expansion) and then relock when a client
asks us to open a TDB. We warn, but don't exit, if it fails.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 82f778e85440bc713d3f87c08ddc955d3cfce926)
1) It's buggy. Code needs to be carefully written (ie. no busy
loops) to handle running with it, and we fork and run scripts.[1]
2) It makes debugging harder. If ctdbd loops (as has happened recently)
it can be extremely hard to get in and see what's happening. We've already
seen the valgrind hacks.
3) We have seen recent scheduler problems. Perhaps they are unrelated,
but removing this very unusual setup is unlikely to hurt.
4) It doesn't make anything faster. Under all but the most perverse of
circumstances, 99% of the cpu gives the same performance as 100%, and
we will always preempt normal processes anyway.
[1] I made this worse in 0fafdcb8d353 "eventscript: fork() a child for
each script" by removing the switch_from_server_to_client() which
restored it, but even that was only for monitor scripts. Others were
run with RT priority.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 482c302d46e2162d0cf552f8456bc49573ae729d)
The do_setsched was being tested for whether to mmap tdbs: let's make it
explicit. We can also happily move the kill-child eventscript hack under
this flag.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 2ee86cc1f311d7b7504c7b14d142b9c4f6f4b469)
Depending on --max-persistent-check-errors we allow ctdb
to start with unhealthy persistent databases.
The default is 0 which means to reject a startup with
unhealthy dbs.
The health of the persistent databases is checked after each
recovery. Node monitoring and the "startup" is deferred
until all persistent databases are healthy.
Databases can become healthy automaticly by a completely
HEALTHY node joining the cluster. Or by an administrator
with "ctdb backupdb/restoredb" or "ctdb wipedb".
metze
(This used to be ctdb commit 15f133d5150ed1badb4fef7d644f10cd08a25cb5)
All other scripts do 'loadconfig ctdb' before any other 'loadconfig foo'
call. I think we should do the same in statd-callout.
Otherwise it's very confusing, if you have configured some Options
in /etc/sysconfig/ctdb, but /etc/ctdb/statd-callout doesn't notice
them.
metze
(This used to be ctdb commit 10d95581fb90bfdf58ec32345c4e36c27acf4f37)
(cherry picked from commit 4334092cba)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 093f57a2c00f2d629a3b58e58202f1a7e1bbd406)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(cherry picked from samba commit 9776cb0345)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit d1873bd81bfc9f486b88f3a38c65c7de8f5a0909)
metze
(cherry picked from samba commit 5ca0a4bfd6)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 04aeac728f56c65b973762f09977de1b1b99099e)
We need to keep TDB_ALLOW_NESTING as default behavior,
so that existing code continues to work.
However we may change the default together with a major version
number change in future.
metze
(cherry picked from samba commit 3b9f19ed91)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit c1c0ede32dc00ed619d1cf5fda40a9de43995f3a)
metze
(cherry picked from samba commit 85449b7bcc)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 855391c1e37012b0d6c673a304bb8da8a1efcd72)
While studying tdb, I've noticed a couple of mismatches between readme
and actual code:
- tdb_open_ex changed it's log_fn argument to log_ctx
- there is now no tdb_update(), which it seems was transformed into
non-exported tdb_update_hash()
There were other mismatches, but I don't remember them now, sorry.
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from samba commit 83de5c8263)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 7a88f1df9190674deaf5dcbedad02ae4120a5263)
The reason I do it is that when using older python-tdb as shipped in
Debian Lenny, python interpreter crashes on this test:
(gdb) bt
#0 0xb7f8c424 in __kernel_vsyscall ()
#1 0xb7df5640 in raise () from /lib/i686/cmov/libc.so.6
#2 0xb7df7018 in abort () from /lib/i686/cmov/libc.so.6
#3 0xb7e3234d in __libc_message () from /lib/i686/cmov/libc.so.6
#4 0xb7e38624 in malloc_printerr () from /lib/i686/cmov/libc.so.6
#5 0xb7e3a826 in free () from /lib/i686/cmov/libc.so.6
#6 0xb7b39c84 in tdb_close () from /usr/lib/libtdb.so.1
#7 0xb7b43e14 in ?? () from /var/lib/python-support/python2.5/_tdb.so
#8 0x0a038d08 in ?? ()
#9 0x00000000 in ?? ()
master's pytdb does not (we have a check for self->closed in obj_close()),
but still...
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from samba commit 71a21393dd)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 03372b4ea8ba2938468a5c0fc234d604966ce070)
So that erroneous double tdb_close() calls do not try to close() same
fd again. This is like SAFE_FREE() but for fd.
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from samba commit b4424f8234)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit f5c992bdaeb73ef726ff4728a9922721474cd6f5)
It's Tdb.get(), not Tdb.fetch().
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from samba commit cfed5f946d)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 76aacdd8e1106f26565e25903091a757b59cd7e2)
This can help with ldb where we rewrite the index records
(cherry picked from samba commit d4c0e8fdf0)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 470750fa2e3cf987f10de48451b1ee13aab03907)
metze
(cherry picked from samba commit 3b62e250c0)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 03b3682e3fa53c9f5fdf2c4beac8b5d030fd2630)
Also, set logging function so we get more informative messages.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from samba commit 0944931159)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 6ac7ef8bf4d384f880c7f483ace70f8e08c15a8b)
ctdb wants a quick way to detect corrupt tdbs; particularly, tdbs with
loops in their hash chains. tdb_check() provides this.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from samba commit 022b4d4aa6)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit df1a3ce0380fa9d8722b2f9b16f65557095e4c83)
We no longer use swig for pytdb, so there is no need for swig make
rules. Also pytdb.c header should be updated.
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from samba commit ecbe5ebd8d)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 27611d6a0c313732e438cb24c82b9de126e50156)
This fixes the build on Tru64.
metze
(cherry picked from samba commit 3718cf294a)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 5652e403be099f35cdd29fda8ba4fe2c35de8035)
With the ctdb checkin dde9f3f006 tdb optimized out write lock checks for
write-enabled transaction. Sadly, this also removed the possibility to ever
remove dead records left over from tdb_delete calls within a transaction.
Tridge, please check this! Did dde9f3f006 have any reason beyond performance
optimizations?
Thanks,
Volker
(cherry picked from samba commit 3f884c4ae3)
(This used to be commit 1d85e0647e)
(cherry picked from samba commit 8c88209c6f)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit b02bf7659f04f1fa203834bd75a2392b48e56c16)
Found by cppcheck:
[lib/tdb/tools/tdbtorture.c:326]: (error) Memory leak: pids
(cherry picked from samba commit 497b9e460b)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 5d4cc4b018a538dc3f1d79fe091f3e6e67003daf)
tdbbackup was originally written before we had transactions, and it
attempted to use its own fsync() calls to make it safe. Now that we
have transactions we can do it in a much safer (and faster!) fashion
(cherry picked from samba commit 2e4247782b)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit cd23d36ada9631095ca68663516de0c8d8c3bbed)
This means you can kill it at any time and expect no corruption.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from samba commit 0fc6800005)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit f7278a277ed91587cae5b5e3660dad7124bdb73f)
It was a regrettable hack which I used to reduce line count in tdb; in fact it caused confusion as can be seen in this patch.
In particular, ecode now needs to be set before TDB_LOG anyway, and having it exposed in
the header is useless (the struct tdb_context isn't defined, so it's doubly useless).
Also, we should never set errno, as io.c was doing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from samba commit b77f41d58b)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit a6620f6e74aadc708395b21b42303d1082192fcc)
When TDB_TRACE is defined (in tdb_private.h), verbose tracing of tdb operations is enabled.
This can be replayed using "replay_trace" from http://ccan.ozlabs.org/info/tdb.
The majority of this patch comes from moving internal functions to _<funcname> to
avoid double-tracing. There should be no additional overhead for the normal (!TDB_TRACE)
case.
Note that the verbose traces compress really well with rzip.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from samba commit 703004340c)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit b01b756cb577f32a1ec4597efb00017241e01685)
There was a race condition that caused the torture.tdb to be left in a
state that needed recovery. The torture code thought that any message
from the tdb code was an error, so the "recovered" message, which is a
TDB_DEBUG_TRACE message, marked the run as being an error when it
isn't.
(cherry picked from samba commit 5dcf0069b6)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 43c97b259b19c42b4edc7f83dbfc5e486568b4e3)
Michael
(cherry picked from samba commit e440a2e11e)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit c1b8d32b4ef87b9d8f37b451f47fcee2ea753d21)
This adds 3 simple speed tests to tdbtool, for transaction store,
store and fetch.
On my laptop this shows transactions costing about 10ms
(cherry picked from samba commit e15027155d)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 463279c972fa4538919bdd1dff48ca6b2fb8d49c)
So one can perform tdbtool operations protected by transactions.
Michael
(cherry picked from samba commit 91e1bab2e9)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 35a5b874b925380f7c227e47aebb590c9db4739e)
Michael
(cherry picked from samba commit 817383d88d)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit dc287a7d7420cca0b104049e689a73202bc535f8)
We previously only allowed a commit to happen after a prepare
commit. It is in fact safe to allow reads between a prepare and a
commit, and the s4 replication code can make use of that, so allow it.
(cherry picked from samba commit 46c99ec2a3)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 5ef5ddb8369e5e76173285fe9a08498dc8dc73ab)
Michael
(cherry picked from samba commit 55dcf928eb)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit ef1dc585d869a9e48164cd65bafc92c1da245007)
Michael
(cherry picked from samba commit cfa4e7ec75)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 0ae735b7a2096a40e5e47086ec41d9d45ef6d36b)
Michael
(cherry picked from samba commit 25939a627f)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 2e69647404c87c438ae7c180277ac3b532941efd)
by first concatenating multilint parentheses and removing typefes afterwards.
Michael
(cherry picked from samba commit 13bfcd5a93)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 37225f1ed3f70d7259c2af2c51c671105c34476a)
Michael
(cherry picked from samba commit ecd12bfb38)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 66fffa577e051212ac7541be906b6c80f4a7c0c9)
Michael
(cherry picked from samba commit 400f08450b)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 310d673b7cb9000d76437d78e43bc2bf133e4e14)
Michael
(cherry picked from samba commit 907e05595f)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit f70e371d70e334a7254649b2bb09aa382e6f09bb)
Guenther
(cherry picked from samba commit 1c2f4919ab)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 9d5015e6fc68d3eb9e7b7178dbaf8c129dc79471)
USAGE: abi_checks.sh LIBRARY_NAME header1 [header2 ...]
This creates symbol signature lists using the mksyms and mksigs scripts
and compares them with the checked in lists.
Michael
(cherry picked from samba commit 9636e0d373)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 724d71dc838750fff91a45359feeb6e71bf0a4c7)
This produces output like the output gcc produces when
invoked with the -aux-info switch.
Run like this: cat include/tdb.h | ./script/mksigs.pl
This simple parser is probably too coarse to handle all
possible header files, but it treats tdb.h correctly...
Michael
(cherry picked from samba commit 0760a04ef9)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 141422d9dc24b15b7b8bc7831adab90367a729f7)
Michael
(cherry picked from samba commit 006fd0c43c)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit aed864dceaf6ec1e6e6066a587c708b485901200)
In future, this may happen, and we don't want to clobber them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from samba commit 398d0c2929)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit eebd467961dad6cfb38c2a5d6e4b4dbf86e55e63)
On systems with 32 bit offsets, expansion and fcntl locking on these records
will fail anyway. SAMBA already does '#define _FILE_OFFSET_BITS 64' in
config.h (on my 32-bit x86 Linux system at least) to get 64 bit file offsets.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from samba commit 252f7da702)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
(This used to be ctdb commit 2d768f664e6db65b3b7e0c732f33ee2b806892f9)
This reverts commit 401f421fa003d9515df15e759b50b56e0c67d69c.
Conflicts:
include/ctdb_private.h
server/ctdb_tunables.c
(This used to be ctdb commit b883d19a495a41a22db37f9c2cf6250fee529de0)
Date: Tue Dec 15 15:53:30 2009 +1030
eventscript: hack to avoid overloading valgrind
Now we fork one child per script, when running under valgrind the
load
gets quite high. This is because valgrind does a lot of work after
exit,
and we don't wait for the children to finish; we start the next one
when
the child reports status via the pipe.
This fix is ugly, but simple.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 6ed34d5320c39d8a55f2a36ad4c1ab574e0b0796)
I saw once where the master ctdbd logging structure was talloc freed
which caused issues.
So only free the structure if it is NOT the master structure.
This needs to be looked into in more detail.
(This used to be ctdb commit bcf494b81f4277dc75f05faccf0c446bd15f6e2b)
or else we can crash if we receive log messages from a child but the log structure has been freed()
(This used to be ctdb commit ea9e39369379939abf6a4076fa2014c10c1a9ad0)
Subject: eventscript: fix spinning at 100% cpu when child exits.
ctdbd was spinning reading 0 from a pipe, as soon as the first
eventscript finishes.
This was caused by the intersection between a78b8ea7168e "Run only one
event for each epoll_wait/select call" and 32cfdc3aec34 "eventscript:
ctdb_fork_with_logging()". Unavoidable mid-air collision, since both
worked fine and both were developed simultaneously.
When the script exits, we have two pipes open to it: one for any
stdout/stderr for logging (ctdb_log_handler), and one for the result
(ctdb_event_script_handler). The latter frees everything, including
the log fd and event structure.
We used to get one callback to ctdb_log_handler, which got a harmless
0-length read, then one to ctdb_event_script_handler which cleaned up.
Now we only do one callback per poll, we need the logging function to
clean itself up so we can make process.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 211ea7907e8e96041aa6f7d086551d64d065a8a3)
since we no longer ban nodes when dodgy scripts continue to hang.
We now only mark nodes as unhealthy if monitor events fail or timeout. Never ban.
(This used to be ctdb commit 5c8e56fc7a518e115bceac257867739283cf6a1e)
In other news, did you know ctime() returns a \n-terminated string?
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 1b4e7bb548976b99f122142b040494b6f9911962)
Commit c1ba1392fe "eventscript: get rid of ctdb_control_event_script_finished
altogether" was wrong: there is one case where we want to free the script
without transferring their status to last_status. This happens because we
always kill an running monitor command when we run any other command.
This still isn't quite right (and never was): the callback will be called
with status value 0, which might flip us to HEALTHY if we were unhealthy.
This is conveniently fixed in my next set of patches :)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 0ea0e27d93398df997d3df9d8bf112358af3a4a5)
there is no rational need for a setting where we permanently mark nodes as disabled everytime an eventscript fails
(This used to be ctdb commit 68a8ee99b128a5ec883600735626bdb3bbc9c503)
This reverts commit 8aef46d2aab3efb322dda51eaa202653cefd5222.
This special recovery logic is wrong now with the transaction rewrite.
The treatment of persistent databases will later be rewritten to use the
database sequence number.
Michael
(This used to be ctdb commit c5a0aef668a63f927d6184612b13ce316eb4a0be)
This patch improves the handling of the fetch_lock operation on non-persistent
databases that ctdb clients have to do very frequently.
The normal flow how this goes is the following:
1. Client does a local fetch_lock on the database
2. Client looks if the local node is dmaster.
If yes, everything is fine
If no, continue here
3. Client unlocks the local record
4. Client issues a "get me the record" call to ctdbd
5. ctdbd goes out and fetches the dmaster role
6. ctdbd tells the client to retry
7. Client starts over again
The problem is between step 6 and 7: Before the client has had the chance to
retry (i.e. catch the record with a fetch_locked), another node might have come
asking ctdbd to migrate away the record again. This is a real problem, I've
seen >20 loops of this kind in real workloads.
This patch does the following: Whenever ctdb receives a record as result of
step 5, it puts the key on a "holdback list". As long as a key is on this list,
a request to migrate away the dmaster is put on hold. It is the client's duty
to issue the "CTDB_CONTROL_GOTIT" control when it has successfully done step 2
after having asked ctdb to fetch the record. This will release the key from the
"holdback list" and re-issue all dmaster migration requests.
As a safeguard against malicious clients, once a second (default 1000msecs,
tunable "HoldbackCleanupInterval" in milliseconds) ctdbd goes over the list of
held back keys, deletes them and releases all held back migration requests.
(This used to be ctdb commit 5736e17c139c9a8049e235429aeae0c6c9d0e93d)
Make it return success for make test.
This is temporarily disabled until the rewrite of the
transaction code (in samba and the daemon) using the global
lock feature has been ported to the ctdb client code.
Michael
(This used to be ctdb commit 78ca29352aa39f4ef4e41096b92d55cb2e0d348a)
This is a simplified version of the trans2 commit control:
It just rolls out the marshall buffer to all active nodes.
It is the main ctdbd part of the re-implementation of the
persistent transactions. The client code is changed to
take a global lock to start a transactions and store into
the marshal buffer instead of writing to the local tdb
under a local transaction.
The old transaction implementation is going to be
removed in a later commit.
Michael
(This used to be ctdb commit f66428f9d2013080a414404c1ba6117888352fd6)
Date: Wed, 9 Dec 2009 22:45:12 +0100
Subject: [PATCH] Revert an accidential commit
(This used to be ctdb commit af6656f2844d8fd72204a70358c9d589dbe1bd34)
Writes without transaction are not possible any more on
persistent databases.
Michael
(This used to be ctdb commit 59f46d7261dfdbdef900bf95dd9eb28ad22a46b2)
This is useless now that persistent write operations without
transaction are forbidden.
Michael
(This used to be ctdb commit b022863d44026c19d5aae54aa485b670bea0540e)
This is useless now that persistent writes without transactions are forbidden.
Michael
(This used to be ctdb commit 9ac82311d796e1fab31f8de62b8ccc754445093c)
This is like the 53_ctdb_transaction test, but it additionally
runs a loop with recoveries while the transactions are running.
When called like this, the transaction loops run for 10 minutes:
CTDB_TEST_TIMELIMIT=600 tests/scripts/run_tests tests/simple/54_ctdb_transaction_recovery.sh
The default timelimit is 30 seconds.
Michael
(This used to be ctdb commit 2ff2679e8f3d50ebf735f2c420898a84268bdc95)
This gets just too noisy on a busy system.
And it is purley informational anyways...
Michael
(This used to be ctdb commit 7f64a00c76203fdf6673c3f862a4bfd17fb848d7)
This might be a bit less efficient, but experience in winbind has shown that
event callbacks can trigger changes in the socket state in very hard to
diagnose ways.
(This used to be ctdb commit a78b8ea7168e5fdb2d62379ad3112008b2748576)
syslog.h says:
LOG_NOTICE 5 normal but significant condition
LOG_INFO 6 informational
several vacuuming related logs logged at NOTICE level although I don't see
any real significance, these are just informational messages for me
Signed-off-by: Christian Ambach <christian.ambach@de.ibm.com>
(This used to be ctdb commit 142111983c103e90ccccbe26fd580c4eb28e949f)
add the __location__ macro to the logs to get a better idea
in which loop the problem occured
Signed-off-by: Christian Ambach <christian.ambach@de.ibm.com>
(This used to be ctdb commit dccb549fd6a6e338063699544e52f2a1a6a966b5)
when checking link status for an interface, first
check if this interface is in fact a bond device
(by the precense of a /proc/net/bonding/IFACE file)
and use that file for checking status.
Othervise assume ib* is an infiniband interface which we donnt know how
to check, or otherwise it is an ethernet interface and ethtool should
hopefully work.
(This used to be ctdb commit 8cc6c5de3d7abb0b72eaa6e769e70963b02d84cb)
We also no longer return an error before scripts have been run; a special
zero-length data means we have never run the scripts.
"ctdb scriptstatus all" returns all event script results.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 9b90d671581e390e2892d3a68f3ca98d58bef4df)
We're going to need this so ctdb can query non-monitor status.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 53bc5ca23ca55a3ac63a440051f16716944a2a51)
Ronnie suggested this; seems like a very good idea.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 93153bca68926401dc9ae7fd77ed3f17be923344)
We always have to call it before freeing the state; we should just do
this work in the destructor itself.
Unfortunately, the script state would already be freed by the time
the state destructor is called, so we make the script state a child of
ctdb, and talloc_free() it manually on the one path which doesn't use
the destructor.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit c1ba1392fe52762960e896ace0aca0ee4faa94d5)
Rather than only tranferring to last_status for monitor events, do
it for every event (ctdb->last_status is now an array).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit c73ea56275d4be76f7ed983d7565b20237dbdce3)
We only need ctdb->current_monitor so we can kill it when we want to run
something else; we don't need to use it here as we always know what script
we are running.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 4cf1b7c32bcf7e4b65aec1fa7ee1a4b162cac889)
The only difference between the exposed an internal structure now is
that the name and output fields were pointers. Switch to using
ctdb_scripts_wire/ctdb_script_wire internally as well so marshalling
is a noop.
We now reject scripts which are too long and truncate logging to the
511 characters we have space for (the entire output will be in the
normal ctdbd log).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit fd2f04554e604bc421806be96b987e601473a9b8)
We're going to allow fetching status of all script runs, so this
name is no longer appropriate.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit f5cb41ecf3fa986b8af243e8546eb3b985cd902a)
This neatens the code slightly. We also use the name 'current' in
ctdb_event_script_handler() for uniformity.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit e9661b383e0c50b9e3d114b7434dfe601aff5744)
This brings us closer to the wire format, by using a simple array
and a 'current' iterator.
The downside is that a 'struct ctdb_script' is no longer a talloc
object: the state must be passed to our log fn, and the current
script extracted with &state->scripts->scripts[state->current].
The wackiness of marshalling is simplified, and as a bonus, we can
distinguish between an empty event directory
(state->scripts->num_scripts == 0) and and error (state->scripts ==
NULL).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 76e8bdc11b953398ce8850de57aa51f30cb46bff)
This unifies almost everything: the state->current pointer points to
the struct ctdb_script where we record start, finish, status and
output.
We still only marshall up the monitor events; the rest disappear when
the state structure is freed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit c476c81f3e3d8fc62f2e53d82fce5774044ee9ce)
We rename ctdb_monitor_script_status to ctdb_script, and instead of
allocating them as the scripts are executed, we allocate them up front
and keep a "current" interator.
This slightly simplifies the code, though it means we only marshall up
to the last successfully run script.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit b2a300768536d10bd867a987ad4cf1c5268c44bc)
A new helper functions which sets up an event attached to the child's
stdout/stderr which gets routed to the logging callback after being
placed in the normal logs.
This is a generalization of the previous code which was hardcoded to
call ctdb_log_event_script_output.
The only subtlety is that we hang the child fds off the output buffer;
the destructor for that will flush, which means it has to be destroyed
before the output buffer is.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 32cfdc3aec34272612f43a3588e4cabed9c85b68)
The current logging logic assumes that any stdout/stderr belongs to
the currently running monitor script output. This isn't quite right
anyway, and we'd like to capture stderr output of other script
invocations.
So we move towards multiple struct ctdb_log_state by handing it
directly to ctdb_log_handler to use, rather than having it assume
ctdb->log. We need a ctdb pointer inside the log struct now though.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 497766cf186442de00fb324343150442457be858)
The child no longer uses ctdb_ctrl_event_script_init or
ctdb_ctrl_event_script_finished, and the others are redundant: it
doesn't need to tell us it's starting a script when it only runs one.
We move start and stop calls to the parent, and eliminate the RPC
infrastructure altogether.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 391926a87a7af73840f10bb314c0a2f951a0854c)
We do the same thing in two places: fire off a child from the initial
ctdb_event_script_callback_v() and also from the ctdb_event_script_handler()
when it's done.
Unify this logic into fork_child_for_script().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 814704a3286756d40c2a6c508c1c0b77fa711891)
We rename child_run_scripts() to child_run_script(), because it now
runs a single script rather than walking the list. When it's
finished, we fork the next child from the ctdb_event_script_handler()
callback.
ctdb_control_event_script_init() and ctdb_control_event_script_finished()
are now called directly by the parent process; the child still calls
ctdb_ctrl_event_script_start() and ctdb_ctrl_event_script_stop() before
and after the script.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 0fafdcb8d3532a05846abaa5805b2e2f3cee8f47)
This means all the state about running the scripts is in that structure,
which helps in the next patch.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 020fd21e0905e7f11400f6537988645987f2bb32)
We put a "scripts" member in ctdb_event_script_state, rather than using
a special struct for monitor events. This will fit better as we further
unify the different events, and holds the reports from the child process
running each monitor script.
Rather than making the monitor state a child of current_monitor_status_ctx,
we just point current_monitor directly at it. This means we need to reset
that pointer in the destructor for ctdb_event_script_state.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 9a2b4f6b17e54685f878d75bad27aa5090b4571f)
We have monitor_event_script_ctx and other_event_script_ctx, and
current_monitor_status_ctx in struct ctdb_context. This seems more
complex than it needs to be.
We use a single "event_script_ctx" as parent for all event script
state structures. Then we explicitly reparent monitor events under
current_monitor_status_ctx: this is freed every script invocation to
kill off any running scripts anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 0d925e6f2767691fa561f15bbb857a2aec531143)
Simple refactoring in preparation for switching to one-child-per-script.
We also call the functions run by the child process "child_".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit bfee777faff75e9bed4aedc1558957483616a6d3)
This is the start of a move towards finer-grained reporting, with one
child per script. Simple code motion to do sanity check and get the
list of scripts before fork().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 816b9177f51ae5b21b92ff4a404f548fe9723c96)
If we've timed out, but we've not timed out more than
ctdb->tunable.script_ban_count, we pretend we haven't.
There's a logic bug in the way this is done: if we were unhealthy before,
this would set us to "healthy" again (status == 0). I don't think this
would happen in real life, but it's a little surprising.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit e6488c0e05bab5c4c2c0a6370930b0b27e5ed56e)
Currently the timeout handler in eventscript.c does the banning if a
timeout happens. However, because monitor events are different, it has
to special case them.
As we call the callback anyway in this case, we should make that handle
-ETIME as it sees fit: for everyone but the monitor event, we simply ban
ourselves. The more complicated monitor event banning logic is now in
ctdb_monitor.c where it belongs.
Note: I wrapped the other bans in "if (status == -ETIME)", though they
should probably ban themselves on any error. This change should be a
noop.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 9ecee127e19a9e7cae114a66f3514ee7a75276c5)
eventscript.c uses this now, but our next patch makes others use it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit a305cb7743c24386e464f6b2efab7e2108bb1e7e)
If we time out just as the child exits, we currently will report an
uninitialized cb_status field. Set it to -ETIME as expected.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 024386931bda9757079f206238ae09bae4de6ea2)
This completes our "problem with script" reporting; we never set cb_status
to -1 on error. Real errnos are used where the failure is a system call
(eg. read, setpgid), otherwise -EIO is used if we couldn't communicate with
the parent.
The latter case is a bit useless, since the parent probably won't see
the error anyway, but it's neater.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 1269458547795c90d544371332ba1de68df29548)
If we break, we avoid cut & paste code inside the loop. Need to initialize
ret to 0 for the "no scripts" case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit ec36ced9446da7e3bf866466d265ee8e18f606c1)
Rather than ignoring deleted event scripts (or pretending that they were "OK"),
and discarding other stat errors, we save the errno and turn it into a negative
status.
This gives us a bit more information if we can't execute a script (eg.
too many symlinks or other weird errors).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 5d894e1ae5228df6bbe4fc305ccba19803fa3798)
This unifies code paths and simplifies things: we just hand -ENOEXEC to
ctdb_ctrl_event_script_stop().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit eadf5e44ef97d7703a7d3bce0e7ea0f21cb11f14)
We currently assume 127 == script removed. The script can also return 127;
best to re-check the execution status in this case (and for 126, which will
happen if the script is non-executable).
If the script is no longer executable/not present, we ignore it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 0a53d6b5ac81daf0efa32f35e7758ede2a5bdb63)
This is used later in the "script vanished" check.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 8ddb97040842375daf378cbb5816d0c2b031fa65)
As we start to use errno more, it's a huge pain if talloc_free() can blatt
it (esp. destructors).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 76a0ca77feba14e1e1162c195ffbdf516e62aa4d)
This starts the move toward more expressive encoding of return values:
positive values mean the script ran, negative means we had a problem with
the script (and the value is the errno).
This does timeout, but changes the ctdb tool to recognize it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 0eb1d0aa14e68b598d9e281c8a02b8f94a042fd9)
This simplifies the code a little: last_status is now read to go
(it's only used by the scriptstatus command at the moment).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 6be931266a4e41fd0253f760936ad9707dd97c47)
This needs to be done after the control-dispatcher:
In the TRANS2_COMMIT control, the client->db_id needs
to be set before bailing out, since otherwise the
next TRANS2_COMMIT_RETRY will fail...
Michael
(This used to be ctdb commit 59faf3f923a5989b5ee94ef02a12827412775bae)
To cope with timeouts when recoveries and transactions collide.
Maybe 100 is too high.
Michael
(This used to be ctdb commit c23d804165e84bdf95ba960c953c736d361011d7)
So that it is correctly handled by recoveries.
Also explicitly set the dmaster field to the current node's pnn.
Michael
(This used to be ctdb commit 03a5bb727b9db1ba952632f08ceb5355f0df842d)
The decision mechanism which records of a persistent db
are to be pulled into the recdb during recovery is now
as follows:
* Usually a record with the higher rsn than that already
stored is taken. (Just as for normal tdbs.)
* If a transaction is running on some node, then those
nodes copies of all records are taken and are not
overwritten later by other nodes' copies.
In order to keep track of whether a record's copy was obtained
from a node with a transaction running, the recovery mechanism
misuses the ctdb tdb header field 'lacount' in the recdb.
It is cleared later when pushing out the recdb database to the
other nodes.
This way, an incomplete transaction is not spoiled when
a recovery interrupts and the replay should usually succeed
(possibly after a few retries).
Michael
(This used to be ctdb commit 8aef46d2aab3efb322dda51eaa202653cefd5222)
It is important to keep track of the dmaster (i.e. the node that last committed
a transaction containing changes to this node).
Michael
(This used to be ctdb commit fe68972eb9cf3aa1f16ba1aacf57ade5d66e647c)
and further down to pull_remote_database(), pull_one_remote_database(),
and push_recdb_database().
This is in preparation of special handling of persistent databases
during recoveries.
Michael
(This used to be ctdb commit 90abc4ac7c16e854cf6e8f96b60a77bc92e35e07)
The githash can be specified through the environment variable "GITHASH"
that can contain a commit hash or a tag name, e.g.
The call syntax is now
[GITHASH=xyz] [USE_GITHASH=yes/no] [DEBIAN_MODE=yes/no] maketarball.sh
Michael
(This used to be ctdb commit 41aa9bdfa2934f564bdc14374362437dfad0045f)
It is unlikely we will need something this verbose for normal troubleshooting.
This allows us to keep a significantly longer time interval of log messages
in the 500k slots available in the ringbuffer.
(This used to be ctdb commit cc99c05c0c6484ad574039a454e6133852cb41fa)
in memory instead of dynamically allocated ones so that we reduce the pressure
on malloc/free.
(This used to be ctdb commit c5cbb95512f034abeec515579983bf7ac55eadd9)
Commit 50c2caed57c0 removed a gratuitous talloc_steal from the code in
ctdb_control_event_script_finished(), but not ctdb_event_script_timeout().
Easiest to call ctdb_control_event_script_finished() at the bottom of the
timeout routine.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 17fa252d0d6981fbae8083a818f26d5ce9c5102e)
This controls is only used by samba when samba wants to check if a subrecord held by a <node-id>:<smbd-pid> is still valid or if it can be reclaimed.
If the node is banned or stopped, we kill the smbd process and return that the process does not exist to the caller. This allows us to recover subrecords from stopped/banned nodes where smbd is hung waiting for the databases to thaw.
bz58185
(This used to be ctdb commit 157807af72ed4f7314afbc9c19756f9787b92c15)
Add the mapping to the list everytime we accept() a new client connection
and set it up to remove in the destructor when the client structure is freed.
(This used to be ctdb commit f75d379377f5d4abbff2576ddc5d58d91dc53bf4)
and store this in the client structure.
There is no need to rely on the hack that samba sends some special message
handle registrations that encodes the pid in the srvid any more.
This might not work on AIX since I recall some issues to get the pid in
this way on that platform.
(This used to be ctdb commit b4a7efa7e53e060a91dea0e8e57b116e2aeacebf)
Wolfgang saw a talloc complaint about using freed memory in ctdb_tcp_read_cb.
His fix was to remove the talloc_free() in that function, which causes
loops when a socket is closed (as it does not get removed from the event
system), eg:
netcat 192.168.1.2 4379 < /dev/null
The real bug is that when we have more than one pending packet in the
queue, we loop calling the callback without any safeguards should that
callback free the queue (as it tends to do on invalid packets). This
can be reproduced by sending more than one bogus packet at once:
# Length word at start: 4 == empty packet (assumed little endian)
/usr/bin/printf \\4\\0\\0\\0\\4\\0\\0\\0 > /tmp/pkt
netcat 192.168.1.2 4379 < /tmp/pkt
Using a destructor we can check if the callback frees us, and exit
immediately. Elsewhere, we return after the callback anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 4d0523dd94fb07e860b3e8118691f93d1ef8d0fa)
It is triggered by setting DEBIAN_MODE=yes in the environment.
This creates a tarball suitable for use in debian packages.
The differences from the standard tarball are these:
* The tar ball file is called ctdb_VERSION.orig.tar.gz
* The base directory in the tar ball is ctdb-VERSION.orig/
Michael
(This used to be ctdb commit 83e7c161efa93cd7acdfc803142b4fb3bfde7538)
The functions file no longer causes a side-effect by doing a shift.
It also doesn't set a convenience variable for $1.
All eventscripts now explicitly use "$1" in their case statement, as
does the initscript. The absence of a shift means that the
takeip/releaseip events now explicitly reference $2-$4 rather than
$1-$3.
New function ctdb_standard_event_handler handles the status and
setstatus events, and exits for either of those events. It is called
via a default case in each eventscript, replacing an explicit status
case where applicable.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit 3d55408cbbb3bb71670b80f3dad5639ea0be5b5b)
and until we have gone through a full re-recovery timeout without triggering
any pending recoveries before we start up the services and start monitoring
the node.
(This used to be ctdb commit 821333afb458358f90446062b0242790695e5060)
Apart from lots of cleanup work, this also fixes a bug where the share
checks didn't used to cope with directory names containing spaces.
The previous commit also loaded the config incorrectly.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit 3c93336ab92c2e4829ff4dc360045bfa6df21d50)
Now we're doing checking, we might as well make sure the commands from
"ctdb eventscripts" are valid.
This gets rid of the "UNKNOWN" event type.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 1d24a3869fe89fc9a109fd9e9b69df5fc665a5f6)
if the node is BANNED.
Dont even let them attach at all
to the database
Revert "temporarily try allowing clients to attach to databases even if
the node is banned/stopped or inactive in any other way."
This reverts commit 227fe99f105bdc3a4f1000f238cbe3adeb3f22f0.
(This used to be ctdb commit 10a3680fb3917ecafc824e73872eace321026172)
Now we're doing checking, we might as well make sure the commands from
"ctdb eventscripts" are valid.
This gets rid of the "UNKNOWN" event type.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 66b22980b14601f29fe8cc64bd8f29883c7ca1c0)
This is not as good as a compile-time check, but at least we count the
number of arguments are correct.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 83b7b233cb4707e826f6ba260bd630c8bc8f1e76)
This is not as good as a compile-time check, but at least we count the
number of arguments are correct.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit a6d353519932eee48f9241ad8887b692882906c9)
Finally, we remove the call name (eg. "monitor" or "start") from the
options field of the struct: it now contains only extra options.
This is clearer, and mainly involves adding some %s to debug statements.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 33fb0e7ba047ca73969b59bccf70a04a17c25a0a)
Finally, we remove the call name (eg. "monitor" or "start") from the
options field of the struct: it now contains only extra options.
This is clearer, and mainly involves adding some %s to debug statements.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit b0648c7f08eba87ec3c9714e2525c9b621bfb4ef)
This means we can get rid of more strcmp; they can simply use the
state->call value instead.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 6c79fa33e26cc4f0873577f8e122b1495b4c427e)
This means we can get rid of more strcmp; they can simply use the
state->call value instead.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 834c93b3e1b8f4151b8a2cd82c2dd8bacc17f66c)
Rather than doing strcmp everywhere, pass an explicit enum around. This
also subtly documents what options are available. The "options" arg
is now used for extra arguments only.
Unfortunately, gcc complains on empty format strings, so we make
ctdb_event_script() take no varargs, and add ctdb_event_script_args(). We
leave ctdb_event_script_callback() taking varargs, which means callers
have to do "%s", "".
For the moment, we have CTDB_EVENT_UNKNOWN for handling forced scripts
from the ctdb tool.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 8001488be4f2beb25e943fe01b2afc2e8779930d)
Rather than doing strcmp everywhere, pass an explicit enum around. This
also subtly documents what options are available. The "options" arg
is now used for extra arguments only.
Unfortunately, gcc complains on empty format strings, so we make
ctdb_event_script() take no varargs, and add ctdb_event_script_args(). We
leave ctdb_event_script_callback() taking varargs, which means callers
have to do "%s", "".
For the moment, we have CTDB_EVENT_UNKNOWN for handling forced scripts
from the ctdb tool.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 470822b329f9d3ca9bef518b56e9ce28d5fedda2)
Everyone uses the same timeout value, so just remove it from the API.
If we ever need variable timeouts, that might as well be central too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 533c3e053293941d2a9484b495e78d45f478bb08)
Everyone uses the same timeout value, so just remove it from the API.
If we ever need variable timeouts, that might as well be central too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit fe8027309c1f7b987cd368fa98f9b28741baa786)
ctdb_event_script_v doesn't take varargs. ctdb_run_event_script is
a better name, and fix comment.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 466beafadb37011fe273de8810ab0012e92a1fd8)
1) ctdb_event_script_v doesn't take varargs. ctdb_run_event_script is
a better name, and fix comment.
2) Fix indentation on allowed_scripts.
3) Comment on run_eventscripts_callback is wrong; it's the callback
for any ctdb forced event.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit e7d57d7ae678b24dab3364a348838c6a3398942c)
In 15bc66ae801b0c69, Ronnie fixed a double-free race. The problem was that
ctdb_run_eventscripts() hands a context to ctdb_event_script_callback() to
hang its data off, which gets freed in the callback. This particularly
hurt in ctdb_event_script_timeout.
There's nothing wrong with this, but obviously we should make the callback
call last of all. At the time, ctdb_event_script_timeout() carefully
extracted everything from the struct ctdb_event_script_state before
calling ->callback.
This was cleaned up in 64da4402c6ad485f (Ronnie again), and now state
was referred to after the callback again. But the same change introduced
a direct use-after-free bug which caused an occasional oops.
So in our last episode (eda052101728cf92) Volker fixed this, and Michael
committed it.
But we still have the double free bug which 15bc66ae801b0c69 was supposed
to fix! Let's try to fix this in a more permanent way, but always doing
the callback from the destructor. This means we need to hold the status,
and don't send the KILL signal if ->child is set to 0.
Finally, add a comment about freeing ourselves in run_eventscripts_callback
and the structure definition.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit b90bdb07c1f6913ddbf11bde9684bdc8af61c549)
In 15bc66ae801b0c69, Ronnie fixed a double-free race. The problem was that
ctdb_run_eventscripts() hands a context to ctdb_event_script_callback() to
hang its data off, which gets freed in the callback. This particularly
hurt in ctdb_event_script_timeout.
There's nothing wrong with this, but obviously we should make the callback
call last of all. At the time, ctdb_event_script_timeout() carefully
extracted everything from the struct ctdb_event_script_state before
calling ->callback.
This was cleaned up in 64da4402c6ad485f (Ronnie again), and now state
was referred to after the callback again. But the same change introduced
a direct use-after-free bug which caused an occasional oops.
So in our last episode (eda052101728cf92) Volker fixed this, and Michael
committed it.
But we still have the double free bug which 15bc66ae801b0c69 was supposed
to fix! Let's try to fix this in a more permanent way, but always doing
the callback from the destructor. This means we need to hold the status,
and don't send the KILL signal if ->child is set to 0.
Finally, add a comment about freeing ourselves in run_eventscripts_callback
and the structure definition.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 20b15de068d042b292725945927ceda1b01d07c0)
Write the whole int through the pipe, rather than quietly cutting it
off. Also, use -2 as the result if the read fails; -1 comes from many
paths if the child fails before running the script.
Add a comment about why we don't need to check the write.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 6804f880436645b52c09a78fa300377fa8058d0e)
Write the whole int through the pipe, rather than quietly cutting it
off. Also, use -2 as the result if the read fails; -1 comes from many
paths if the child fails before running the script.
Add a comment about why we don't need to check the write.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit c715746c2f40eb9b21dbf011d16f1f1b0b53fdf9)
Apart from lots of cleanup work, this also fixes a bug where the share
checks didn't used to cope with directory names containing spaces.
The previous commit also loaded the config incorrectly.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit 35a60a63a9b5c7d98dde514ae552239506b691c9)
The test depended on the exit code of "ctdb gettickles", which always
succeeds. This change wraps the command in a function that checks
whether the tickle we're interested in is registered.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit c4b05a731e1bee8f5b46529773a4f5389b2b6064)
command.
Use the existing context used for non-monitor events
Multiple concurrent uses of "ctdb eventscript ..." could otherwise lead to a SEGV
(This used to be ctdb commit 80a8d728e9680040e00d24361dfc9367dd372a56)
This is the first stage of an experimental change to eventscripts.
Ronnie and I did a few hours of factorisation of 40.vsftpd and applied
many of the changes to 41.httpd. Other eventscripts were also
modified.
At this stage this is completely untested.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit 364e70b763f0ccd7714d15723ad3ea4d7e2968a1)
This allows running the actual monitoring asynchronously from ctdbd
and only using "status" to pick up the actual results.
(This used to be ctdb commit 1908bac812650ca25151051f5d86815e0b8ed319)
The NFS test sleeps for MonitorInterval to give CTDB time to record an
NFS tickle. However, this isn't always long enough. This changes the
test to wait until a monitor event has actually occurred.
The CIFS test assumes that Samba is able to register a tickle with
CTDB before it notices that netstat has registered the tickle and can
use onnode to ask CTDB about it. That is an incorrect assumption -
sometimes we can get to the point of asking CTDB about the tickle
before Samba and CTDB have processed it. This adds a timeout loop
that makes the CIFS test wait until the tickle has been registered or
fail after 10 seconds.
Signed-off-by: Martin Schwenke <martin@meltin.net>
(This used to be ctdb commit 20a9d35933d89dc7eb710075f360686a49d78609)
use killtcp and kill both directions of the nfs connections.
we used to kill only one direction since the other direction was unkillble
but recent kernels allow us to kill both
(This used to be ctdb commit 8001ae580bcc28d45f6026b529d7ffc247cbba34)
dont allow UNHEALTHY nodes to become natgw master, unless all nodes
are unhealthy
(This used to be ctdb commit e8e7129ff1371065fbd75e1aea844d6d04a96fa9)
This just sleeps for twice the value of EventScriptTimeout
in the monitor action. It is not run by default, but
can be activated by setting CTDB_RUN_TIMEOUT_MONITOR
in /etc/sysconfig/ctdb .
Michael
(This used to be ctdb commit 1a3ecdee85b82bb3234a92ae6bcdeb92238eb7ee)
It's much nicer for post-mortem debugging to have a body to examine.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(This used to be ctdb commit 058e21d96c3c02759833fd5ddfe7b43e6a5f5740)
this to handle the case where all links do have a physical layer, but where all slaves have been disabled using ifdown
(This used to be ctdb commit bf50709630df000583f2b0ef0edc177c01d60eaf)
setting USE_GITHASH=no in the environment makes
makerpms.sh omit the git hash
Michael
(This used to be ctdb commit 209ff041596e39688186c99995863ed3e816b8e4)
The vacuum process treats persistent databases the same as
non-persistent and thus ignores the extra state for transactions.
This way, it breaks the api-level transactions.
Michael
(This used to be ctdb commit f98fefbc566eefbfcc660646af6e25256ab82b13)
This reverts commit 4e9a3a5dc232bac12ab387ea0cf4f1b279bed5c1.
Transaction commit should not be allowed to fail.
This is a real error.
Michael
(This used to be ctdb commit 825c506da76d7afd0714b75b8c8727874183a618)
The gap that remained is between checking whether a transaction commit
is in progress and taking the lock. Now we first take the lock and then
check whether a transaction commit is in progress. If so, we release the
lock, wait for one second and retry.
Michael
(This used to be ctdb commit b95524c08bf12914120cb6c818ecc1c99738fe37)
We should really leave it up to the administrator to decide
whether ctdb should be started automatically at boot-time.
Michael
(This used to be ctdb commit c1d8496f9fd5e8046f3d990264258dfb054f3b32)
use a udp socket on the ctdbd port to send messages to teh syslog child process for loggign.
we need this when syslog becomes "slow", like very slow, and on boxes where syslog is limited to 100 lines per second and starts to block after that
(This used to be ctdb commit 1446f4c247310e2ff2d522055bd8927d1a78d017)
