default ctdb configuration file locations

[Steve French]

On Sat, Oct 22, 2016 at 3:39 PM, Martin Schwenke <martin at meltin.net> wrote:
> On Fri, 21 Oct 2016 10:48:30 -0500, Steve French <smfrench at gmail.com>
> wrote:
>
>> [...] Part of the reason I was worrying
>> about this is seeing some strange behavior I (at first) thought was
>> configuration related but presumably is not.  I had configured a two
>> node ctdb cluster with the node below's ctdbd.conf configured as:
>>
>> "CTDB_CAPABILITY_RECMASTER=no"
>>
>>
>> $ ctdb status
>>
>> Number of nodes:2
>> pnn:0 172.29.161.26    OK
>> pnn:1 172.29.161.45    OK (THIS NODE)
>> Generation:1678151314
>> Size:2
>>
>> hash:0 lmaster:0
>> hash:1 lmaster:1
>> Recovery mode:NORMAL (0)
>> Recovery master:1
>>
>> I am certain that CTDB_CAPABILITY_RECMASTER is set to no on that node
>> (and not set to anything on the other node) but it is still becoming
>> recovery master which I found confusing.
>
> What does "ctdb getcapabilities" say on that node?
>
> If it says "YES":

It says
    RECMASTER: NO
    LMASTER: YES

 on both nodes including what should be the master node, ie the one
where CTDB_CAPABILITY_RECMASTER=no is commented out.  I expected it to
say "RECMASTER:NO" only on the nodes where
CTDB_CAPABILITY_RECMASTER=no
is explicitly set


> * Have you restarted CTDB since setting "CTDB_CAPABILITY_RECMASTER=no"?

Yes


> * CTDB_CAPABILITY_RECMASTER is case-sensitive
>
>   Only an exact value of "no" will switch it off.  Perhaps we need to
>   loosen the matching?
>
> If it says "NO" and the node is recovery master (for more than about
> a second) then we have a bug in the recovery daemon's recovery master
> checking logic. I have touched that code several times in the last
> couple of years so there is obviously a chance that I have broken it.
> However, it does work for me...  :-)

So two interesting things,

1) with what it thinks is no recovery master capable node, it picked
one anyway (the last one in this case).

2) defaults are not what we expected. setting
CTDB_CAPABILITY_RECMASTER=yes explicitly and restarting ctdb did work.
So the default (if that line is commented out) is "RECMASTER:NO" not
"RECMASTER:YES" (at least in some cases, e.g. in our case we don't
configure a recovery lock file).   This is Samba 4.5.1

-- 
Thanks,

Steve