samba.git/ctdb/server, branch master

ctdb-daemon: Use statically allocated arrays for helper paths

2015-03-10T14:29:06+00:00

The use of talloc with a static variable is somewhat confusing.
Statically allocate an array and use ctdb_set_helper() instead.

Signed-off-by: Martin Schwenke 
Reviewed-by: Volker Lendecke

ctdb-locking: Back-off from logging every 10 seconds

2015-03-05T11:06:44+00:00

If ctdb_lock_helper cannot get a lock within 10 seconds, ctdb daemon
logs a message and invokes an external debug script.  This is repeated
every 10 seconds.

In case of a contention or on a loaded system, there can be multiple
ctdb_lock_helper processes waiting to get lock on record(s).  For each
lock request taking longer, ctdb daemon will flood the log every
10 seconds.  Instead of logging aggressively every 10 seconds, relax
logging to every 100s and 1000s if the elapsed time has exceeded 100s
and 1000s respectively.

Signed-off-by: Amitay Isaacs 
Reviewed-by: Michael Adam 

Autobuild-User(master): Michael Adam 
Autobuild-Date(master): Thu Mar  5 12:06:44 CET 2015 on sn-devel-104

ctdb-client: Return a value of 1 when setting obsolete tunable variable

2015-02-18T04:34:06+00:00

Signed-off-by: Martin Schwenke 
Reviewed-by: Amitay Isaacs

ctdb-recoverd: Abort when daemon can take recovery lock during recovery

2015-02-13T08:48:15+00:00

Signed-off-by: Martin Schwenke 
Reviewed-by: Amitay Isaacs 

Autobuild-User(master): Amitay Isaacs 
Autobuild-Date(master): Fri Feb 13 09:48:15 CET 2015 on sn-devel-104

ctdb-recoverd: Improve error messages on recovery lock coherence fail

2015-02-13T06:19:07+00:00

When the daemon is able to take the recovery lock during recovery we
might as well guess that the cluster filesystem has a lock coherence
problem and print a more useful message.  This will be more helpful to
those trying out cluster filesystems that don't have lock coherence or
that are difficult to setup.

Signed-off-by: Martin Schwenke 
Reviewed-by: Amitay Isaacs

ctdb-recoverd: Don't release and re-take the recovery lock

2015-02-13T06:19:07+00:00

Just continue to hold it, otherwise a broken node might win an
election and grab the lock.

Signed-off-by: Martin Schwenke 
Reviewed-by: Amitay Isaacs

ctdb-recoverd: Simplify ctdb_recovery_lock()

2015-02-13T06:19:07+00:00

Have it just silently take or fail to take the lock, except on an
unexpected failure (where it should log an error).

This means that when it is called we need to keep the old behaviour
and explicitly release the lock.  In do_recovery() the lock is
released and a message is printed before attempting to take the lock.
In the daemon sanity check the lock must be released in the error path
if it is actually taken.

Signed-off-by: Martin Schwenke 
Reviewed-by: Amitay Isaacs

ctdb-recoverd: Remove check_recovery_lock()

2015-02-13T06:19:07+00:00

This has not done anything useful since commit
b9d8bb23af8abefb2d967e9b4e9d6e60c4a3b520.  Instead, just check that
the lock is held.

Signed-off-by: Martin Schwenke 
Reviewed-by: Amitay Isaacs

ctdb-recoverd: Improve logging when recovery lock file is changed

2015-02-13T06:19:07+00:00

Signed-off-by: Martin Schwenke 
Reviewed-by: Amitay Isaacs

ctdb-recoverd: New function ctdb_recovery_unlock()

2015-02-13T06:19:07+00:00

Unlock the recovery lock file.  This way knowledge of the file
descriptor isn't sprinkled throughout the code.

Signed-off-by: Martin Schwenke 
Reviewed-by: Amitay Isaacs