[PATCH]: Inconsistent recmaster during election.
kdinh at peaxy.net
Thu Jan 21 03:03:40 UTC 2016
> "We need to figure out if some changes to winbind mean that this
particular smbcontrol is no longer required."
Do you mean recent patches to winbind? Do you want me to test with samba
4.2.x or any newer version of samba, or would samba 4.2.3-10 and ctdb 2.5.4
Secondly, I was under the impression that you were going to work toward
what Volker suggested.
[Volker] - "So maybe it's time to implement reading from the registry
without messing with ctdb"
>From your reply, I am getting the impression that reading from the registry
is not an issue. The issue is that smbcontrol needs to connect CTDB as a
client and it could not do so while ctdb is in recovery mode. Sorry for
repeating your word but I wanted to clarify.
If that is the case, one option is to do what you suggested. Another
option is to allow the recovery to go ahead without nodes that are in the
process of shutting down. Once the recovery is completed, "smbcontrol
winbindd ip-dropped" will get unblocked. To omit nodes during recovery,
nodes that are going down could respond to CTDB_CONTROL_GET_RECMASTER with
(-1) and the RECMASTER could ignore (-1) in verify_recmaster_callback(). I
tried this workaround and it worked but I did not mentioned it because I
thought the correct fix is what Volker suggested above.
I will test out your suggestion as soon as I get a hold of test hardware.
On Wed, Jan 20, 2016 at 6:14 PM, Martin Schwenke <martin at meltin.net> wrote:
> On Tue, 12 Jan 2016 17:02:25 +1100, Martin Schwenke <martin at meltin.net>
> > OK. Still thinking about answers to this... :-)
> I'm still trying to find ways around this.
> I thought about modifying 49.winbind so that it no longer does
> "smbcontrol winbindd ip-dropped ..." when CTDB is shutting down.
> However, the problem is not that CTDB on the current node is shutting
> down, it is that a node (any node!) (shutting down) has triggered a
> recovery so smbcontrol is unable to connect to CTDB as a client.
> We need to figure out if some changes to winbind mean that this
> particular smbcontrol is no longer required.
> Alternatively, we need to understand how important it is. We could
> just run it under the timeout(1) command:
> timeout 5 smbcontrol winbindd ip-dropped $ip >/dev/null 2>/dev/null
> The redirections there and lack of anything looking at the exit code
> suggests that we don't care a lot whether it works or not. So, while
> not a well thought out solution, the above seems to be a reasonable
> Do you want to try the above and see if your problems magically go
> away? :-)
> peace & happiness,
More information about the samba-technical