new version 1.0.112-42

CTDB_FATAL() try to drop all ip addresses when shutting down through ctdb_fatal()

If we shutdown through a ctdb_fatal(), unless there is an external mechanism to trap this and restart ctdb, we will get a duplicate address problem since addresses held on the node remain which collides with the addresses when failed over to other nodes.

During ctdb_fatal(), spawn a child process to try to drop all held public addresses.

VACUUMING lmaster check is wrong when nodes are disconnected from the cluster

During vacuuming we incorrectly used the size of the VNN map as the range of possible/allowed lmaster values.
This is incorrect if for example one or more of the nodes in the cluster are permanently disconnected and taken out of service.
When this happens, there will be a slow and steady buildup of un-vacuumable records which belong to the last n nodes in the cluster.
Un vacuumnable since the vnn map is smaller than the niumber of nodes and any records belonging to a node with pnn id higher than the size of the vnn map size would always be ignored.

Eventually the cluster would be full of un-vacuumable dead records which would lead to ctdb outages.

Fix the vacuuming logic to use ctdb->num_nodes as the possible range for lmaster values. Fix the other references in the vacuuming to keep ctdb->num_nodes lists of records and not vnnmap->size.

To reproduce, start a 3 node cluster and shutdown node #1 so only node #0 and node #2 are running.
To not have to create unrealistically large number of records, we need to tweak the tunables for vacuuming so vacuuming also triggers for small number of rectords :
onnode all ctdb setvar VacuumLimit 10; onnode all ctdb setvar RepackLimit 10

Use smbtorture to create a large number of dead records in sessionid.tdb :
smbtorture //127.0.0.1/data -U<user>%<password> --num-ops=3000 BASE-BENCH-HOLDCON

Without the patch, many/most records would eventually be vacuumed, but the database would never become completely empty, there would always be a number of records that would hash to node#2 which would never be removed.

With this patch, all records will eventually become vacuumed and the database would become empty.

alternatively, by starting node#1,  the database would also become empty.

The command 'tdbdump /var/ctdb/sessionid.tdb.* | grep data\(24\) | wc -l'
can be used to count how many dead records exist in the database.

CQ S1022203

New version 1.0.112-41

Restart recovery dameon if it looks like it hung.
Dont shutdown ctdbd completely, that only makes the problem worse.

Suppress a log message properly

new version 1.0.112-40

dont log an error if we waitpid but there is no child process to wait for

If/when the recovery daemon terminates unexpectedly, try to restart it again from the main daemon instead of just shutting down the main deamon too.

While it does not address the reason for recovery daemon shutting down, it reduces the impact of such issues and makes the system more robust.

re-sync to 1.0.112-39 srpm

When we are no longer the natgw master, dont put the natgw ip on loopback.
We put the ip on loopback just to make sure we would still interoperate with
non-standard configurations on unix-KDC, that are configured to verify the optional
HostAddresses field.
This is not required for AD, since AD does not use this field, and is replaced in
unix land with other/better mechanisms than this "dodgy" check.

This makes it "easier" for applications that have bound to the natgw address
to detect a socket problem and try to reconnect/recover if the ip address
is completely missing from the system.

At the same time, use the winbind specific hook that exists to explicitely tell winbindd : this address is gone, so if you have bound to it, this is a good time to close and rebind your socket.

cq 1020333

new version -1.0.112-38

Try to restart LOCKD if "service nfslock start" fails.

Some systems this command occasionally returns [OK] == success
but lock manager fails to start.

Dodgy service scripts.

CQ1020366

new version 1.0.112-37

Unconditionally create the state directory in case it has been changed at runtime

CQS1019937

New version 1.0.112-36

Updates to ctdb_diagnostics

Add some command-line options to ctdb_diagnostics.

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>

New version 1.0.112-35

* Fri Oct 1 2010 : Version 1.0.112-35
 - Fix futex hang during eventscript timeout
 - Fix a crash when printing a log message during shutdown

When memory allocations for recovery fails,
dont dereference a null pointer while trying to print the log message for the failure.

also shutdown ctdb with ctdb_fatal()

eventscript: make sure we die when we timeout.

Volker noticed that system() can hang on a futex: we do this inside a
signal handler simply to dump extra diagnostics when we timeout, which is
very questionable but usually works.

Add a timeout of 90 seconds: after that, commit suicide.
(This is a workaround for this branch: master does this correctly).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

new version 1.0.112-34

Revert "add some extra debugging statements to the client side code sending controls"

This reverts commit 1d1d475d7e18620330aaee95038c40b27e5496d4.

On RHEL,    "service nfs stop;service nfs start"  and "service nfs restart"
    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

add some extra debugging statements to the client side code sending controls
and failing. in particular the GETRECMASTER control

New version 1.0.112-33

Add a new event :ipreallocated"
This is called everytime a reallocation is performed.

While STARTRECOVERY/RECOVERED events are only called when
we do ipreallocation as part of a full database/cluster recovery,
this new event can be used to trigger on when we just do a light
failover due to a node becomming unhealthy.

I.e. situations where we do a failover but we do not perform a full
cluster recovery.

Use this to trigger for natgw so we select a new natgw master node
when failover happens and not just when cluster rebuilds happen.

new version 1.0.112-32

 Tue Aug 10 2010 : Version 1.0.112-32
 - Dont check if natgw is enabled or not in the natgw script
 - disable the check if winbind is ok
 - optimize 61.nfstickles
 - fix a fd leak from the abort-vacuuming patch

skip the check if NATGW is enabled.

many users use natgw incorrectly with invalid configurations.
It is easier to skip this check here

disable the check that winbind works or not for now

Optimise 61.nfstickle to write the tickles more efficiently.

Currently the file for each IP address is reopened to append the
details of each source socket.

This optimisation puts all the logic into awk, including the matching
of output lines from netstat.  The source sockets for each for each
destination IP are written into an array entry and then each array
entry is written to the corresponding file in a single operation.

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

Revert "For deterministic IPs, check if the designated node can host the ip before"

This reverts commit 5e60aad0e19cabb29c3be191698e10049da151c7.

This change lowers the "flapping" but at the expense of less balance.
Keeping the system balancved is likely better than minimizing the amount of flapping
for this configuration

vacuum: close fd leak

Commit 517f05e42f17766b1e8db8f1f4789cbad968e304 "freeze: abort vacuuming
when we're going to freeze." introduced a file descriptor leak, because
the abortfd used to talk to the child wasn't closed.

Do this in the destructor.

CQ:S1019190
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

New version 1.0.112-31

 - Retry the vacuum abort code.
 - Add codestyle doc
 - When rebalancing ip addresses, increase number of iterations from 5
 - When using deterministic ips, dont force ips without home address
   to move back.

For deterministic IPs, check if the designated node can host the ip before
we try to reassign it back to the home node.

If it can not, of if it is unknown, just leave the ip where it is.

This reduces the amount of "flapping" an ip address with no home node
does during recoveries.

When trying to re-balance the ip assignment and shuffle ips from
nodes with many addresses to nodes with few addresses,
loop up to num_ips+5 times instead of only 5 times.

When we have very many public ips per node, we might need to loop more than
5 times or else we will exit without reaching optimal balance.

Add a code-style document.

Shamelessly sto^H^H^Hborrowed from samba3.

add back the vacuum crash bug in the childprocess
that got lost in the "new release" commit.

New version : 1.0.112-30

Merge commit 'rusty/1.0.112' into 1.0.112

vacuum: fix crash on vacuum abort

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>

New version 1.0.112-29

 - Fix for a SEGV that can happen when tcp tickles fail/timeout
   CQ:S1019041

takeover: prevent crash by avoiding free in traverse on RST timeout

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>

New version 1.0.112-28

Revert "Make deterministic ips off by the default."

This reverts commit 09d5dc94930a1349bb74b5557a4e71144ad525a4.

We decided more review is needed, and we should not change this
for 1.0.112.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

New version 1.0.112-27

Make deterministic ips off by the default.

The git log makes it clear that it's mainly useful for debugging; we
should turn it off in production to minimize IP address movement.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

freeze: abort vacuuming when we're going to freeze.

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.

CQ:S1018154 & S1018349
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

vacuum: disabling vacuuming during a freeze

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>

logging: give a unique logging name to each forked child.

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>

New version 1.0.112-26

config: wrap iptables in flock to avoid concurrancy.

When doing a releaseip event, we do them in parallel for all the separate
IPs.  This creates a problem for iptables, which isn't reentrant, giving
the strange message:
iptables encountered unknown error "18446744073709551615" while initializing table "filter"

The worst possible symptom of this is that releaseip won't remove the rule
which prevents us listening to clients during releaseip, and the node will be
healthy but non-responsive.

The simple workaround is to flock-wrap iptables.  Better would be to rework
the code so we didn't need to use iptables in these paths.

CQ:S1018353
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

New version 1.0.112-25
* Tue Jul 6 2010 : Version 1.0.112-25
 - natgw firewall fix
   BZ62613

Move NAT gateway firewall rules to recovered|updatenatgw events.

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>

New version 1.0.112-24

* Mon Jul 5 2010 : Version 1.0.112-24
 - Extra logging on tdb_chainunlock failures.
 - Extra sanity check in ctdb_become_dmaster
   BZ65158
 - More robustness against IDR wrap
   BZ65158
 - Recovery failure under stress fix
   BZ:65158

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

ctdb_freeze: extend db priority hack to cover serverid.tdb deadlock.

We discovered that recent smbd locks the serverid tdb while
holding a lock on another tdb (locking.tdb):
  7: POSIX  ADVISORY  WRITE smbd-2224318 locking.tdb.0 10600 10600
  22: -> POSIX  ADVISORY  READ  smbd-2224318 serverid.tdb.0 26580 26580

The result is a deadlock against the ctdb_freeze code called for
recovery.  We extend the "notify" workaround to this case, too.

BZ:65158
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Wrap the IDR early, but not too early.

We dont want it to wrap almost immediately so that basically all "ctdb ..."
commands log the "Reqid wrap" warning.

Delay reusing ids to make protocol more robust

Ronnie and I tracked down a bug which seems to be caused by a node
running so slowly that we timed out the request and reused the request
id before it responded.

The result was that we unlocked the wrong record, leading to the
following:

ctdbd: tdb_unlock: count is 0
ctdbd: tdb_chainunlock failed
smbd[1630912]: [2010/06/08 15:32:28.251716,  0] lib/util_sock.c:1491(get_peer_addr_internal)
ctdbd: Could not find idr:43
ctdbd: server/ctdb_call.c:492 reqid 43 not found

This exact problem is now detected, but in general we want to delay
id reuse as long as possible to make our system more robust.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

idtree: fix handling of large ids (eg INT_MAX)

Since idtree assigns sequentially, it rarely reaches high numbers.
But such numbers can be forced with idr_get_new_above(), and that
reveals two bugs:
1) Crash in sub_remove() caused by pa array being too short.
2) Shift by more than 32 in _idr_find(), which is undefined, causing
   the "outside the current tree" optimization to misfire and return NULL.

Signed-off-by: Rusty Russell <rusty@rustorp.com.au>

fix a debug message

idr can timeout and wrap/be reused quite quickly.

If a noremote node hangs for an extended period, it is possible
that we might have a DMASTER request in flight for record A to that node.
Eventually we will reuse the idr, and may reuse it for a DMASTER request to a different node for a different record B.

If while the request for B is in flight,  the first tnode un-hangs and responds back
we would receive a dmaster reply for the wrong record.

This would cause a record to become perpetually locked, since inside the daemon we would tdb_chainlock(dmaster_reply->pdu->key)   but once the migration would complete we would chainunlock   idr->state->call->key

Adding code to verify that when we receive a dmaster reply packet that it does in fact match the exact same key that the state variable we have for the idr in flight.

We can not be holding a chainlock at this stage, so the tdb_chainunlock() call is bogus

( a child process might be holding the lock, but not the main daemon)

add extra logging for failed ctdb_ltdb_unlock() for a few more places
it is called from

add additional logging when tdb_chainunlock() fails
so we can see where it was called from when it fails

print the db name qwhen a chainunlock fails too

when tdb_chainunlock() fails, print the tdb error that occured

New version 1.0.112-23

* Tue Jun 8 2010 : Version 1.0.112-23
 - Fix a SEGV that can be triggered by "ctdb delip"
   BZ 62783
 - Add iptables filters to stop clients from connecting to the NATGW
   address.
   BZ62613
 - Add timestamps to the ctdb statistics output
 - Change "ctdb addip" to block until the address is active
   BZ63191
 - Add additional log messages when tdbs can no longer be locked/chain
   unlocked
   BZ64688

Additional log messages when tdb databases can no longer be chainlocked or chainunlocked

BZ64688

change the addip command to wait until the ip address is taken by the proper node

BZ63191

When we say "current time of statistics" in the "ctdb statistics" output,
print the current time and not the start time

Add a variable for start/current time to ctdb statistics
and print the time startistics was taken and for how long the statistics have been collected to the "ctdb statistics" output.

Prevent clients from connecting to the natgw address.
    This address is dedicated for outgoing connections.

    BZ62613

From rusty
Fix a SEGV that could happend when deleting a public ip.

BZ62783

new version 1.0.112-22

+* Mon May 24 2010 : Version 1.0.112-22
+ - Fix bug in 62.cnfs to allow exports that are quoted.
+ - Add monitoring og Quorum for the 62.cnfs script
+ - Allow restoredb to restore a backup to to a different database

Enhance the "ctdb restoredb" command so you can restore a backup into a different database.

Add monitoring of quorum and make the node UNHEALTHY when quarum is lost

in 62.cnfs, lines in /etc/exports can have hte exports quoted,
so strip off any initial " on the exports line

New version 1.0.112-21

* Fri May 21 2010 : Version 1.0.112-21
 - Fix a bug where we would fail to remove the natgw configuration
   and would leave a ip address for natgw still remaining on loopback.
   BZ 58317
 - In the ctdb command line tool, we do not wait long enough for the ipreallocate
   command to finish on the recovery daemon. which sometimes would timeout if the
   recovery daemon was busy, or we had rolling recoveries.
   BZ 61783
 - During failed recoveries we could get in a state where recovery attempts stopped
   while database priority level 2 or 3 remain frozen.
   BZ 63951

It was possible for ->recovery_mode to get out of sync with the new three db priorities in such a way that
->recovery_mode was set to normal   but database priorities leven2 or 3 was still set to frozen.

causing the recovery daemon to fail to detect that a recovery was needed to recover access to the database.

BZ63951

In control_ipreallocate() we wait at most 5 tries before aborting the command
and returning an error.
This might not be sufficient if there are several recoveries in a row.

Instead loop as long as it takes for the recovery master to finish the recoveries and re
spond to the ipreallocate call.

Increase the log level of the error message when the recovery master was busy and could
not perform the ipreallocation promptly

BZ61783

Fix a bug where we failed to remove the natgw address from loopback properly
bz58317

New version 1.0.112-20

+* Tue May 11 2010 : Version 1.0.112-20
+ - Add number of recoveries done to the ctdb statistics output.
+ - Use the fuill range for IDR values.
+   BZ 60540
+ - When performing a recovery, make sure all nodes agree with recmaster
+   on the reclock file.
+   BZ 62748
+ - Lower the loglevel for some debug messages
+   BZ 63074

Add the number of performed recoveries to the "ctdb statistics" output.

ctdb: use full range of IDR

This resolves a problem with huge numbers of requests which could overflow
16 bits.  Fortunately, the IDR should scale reasonably well, so we can simply
hold all the requests.

Although noone checks for failure, I added a constant for that.

BZ: 60540
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

When we perform a recovery. Make sure that the recmaster will sync the reclock file across the cluster.

This prevents issues such as when the recovery master is configured to NOT use a reclock file but other nodes are configured to use one.

BZ 62748

Lower the debug level for the messages when a client registers/deregisters a server id

BZ63074

New version 1.0.112-19

This version adds a new eventscript 62.cnfs that
allows better integration with GPFS.

BZ 61913

New version 1.0.112

+* Mon May 3 2010 : Version 1.0.112-18
+ - Make the NATGW eventscript check for when the system is misconfigured
+   to use the same address for both natgw as well as a public address
+   and warn.  BZ60933
+ - A recent change to monitor the ip address assignment broke "ctdb moveip".
+   Fix ctdb moveip so it works again. BZ62782

Dont check ip assignment across the cluster while ip-verification
checks are disabled

The recent change to the recovery daemon to keep track of and
verify that all nodes agree on the most recent ip address assignments
broke "ctdb moveip ..." since that call would never trigger
a full takeover run and thus would immediately trigger an inconsistency.

Add a new message to the recovery daemon where we can tell the recovery daemon to update its assignments.

BZ62782

Make create_merged_ip_list() a static function since
it is not called from outside of ctdb_takeover.c

In the log message when we have found an inconsistent ip address allocation,
add extra log information about what the inconsistency is.

If the admin makes a configuration mistake and configures NATGW to use the
same ip address as a normal public-address,
check for this in the natgw script and warn the user.

Also prevent ctdb from starting up since this configuration will not work.

BZ60933

New version 1.0.112-17

* Fri Apr 23 2010 : Version 1.0.112-17
 - In ctdb-crash-cleanup.sh  also check for and remove the NATGW address
   if set.
 - Add monitoring and warning of low memory condition
   CTDB_MONITOR_FREE_MEMORY_WARN

Add a setting where CTDB will monitor and warn for low memory conditions.

    CTDB_MONITOR_FREE_MEMORY_WARN

BZ 59747

In the example script to remove all ip addresses after a ctdb crash,
add the NATGW address as one to be removed in addition to the
public addresses.

New version 1.0.112-16

add an example script that can be called from crontab to cleanup
and release public ip addresses if ctdbd is no longer running

add a missing ||
to make the 10.interface script not fail with a syntax error

New version 1.0.112-15

* Wed Apr 21 2010 : Version 1.0.112-15
 - Change how we add/remove iptable rules during recovery to make
   rules leaks less likey.
 - change a debug message loglevel from ERR to NOTICE
   BZ62086
 - In the recovery daemon, track pulbic ip assignment
   across the cluster and verify consistency.
 - From Martins: change the 10.interface script to handle
   virtio interfaces correctly for virtual clusters.
 - Make the recovery master verify the reclock setting across the cluster
   and ban nodes with inconsistencies.
   BZ56354

Let the recovery master verify the reclock setting on all nodes in the cluster.

Any node that is found to use a different filename from the first node
will be banned.

Nodes that have no reclock file at all configured are ignored in this check.

BZ56354