doc: Fix documentation for setup event

Signed-off-by: Amitay Isaacs <amitay@gmail.com>

(This used to be ctdb commit 36d25e96a2f8ae1461c5a708a2922f0475a39900)
doc: Add info about execute permissions on event scripts

Signed-off-by: Amitay Isaacs <amitay@gmail.com>

(This used to be ctdb commit 25d886060b138bc5e78fe93d7bebe3990264f29d)
config/functions: fix a comment

ctdb_check_counter_limits does not fail but succeed if count >= limit

Signed-off-by: Michael Adam <obnox@samba.org>

(This used to be ctdb commit af540ef728303b4a0a188b17c695e9aefab34489)
common: Debug ctdb_addr_to_str() using new function ctdb_external_trace()

We've seen this function report "Unknown family, 0" and then CTDB
disappeared without a trace.  If we can reproduce it then this might
help us to debug it.

The idea is that you do something like the following in /etc/sysconfig/ctdb:

  export CTDB_EXTERNAL_TRACE="/etc/ctdb/config/gcore_trace.sh"

When we hit this error than we call out to gcore to get a core file so
we can do forensics.  This might block CTDB for a few seconds.

Signed-off-by: Martin Schwenke <martin@meltin.net>

(This used to be ctdb commit 7895bc003f087ab2f3181df3c464386f59bfcc39)
Logging: Map TEVENT_DEBUG_FATAL to DEBUG_CRIT

This is currently mapped to DEBUG_EMERG.  CTDB really has no business
logging anything at EMERG level since the whole system is not about to
abort or catch fire.  EMERG causes the message to appear on the
console and on every terminal.  That's a bit overzealous!

There would be very few situations where logs are being filtered at
level below ERROR, so CRIT should certainly suffice.

The trigger for this was curious messages saying "No event for <n>
seconds!" logged in a user's terminal.

Pair-programmed-with: Amitay Isaacs <amitay@gmail.com>
Signed-off-by: Martin Schwenke <martin@meltin.net>

(This used to be ctdb commit 0e56e2dad1861892aa8ba59494ad244f2498314e)
Eventscripts: "recovered" event should not fail on NATGW failure

The recovery process has no protection against the "recovered" event
failing, so this can cause a recovery loop.

Instead of failing the "recovered" event, add a "monitor" event and
fail that instead.  In this case the failure semantics are well
defined.

A separate patch should ban nodes if the "recovered" event fails for
an unknown reason.

Signed-off-by: Martin Schwenke <martin@meltin.net>

(This used to be ctdb commit eaa7c165f58abd7e259c37d76b7dd37c91e13d9f)
Revert "Eventscripts - add facility to 10.interface to delete unmanaged IPs"

This reverts commit 88f88d86b0d08240f749fb721b8c401c2eeb1099.

This is dangerous and, on reflection, I can't see it being useful.
There are often permanent IPs on interfaces that CTDB shares with its
public IPs.

(This used to be ctdb commit 16aba4eb620844626a1c71c58b51658caf44dea6)
recoverd: Verifying local IPs should only check for unhosted available IPs

Currently it checks for unhosted IPs among the known IPs rather than
available IPs.  This means that a takeover run can be flagged even
when that takeover run will be unable to assign a known, unhosted IP.

Pair-programmed-with: Amitay Isaacs <amitay@gmail.com>
Signed-off-by: Martin Schwenke <martin@meltin.net>

(This used to be ctdb commit 3cc878bc97fdac764a60ed805f64d649eaab06e8)
tools/ctdb: Remove extra header from natgwlist -Y output

Signed-off-by: Martin Schwenke <martin@meltin.net>

(This used to be ctdb commit 59520c9785d113ad5063eb5fbe42a9efc7e30076)
recoverd: Clarify some misleading log messages

Signed-off-by: Martin Schwenke <martin@meltin.net>

(This used to be ctdb commit 14589bf7c16ba017fe00d4e8bea8cc501546c60f)
ctdbd: Remove references to forcing running of eventscripts from log messages

Running of eventscripts can be initiated from many places, including
the recovery daemon.

Signed-off-by: Martin Schwenke <martin@meltin.net>

(This used to be ctdb commit 440892d75ef73c0aca22f47c0c01712be00cf5b7)
initscript: Check that rc.ctdb is executable before running it

Signed-off-by: Martin Schwenke <martin@meltin.net>

(This used to be ctdb commit 59a47c0674bacfebc17a1b44f0244727bf2fa7a4)
tools/ctdb_diagnostics: Add "ctdb listvars" output

Signed-off-by: Martin Schwenke <martin@meltin.net>

(This used to be ctdb commit 2d75a04ba9a2e87a0dcb9bf778c58e335af1871c)
scripts: Refactor logging code in initscript and functions file

Signed-off-by: Martin Schwenke <martin@meltin.net>

(This used to be ctdb commit 5ee242c949a98bb7397e0f7368b20d44c06fe772)
header: Added DB statistics update macros

Signed-off-by: Amitay Isaacs <amitay@gmail.com>

(This used to be ctdb commit a0cdfae7438092f5c605f0608daa536be860b7fe)
common: Add routines to get process and lock information

Currently these functions are implemented only for Linux.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>

(This used to be ctdb commit be4051326b0c6a0fd301561af10fd15a0e90023b)
ctdbd: locking: Provide non-blocking API for locking of TDB record/db/alldb

This introduces a consistent API for handling locks on single record, complete
db or all dbs. The locks are taken out in a child process. In cases of timeout,
find the processes that currently hold the lock and log.

Callback functions for locking requests take locked boolean to indicate
whether the lock was successfully obtained or not.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>

(This used to be ctdb commit 1af99cf0de9919dd89af1feab6d1bd18b95d82ff)
tools/ctdb: Display the locking statistics

Signed-off-by: Amitay Isaacs <amitay@gmail.com>

(This used to be ctdb commit e24b5bf283736624b387b0364d7200212bb3054b)
tests: Fix statistics test for new output lines from locking API

Signed-off-by: Amitay Isaacs <amitay@gmail.com>

(This used to be ctdb commit 1ee55c511b99e9f8a6fa4e34207267e953f09bae)
ctdbd_test: Include ctdb_lock.c code for test stubs

Signed-off-by: Amitay Isaacs <amitay@gmail.com>

(This used to be ctdb commit caff197edf6f928494028ac6c993901954aaa36f)