New version 1.0.114.7

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

doc: The second half of monitoring is only for recovery master

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit fcd5e1f04c5fe6c98399429b8f0918b8779acba6)

recoverd: when the recmaster is banned, use that information when forcing an election

When we trigger an election because the recmaster considers itself inactive,
update our local nodemap with the recmaster's flags before calling
force_election(). This way, we don't send the inactive node freeze commands
(e.g.) that may fail and then lead to ourselves getting banned.

The theory is that this should help avoiding banning loops.

Signed-off-by: Michael Adam <obnox@samba.org>
(cherry picked from commit 932360992b08a5483d90c0590218ba0fd756119e)

recoverd: fix a comment typo

Signed-off-by: Michael Adam <obnox@samba.org>
(cherry picked from commit 741944f118e98f178b860194eecb215180949d18)

recoverd: fix a comment in main_loop

Signed-off-by: Michael Adam <obnox@samba.org>
(cherry picked from commit ac06c46e4a80c635f6094b5ac6f0bf3e3a02db95)

recoverd: eliminate some trailing spaces from ctdb_election_win()

Signed-off-by: Michael Adam <obnox@samba.org>
(cherry picked from commit df30c0a05ed908fc2a997c56ff5484736b23b70f)

recoverd: Don't continue if the current node gets banned

Can not continue with recovery or monitoring cluster.

Signed-off-by: Martin Schwenke <martin@meltin.net>
Pair-programmed-with: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 14399de1dd0bd8dabf1f48b1457e3ccb37589d8a)

recoverd: Refactor code to ban misbehaving nodes

Since we have nodemap information, there is no need to hardcode the
limit of 20.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Pair-Programmed-With: Martin Schwenke <martin@meltin.net>
(cherry picked from commit aea12dce83ef385e9fb3bc03ac7ace0874a0e3fe)

Conflicts:

server/ctdb_recoverd.c

recoverd: Move code to ban other nodes after we get local node flags

If a node gets banned first, then it should not ban other nodes.

This code was moved up in main_loop to avoid waiting for nodemap
from other nodes (commit 83b0261f2cb453195b86f547d360400103a8b795).

To prevent a banned node from banning other nodes, we need to first get
nodemap information from local node, so trying to ban other nodes can
fail if we are already banned.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit ae1693905036ecdbc4594fde1f12500faae4a554)

recoverd: Delay the initial election if node is started in stopped state

Since there is an early exit if a node is stopped or banned, we can wait till
the node becomes active to start initial election.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 593a17678fbd3109e118154b034d43b852659518)

recoverd: Update capabilities only if the current node is active

Since we do an early return if a node is stopped or banned, move update
capabilities code below the early return and just before we check the
capabilities of current recovery master.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 93bcb6617e1024f810533e12390a572f51703ca0)

recoverd: No need to check if node is recovery master when inactive

If a node is stopped or banned, it will cause early return from the
main_loop, so this check is redundent.  The election will called by an
active node.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 815ddd3341b7e9db39e05a3a3fcd9a1420f053bc)

recoverd: Always do an early exit from main_loop if node is stopped or banned

A stopped or banned node cannot do anything useful.  So do not participate
in any cluster activity and do not cause any unnecessary network traffic.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 2396981c4bcf30530aeb7f4395093cc202105b50)

recoverd: main_loop() should not verify local IPs if node is stopped

Doing these checks is pointless and potentially causes unnecessary log
messages.

Signed-off-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit a0c30c820fd47d4f8620dc060c825be10754f5d1)
(cherry picked from commit d181a5dadffacc5bfe04dcab6595b03499e613ad)

recoverd: Do not set banning credits on a node if current node is inactive

If the current node is banned or stopped, then it should not assign banning
credits to other nodes since the current node will not have up-to-date flags
of other nodes.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 38304f88e0c634e97d4687c25adef975f71537b8)

banning: Do not come out of ban if databases are not frozen

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit a60f228f8380f222f838eb619d2ab55f96f11ac2)

banning: No need to check if banned pnn is for local node

If the banned pnn is not the local node, the function returns early.
So no need for additional check.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 297d93cecc3c0655e72ecac38508e113bdbeab9c)

banning: Make ctdb_local_node_got_banned() a void function

When this function is called, we are already committed to banning
and there is no point in failing this function.  In case, freezing of
databases fails, it will be fixed from recovery daemon.
(cherry picked from commit bb178338658b4ae32382a1f62f7c21cee1d4878f)

recoverd: Also check if current node is in recovery when it is banned

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 6a9dbb8fb0f1f6e8c206189cdc2d33bb371ea2a8)

recoverd: Set node_flags information as soon as we get nodemap

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 8d622660a14c929e365d306147b378ea6ab92175)

recovered: Remove old comment as the code corresponding to that has gone away

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 34af2cdf686d5d77854cbaa7bbcd8f878e9171c7)

banning: Log ban state changes for other nodes at higher debug level

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit c6f8407648abb37f2ed781afa5171dad8c9f59e9)

freeze: Make ctdb_start_freeze() a void function

If this function fails due to memory errors, there is no way to recover.
The best course of action is to abort.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 46efe7a886f8c4c56f19536adc98a73c22db906a)

Conflicts:

server/ctdb_freeze.c

freeze: If priority is invalid here, it's time to abort

ctdb_start_freeze() is called from ctdb_control_freeze() which fixes the
priority if it's 0 and return error if it's invalid.  Other callers of
ctdb_start_freeze() are internal to CTDB.  So if priority is invalid in
ctdb_start_freeze(), definitely something is seriously wrong.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 87716e8f504d659515d3dbcf93badbf106873bc8)

Conflicts:

server/ctdb_freeze.c

freeze: Log message from ctdb_start_freeze() and ctdb_control_freeze()

This ensures that whenever databases are frozen either via sending
control or by calling ctdb_start_freeze(), the action is logged.
Since ctdb_control_freeze() calls ctdb_start_freeze(), move logging of
message in early return condition if databases are already frozen.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 478e24bceda3fedfba54ccb48faa115df726b819)

recoverd: Print banning message only after verifying pnn

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 4be8dff3a4451192f838497b4747273685959bed)

recoverd: When updating flags on nodes, send updated flags and not old flags

This was broken by commit a9a1156ea4e10483a4bf4265b8e9203f0af033aa.
Instead of a SRVID_SET_NODE_FLAGS message to recovery daemon, a control
was sent to the local daemon which in turn informed the recovery daemon.
And while doing this change old flags were sent via CONTROL_MODIFY_FLAGS.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 7eb2f89979360b6cc98ca9b17c48310277fa89fc)

vacuum: Reduce the priority of non-critical error

Since the complete database is not locked when the receive_records
control is received, it's possible that we may not be able to obtain
lock on a chain.  We will try again to store this record.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Michael Adam <obnox@samba.org>
(cherry picked from commit 32723c9efdad1c6ca4aa53f308ccd9bef1aadfff)

ctdbd: remove a nonempty blank line

Signed-off-by: Michael Adam <obnox@samba.org>
(cherry picked from commit d9e24782a90d9ce29c0e6584b75d2b186142174d)

ctdbd: update comment describing ctdb_call_send_redirect()

Signed-off-by: Michael Adam <obnox@samba.org>
(cherry picked from commit 9a21d417c51fb9cad8f2e87e00ca54d379aef860)

Conflicts:

server/ctdb_call.c

recoverd: Clarify some misleading log messages

Signed-off-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit 14589bf7c16ba017fe00d4e8bea8cc501546c60f)

recoverd: All inactive nodes should yield recovery master role

Not just stopped nodes.  In reality, this means that banned nodes will
also yield, since nodes in the other inactive states won't be running
a daemon.

This seems sensible since if another node notices that an inactive
node is the recovery master then it will force an election anyway.

Signed-off-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit fc18188b7b63eb0dafbc47e3abf80e306e1dfc31)

Clean up warnings: remove changed_flags in monitor_helper

Signed-off-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit 3e4fa518f02db75e4e4a7f326a71df226913f8a8)

speed startup: alter recovery loop

We do a recovery on startup.  But the code does:
   Sleep for ctdb->tunable.recover_interval.
   Check for recovery.

We want to do it in the other order.  This is best done by extracting
the loop into a separate "main_loop" function.

Seconds between ctdbd first log message and node healthy:
BEFORE: 24.09
AFTER: 23.58

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from commit 097046025176b9fcb670839d1a9f100f890e7ed2)

rename ctdb_set_message_handler to ctdb_client_set_message_handler
to avoid a colission with the function of the same name in libctdb
(cherry picked from commit 41dbdd4fc0ab560420fb0e24a3179ff7c94c5bb7)

Conflicts:

include/ctdb_client.h
tests/src/ctdb_fetch.c

Added some #ifndefs to stop files being included multiple times.

Signed-off-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit fdca12c25e6fce6206135b994dedf44265e4eb09)

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
(cherry picked from commit e7069082e5f0380dcddee247db8754218ce18cab)

Fix the build after backporting f3bf2ab61f8dbbc806ec23a68a87aaedd458e712.

This patch (keeping track of public IP assignment in recovery daemon)
which was backported to 1.0.0114 as 9640e2bb889bd99389d9fb247191a19785a75104
renamed "struct _trbt_tree_t" to "struct trbt_tree".

In master, this patch came before the introduction of the delete queue
to the db context. So in the 1.0.114 branch we need to fix up afterwards.

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

In the recovery daemon, keep track of which node we have assigned public ip
addresses and verify that the remote nodes have/keep a consistent view of
assigned addresses.

If a remote node has an inconsistent view of addresses visavi the recovery
master this will trigger a full ip reallocation.
(cherry picked from commit f3bf2ab61f8dbbc806ec23a68a87aaedd458e712)

Conflicts:

include/ctdb_private.h

vacuuming: Fix vacuuming bug where requests keep bouncing between nodes (part 2)

This is caused by corruption of a record header such that the records
on two nodes point to each other as dmaster.  This makes a request for
that record bounce between nodes endlessly.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit f0853013655ac3bedf1b793de128fb679c6db6c6)

Conflicts:

server/ctdb_recover.c

vacuuming: Fix vacuuming bug where requests keep bouncing between nodes (part 1)

This is caused by corruption of a record header such that the records
on two nodes point to each other as dmaster.  This makes a request for
that record bounce between nodes endlessly.

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit a610bc351f0754c84c78c27d02f9a695e60c5b0f)

Set FD_CLOEXEC for epoll file descriptors

Don't leak file descriptors.
This showed up as selinux AVCs on RHEL:
https://bugzilla.redhat.com/show_bug.cgi?id=728545

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

Print deleted nodes as well

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 0930a3b806977555509c3228726e2250aef1f971)

Conflicts:

tools/ctdb.c

IPv6 neighbor solicit cleanup

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit a81edf7eb908659a379f0cb55fd5d04551dc2c37)

Fix memory leak in ctdb_send_message()

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit da87395d29f5d11ecfedaf36b53fa060a9140bfd)

tdb: Fix Coverity ID 2192: NO_EFFECT

(ret < 0) can never be true
(cherry picked from commit 25397de589e577e32bb291576b10c18978b5bc4e)

Fixes for various issues found by Coverity

Corresponds to commit 05bfdbbd0d4abdfbcf28e3930086723508b35952 from master.

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()
(cherry picked from commit f8642d0438c6bbb34a72c25d6a904b626e247410)

idtree: fix overflow for v. large ids on allocation and removal

(Imported from SAMBA commit 09a6538969ac).

Chris Cowan tracked down a SEGV in sub_alloc: idp->level can actually
be equal to 7 (MAX_LEVEL) there, as it can be in sub_remove.

(We unfairly blamed a shift of a signed var for this crash in commit
 2db1987f5a3a).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from commit 73764104356d3738d9d20a9d06ce51535f74f475)

idtree: fix right shift of signed ints, crash on large ids on AIX

Right-shifting signed integers in undefined; indeed it seems that on
AIX with their compiler, doing a 30-bit shift on (INT_MAX-200) gives
0, not 1 as we might expect.

The obvious fix is to make id and oid unsigned: l (level count) is also
logically unsigned.

(Note: Samba doesn't generally get to ids > 1 billion, but ctdb does)

Reported-by: Chris Cowan <cc@us.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Autobuild-User: Rusty Russell <rusty@samba.org>
Autobuild-Date: Wed Oct  6 08:31:09 UTC 2010 on sn-devel-104
(cherry picked from commit 2db1987f5a3a4268ce64fe570ff598e3bf4ecc73)

Check return value of tdb_delete()

Signed-off-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 5cdcc3d45d358ddbcd7e864898eed9cbd9935429)

New version 1.0.114.6

vacuum: Update (C)

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 61264debba58355b9716ac1637fdedef5ed249c8)

vacuum: extend the header comment for ctdb_process_delete_list()

Describe the (new) process more precisely.
And mention that is the last step of the vacuuming process
that is performed on the lmaster.

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 06de786c786f1cab4c6721adf47c2cb1e8a72adb)

vacuum: turn the vacuuming on lmaster into a three-phase process.

More precisely, before locally deleting an empty record, that has been
migrated with data and that we are dmaster and laster for, we now perform
the deletion on the other nodes in two steps instead of a single step.

- First send out the list of records to be deleted to all
  other nodes with the new RECEIVE_RECORDS control to store
  the lmaster's current empty copy.
- Then send those records that could be deleted on all nodes
  to all nodes again with the TRY_DELETE_RECORDS control
  as before for deletion.
- Finally delete those records locally that were successfully
  deleted remotely in the previous step.

This fixes an old race where a recovery that hits the vacuum process
square between the eyes can create gaps in the record's history and
hence let the records resurrect. In the case of the locking.tdb,
that could mean that a file that was already closed, was recorded as
being open and locked again, so samba clients were locked out of that
file until samba was restarted.

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit eee23d44b6427be8ab49bbfcee3abb62f37dfcc7)

vacuum: introduce the RECEIVE_RECORDS control

This in preparation of turning the vacuming on the lmaster into
into a two phase process:

- First the node sends the list of records to be vacuumed
  to all other nodes with this new RECEIVE_RECORDS control.
  The remote nodes should store the lmaster's empty current copy.
- Only those records that could be stored on all other nodes
  are processed further. They are send to all other nodes with
  the TRY_DELETE_RECORDS control as before for deletion.

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit e397702e271af38204fd99733bbeba7c1db3a999)

Conflicts:

include/ctdb_protocol.h
server/ctdb_control.c

vacuum: reorder some of ctdb_process_delete_list() more intuitively

Now that the nodemap and its talloc children don't hang off of the
delete_records_list talloc context, we can build the nodemap
and earlier, and move the construction of the delete_records_list
to where it is more obvious what it is used for.

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit e3740899c1af6962f93c85ad7d1cb71bddce45c6)

vacuum: add explicit temporary memory context to ctdb_process_delete_list()

This removes the implicit artificial talloc hierarchy and makes the
code easier to understand.

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit b7c3b8cdf92c597e621e3dae28b110d321de5ea8)

vacuum: fix indentation in ctdb_process_delete_list()

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 59a887e12469266e514ad7d4e34810e7ea888ba3)

vacuum: free temporary allocated memory correctly in ctdb_process_delete_list().

Add a common exit point for cleanup.

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 11d728465a9c635e1829abaae17e2f7720433b69)

vacuum: move variable into scope of use in ctdb_process_delete_list()

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 3710dd0f313f551f1b302b4961e0203243e3d661)

vacuum: move variable into scope of use in ctdb_process_delete_list()

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 4640979b526b6dac69a6a0555bfce75fe0206dac)

vacuum: simplify ctdb_process_delete_list(): reduce indentation

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit f3e6e7f8ef22bd70dd2f101d818e2e5ab5ed3cd8)

Conflicts:

server/ctdb_vacuum.c

vacuum: add DEBUG to skip conditions in delete_record_traverse()

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 817c77a3d0a3546bf46389cec5f6b54778dd1693)

Conflicts:

server/ctdb_vacuum.c

client: fix ctdb_control() to be able to cope with CTDB_CTRL_FLAG_NOREPLY

This was apparently not used before in this context, and the bug hence
not detected. It becomes necessary when ctdb_local_schedule_for_deletion()
is called from a client ctdbd (the vacuuming child), hence needs to send
the SCHEDULE_FOR_DELETION control to its parent.

Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit e72a5e11845fe445baaee4730bb0bea8588ee9e3)

ctdb_call: don't bump the rsn in ctdb_become_dmaster() any more

This is now done in ctdb_ltdb_store_server(), so this
extra bump can be spared.

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit cad3107b12e8392f786f9a758ee38cf3a3d58538)

Fix a severe recovery bug that can lead to data corruption for SMB clients.

Problem:
Recovery can under certain circumstances lead to old record copies
resurrecting: Recovery selects the newest record copy purely by RSN. At
the end of the recovery, the recovery master is the dmaster for all
records in all (non-persistent) databases. And the other nodes locally
hold the complete copy of the databases. The bug is that the recovery
process does not increment the RSN on the recovery master at the end of
the recovery. Now clients acting directly on the Recovery master will
directly change a record's content on the recmaster without migration
and hence without RSN bump.  So a subsequent recovery can not tell that
the recmaster's copy is newer than the copies on the other nodes, since
their RSN is the same. Hence, if the recmaster is not node 0 (or more
precisely not the active node with the lowest node number), the recovery
will choose copies from nodes with lower number and stick to these.

Here is how to reproduce:

- assume we have a cluster with at least 2 nodes
- ensure that the recmaster is not node 0
  (maybe ensure with "onnode 0 ctdb setrecmasterrole off")
  say recmaster is node 1
- choose a new database name, say "test1.tdb"
  (make sure it is not yet attached as persistent)
- choose a key name, say "key1"
- all clustere nodes should ok and no recovery running
- now do the following on node 1:

1. dbwrap_tool test1.tdb store key1 uint32 1
2. dbwrap_tool test1.tdb fetch key1 uint32
   ==> 1
3. ctdb recover
4. dbwrap_tool test1.tdb store key1 uint32 2
5. dbwrap_tool test1.tdb fetch key1 uint32
   ==> 2
4. ctdb recover
7. dbwrap_tool test1.tdb fetch key1 uint32
   ==> 1
   ==> BUG

This is a very severe bug, since when applied to Samba's locking.tdb
database, it means that for SMB clients on clustered Samba there is
the potential for locking out oneself from previously opened files
or even worse, data corruption:

Case 1: locking out

- client on recmaster opens file
- recovery propagates open file handle (entry in locking.tdb) to
  other nodes
- client closes file
- client opens the same file
- recovery resurrects old copy of open file record in locking.tdb
  from lower node
- client closes file but fails to delete entry in locking.tdb
- client tries to open same file again but fails, since
  the old record locks it out (since the client is still connected)

Case 2: data corruption

- clien1 on recmaster opens file
- recovery propagates open file info to other nodes
- client1 closes the file and disconnects
- client2 opens the same file
- recovery resurrects old copy of locking.tdb record,
  where client2 has no entry, but client1 has.
- but client2 believes it still has a handle
- client3 opens the file and succees without
  conflicting with client2
  (the detached entry for client1 is discarded because
   the server does not exist any more).
=> both client2 and client3 believe they have exclusive
  access to the file and writing creates data corruption

Fix:

When storing a record on the dmaster, bump its RSN.

The ctdb_ltdb_store_server() is the central function for storing
a record to a local tdb from the ctdbd server context.
So this is also the place where the RSN of the record to be stored
should be incremented, when storing on the dmaster.

For the case of the record migration, this is currently done in
ctdb_become_dmaster() in ctdb_call.c, but there are other places
such as in recovery, where we should bump the RSN, but currently
don't do it.

So moving the RSN incrementation into ctdb_ltdb_store_server fixes
the recovery-record-resurrection bug.

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-By: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit feb1d40b21a160737aead22e398f3c34ff3be8de)

Conflicts:

server/ctdb_ltdb_server.c

logging: fix comment typo

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 4c0cbfbe8b19f2e6fe17093b52c734bec63dd8b7)

ctdbd: unimplement the unused SET_DMASTER control

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 2e92deef5221ee651028ef87138b3113f1fece91)

Conflicts:

include/ctdb_protocol.h
server/ctdb_recover.c

recoverd: remove bogus comment "qqq" from "add prototype new banning code"

Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
(cherry picked from commit 9f01b8db72780acf2f88f1392bc0a796dd4c6176)

Fix typo in ctdb_ltdb_store_server()

The if statement uses ret but means to use ret2.

Signed-off-by: Martin Schwenke <martin@meltin.net>
(cherry picked from commit f40101a615f8b9826a484e4697bfea6ee2b9ba88)

ctdb:recover: fix a comment typo

Signed-off-by: Michael Adam <obnox@samba.org>
(cherry picked from commit 5067392d2e06795559f25828b65c129608b65c0b)

vacuum: Avoid some tallocs in ctdb recovery

In a heavily loaded and volatile database a lot of SCHEDULE_FOR_DELETION
requests can come in between fast vacuuming runs. This can lead to
significant ctdb cpu load due to the cost of doing talloc_free. This
reduces the number of objects a bit by coalescing the two objects
of delete_record_data into one. It will also avoid having to allocate
another talloc header for a SCHEDULE_FOR_DELETION key. Not the full fix
for this problem, but it might contribute a bit.
(cherry picked from commit 9a02f61547ddf74629aca21639d8fb61c1df7cbb)

vacuum: fix a comment typo

Pair-Programmed-With: Volker Lendecke <vl@samba.org>
Signed-off-by: Michael Adam <obnox@samba.org>
(cherry picked from commit bab744e3c49efef2e05dc09e8ea9bd3e3fa58716)

New version 1.0.114.5.

recover: finish pending trans3 commits when a recovery is finished.

When the end_recovery control is received, pending trans3 commits are
finished. During the recovery, all the actions like persistent_callback
and persistent_store_timeout had been disabled to let the recovery do
its job. After the recover is completed, send the reply to the waiting
clients.
(cherry picked from commit f7dfeb7143f574c2434f7dd16917380dfd1f4f64)

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

persistent: add ctdb_persistent_finish_trans3_commits().

This function walks all databases and checks for running trans3 commits.
It sends replies to all of them (with error code) and ends them.
To be called when a recovery finishes.
(cherry picked from commit 70ba153b532528bdccea70c5ea28972257f384c1)

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

daemon: correctly end a running trans3_commit if the client disconnects.
(cherry picked from commit 9e0898db6df52d9bc799dd87bfea8c72d5f70ba0)

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

persistent: add a client context to the persistent_stat and track the db_id

The db_id is tracked in the client context as an indication that a
transaction commit is in progress. This is cleared in the persistent_state
talloc destructor.

This is in order to properly treat running trans3_commits if the client
disconnects.
(cherry picked from commit e886ff24f4e3e250944289db95916b948893d26c)

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

persistent: reject trans3_control when a commit is already active.

This should actually never happen.
(cherry picked from commit f416e76838fe2adf629d4356d1cc87054b1af164)

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

persistent: allocate the persistent state in the ctdb_db struct in trans3_commit

Make sure that ctdb_db->persistent_state is correctly NULL-ed when
the state is freed. This way, we can use ctdb_db->persistent_state
as an indication for whether a transaction commit is currently
running.
(cherry picked from commit 761cb235193564a0f337d0308f0a9e6de0ef2710)

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

persistent: add a ctdb_db context to the ctdb_persistent_state struct.
(cherry picked from commit a14917c983c3b9bbbf38f5ddeecdbbe5bde32364)

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

persistent: add a ctdb_persistent_state member to the ctdb_db context.

To be used for tracking running transaction commits through recoveries.

(Backported from commit 1237e15df4af58a3d220eea42a4b75e21e65029f)

persistent_callback: print "no error message given" instead of "(null)"
(cherry picked from commit d871a38978219e004833608c11aae98fe47614b9)

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

persistent: reduce indentation for the finishing moves in ctdb_persistent_callback
(cherry picked from commit 2c2d1646eb753ea9561f085bcb101153267b052b)

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

persistent: if a node failed to update_record, trigger a recovery

and stop processing of the update_record replies in order to let
the recovery finish the trans3_commit control.
(cherry picked from commit cab95570dc1eefb08abbac5ae411c29f699b51cc)

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

persistent_store_timout: do not really time out the trans3_commit control in recovery

If a recovery was started, then all further processing of the update_record
controls sent by the trans3_commit control and timing them out is disabled.
The recovery should trigger sending the reply for the update record control
when finished.
(cherry picked from commit 983c1ca2e18ecd60fca69bfe9e116125cc695857)

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

persistent_callback: ignore the update-recordreturn code of remote node in recovery

If a recovery was started, then all further processing of the update_record
controls sent by the trans3_commit control is disabled. The recovery should
trigger sending the reply for the update record control when finished.
(cherry picked from commit 12cf0619255b12230843cd8bb49cbfdea376ca2f)

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

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>
(cherry picked from commit 72d6914ee913272312d7b68f1be5ad05ad06587d)

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

New version 1.0.114.4

Includes vacuuming fixes and cleanup.

ltdb_server: improve logging in ctdb_ltdb_store_server

When logging which key to store/delete, list the ctdb_hash
and the jenkins_hash. In this version, the databases still
use the the old hash (with lots of hash collisions) while
the internal lists (vacuuming, schedule_for_deletion, ...)
already use the jenkins hash.

doc:ctdb.1: add generated files after update

doc:ctdb.1: explain that "ctdb listvars" does not list obsolete tunables any more
(cherry picked from commit 4ed94279f243729d521d365a44607fd086ae7c41)

doc:ctdb.1: adapt example output of "ctdb listvars" to current state

ctdb-tool: adapt formatting of "listvars" output to lenght of longest name
(cherry picked from commit 295168d99183d2d21f27a8ac6825d421fa866b28)

tunables: don't list obsolete tunables in the list_tunables control
(cherry picked from commit d8ab86f0eb11437e50d18183858dd3177a8f61e6)

tunables: add a bool obsolete flag to the tunable_map list

(cherry picked from commit 1a7d9b25fdcf7b59598618d406c2a681c90d9163)

vacuum: improve logging in remove_record_from_delete_queue()
(cherry picked from commit 809d1f3b8a9232fce0376cb47e4f633b49237529)

vacuum: improve logging in delete_record_traverse()
(cherry picked from commit 40ca781b3305d9f0bfee5b109d4eefde461a3f13)

vacuum: improve logging in insert_record_into_delete_queue()
(cherry picked from commit db59ac2ee6a9f5f7f088ebbc5e2800d9e57aae17)