Looking at the rabbitmq logs, it appears to me (I could be misinterpreting):
At 21:39:23 -> unit 2 becomes the leader (the leader-elected hook is run) At 21:47:25 -> unit 0 becomes the leader (the leader-elected hook is run) At 22:01:27 -> unit 1 becomes the leader (the leader-elected hook is run) At 22:13:54 -> unit 1 thinks it is the leader and updates leader settings but Juju thinks it is not At 22:17:06 -> unit 0 becomes the leader (the leader-elected hook is run) At 22:22:57 -> unit 0 thinks it is the leader and updates leader settings but Juju thinks it is not So it appears that Juju ran the leader elected hook on both unit 0 and unit 1 and these units tried to do stuff as leader. But Juju thinks unit 2 is leader. Curiously, at 22:17:06 and 22:17:58, unit 2 successfully updates leader settings, even though it should not have been the leader anymore. The charm doesn't appear to use leader elected or deposed hooks - it just symlinks to a common Python file. Juju still thinks that there are hooks though, so it runs the leader-elected hook and logs that. But I can't see any logs of where Juju runs the leader-deposed hook. Perhaps that's a clue? Perhaps that indicates that Juju is getting confused as to who the leader is? It would be useful to have a mongo dump to see what state the model is in. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1654116 Title: Attempts to write leadership settings when not the leader during relation-changed hooks To manage notifications about this bug go to: https://bugs.launchpad.net/autopilot-log-analyser/+bug/1654116/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
