CTDB and Recovery lock

[Martin Schwenke]

Hi Partha,

On Tue, 17 Nov 2015 14:00:11 -0800, Partha Sarathi
<parthasarathi.bl at gmail.com> wrote:

> > > Also we don't have our Clustered Filesystem with Posix locking
> > > support but we do have Consensus/Conspiracy service available in
> > > cluster, is it possible to make use of that infrastructure to
> > > mimic the recovery file lock mechanism ?  

> > Not today.  Hopefully soon.  As I untangle some of this I will make the
> > "exclusive" lock code call out to a configurable helper program.

> Thanks a lot Martin for your detailed answers.
> 
> Now I am more interested about the "configurable helper program" you
> mentioned  which replaces the recovery lock mechanism. May I know little
> more about it ?.

We are thinking of an executable similar to the current
ctdb_event_helper.  This would take some file descriptors for status
and logging, and whatever other arguments are needed - for the fcntl(2)
helper the only other argument would probably be the filename.

The behaviour would be something like this:

* If the cluster-wide mutex can be taken then write 0 to the status file
  descriptor and hold the mutex until terminated with a signal or the
  parent exits.

* If the cluster-wide mutex can't be taken then write non-0 (or nothing)
  to the status file descriptor, potentially write some messages to the
  logging file descriptor, and exit.  It would probably make sense to
  write an errno to the status file descriptor so CTDB can tell if
  there was contention for the mutex (e.g. EACCES or EAGAIN) or some
  other error.  We would need some sort of convention - I won't invent
  it now.  :-)

* When CTDB wants to release the mutex it could send SIGTERM.

* If the parent exits then release the mutex and exit.

How does that sound?

As I said, there is probably a bit more untangling to do before this
can be implemented.  I hope this can be done before Samba 4.4 is
released in March 2016.

peace & happiness,
martin