{"action":"created","issue":{"url":"https://api.github.com/repos/acassen/keepalived/issues/950","repository_url":"https://api.github.com/repos/acassen/keepalived","labels_url":"https://api.github.com/repos/acassen/keepalived/issues/950/labels{/name}","comments_url":"https://api.github.com/repos/acassen/keepalived/issues/950/comments","events_url":"https://api.github.com/repos/acassen/keepalived/issues/950/events","html_url":"https://github.com/acassen/keepalived/issues/950","id":340044212,"node_id":"MDU6SXNzdWUzNDAwNDQyMTI=","number":950,"title":"forcing new election without action","user":{"login":"mrozentsvayg","id":26338219,"node_id":"MDQ6VXNlcjI2MzM4MjE5","avatar_url":"https://avatars2.githubusercontent.com/u/26338219?v=4","gravatar_id":"","url":"https://api.github.com/users/mrozentsvayg","html_url":"https://github.com/mrozentsvayg","followers_url":"https://api.github.com/users/mrozentsvayg/followers","following_url":"https://api.github.com/users/mrozentsvayg/following{/other_user}","gists_url":"https://api.github.com/users/mrozentsvayg/gists{/gist_id}","starred_url":"https://api.github.com/users/mrozentsvayg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mrozentsvayg/subscriptions","organizations_url":"https://api.github.com/users/mrozentsvayg/orgs","repos_url":"https://api.github.com/users/mrozentsvayg/repos","events_url":"https://api.github.com/users/mrozentsvayg/events{/privacy}","received_events_url":"https://api.github.com/users/mrozentsvayg/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-07-10T23:46:53Z","updated_at":"2018-07-11T07:31:51Z","closed_at":null,"author_association":"NONE","body":"Hi,\r\n\r\nThis is pretty much the same issue as:\r\nhttps://github.com/acassen/keepalived/issues/100\r\nit has been closed without resolution, however it can occasionally reproduce.\r\n\r\nslave:\r\n```\r\nJul  9 14:41:42 i-<slave> Keepalived_vrrp[19036]: (instance1) Entering MASTER STATE\r\nJul  9 14:41:42 i-<slave> Keepalived_vrrp[19036]: (instance1) Master received advert from <master> with higher priority 122, ours 121\r\nJul  9 14:41:42 i-<slave> Keepalived_vrrp[19036]: (instance1) Entering BACKUP STATE\r\n```\r\n\r\nmaster:\r\n```\r\nJul  9 14:41:42 i-<master> Keepalived_vrrp[10266]: (instance1) Received advert from <slave> with lower priority 121, ours 122, forcing new election\r\n```\r\n\r\nwhat happened here is that for a split second slave considered itself a master and executed a `notify_master` script. in our case it assigns a secondary ip in AWS.\r\nmaster triggered a reelection, but as it kept considering itself a master, it didn't execute anything. the state didn't change it's got nothing to do.\r\n\r\nas a result we got a broken vrrp pair, the ip in AWS was pointing to the instance in a backup state.\r\n\r\nAs mentioned in the issue 100, it could be worked around with journalctl in vrrp_script or some other ugly periodic checks,  but it would also potentially prone to the race cases.\r\nWhat Is the recommended way to handle this ?\r\n\r\nThank you."},"comment":{"url":"https://api.github.com/repos/acassen/keepalived/issues/comments/404072948","html_url":"https://github.com/acassen/keepalived/issues/950#issuecomment-404072948","issue_url":"https://api.github.com/repos/acassen/keepalived/issues/950","id":404072948,"node_id":"MDEyOklzc3VlQ29tbWVudDQwNDA3Mjk0OA==","user":{"login":"pqarmitage","id":15689733,"node_id":"MDQ6VXNlcjE1Njg5NzMz","avatar_url":"https://avatars1.githubusercontent.com/u/15689733?v=4","gravatar_id":"","url":"https://api.github.com/users/pqarmitage","html_url":"https://github.com/pqarmitage","followers_url":"https://api.github.com/users/pqarmitage/followers","following_url":"https://api.github.com/users/pqarmitage/following{/other_user}","gists_url":"https://api.github.com/users/pqarmitage/gists{/gist_id}","starred_url":"https://api.github.com/users/pqarmitage/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pqarmitage/subscriptions","organizations_url":"https://api.github.com/users/pqarmitage/orgs","repos_url":"https://api.github.com/users/pqarmitage/repos","events_url":"https://api.github.com/users/pqarmitage/events{/privacy}","received_events_url":"https://api.github.com/users/pqarmitage/received_events","type":"User","site_admin":false},"created_at":"2018-07-11T07:31:51Z","updated_at":"2018-07-11T07:31:51Z","author_association":"COLLABORATOR","body":"Could you please provide the following details:\r\n1. Version of keepalived being used\r\n2. What distro you are running, what version and what kernel version\r\n3. A description of the environment the systems are running in.\r\n\r\nThe only reasons a vrrp instance in backup mode can transition to master is if it doesn't receive an advert for three advert intervals, or following receipt of a priority 0 advert, it doesn't receive an advert within (256 - own priority)/256 * advert interval (or something close to that). In this case, you don't indicate that receipt of a 0 priority advert was logged, so I'll assume that was not the case. This leaves us with the backup instance not receiving an advert for 3 advert intervals, which suggests that there is some sort of (possibly intermittent) connectivity problem between the two systems.\r\n\r\nYou could try one or more of the following:\r\n1. Use a `notify_backup` script to remove the secondary ip in AWS\r\n2. Could you use keepalived itself to manage the secondary ip in AWS?\r\n3. Increase the advert interval so that a short break in connectivity doesn't trigger a timeout on the backup instance."}}
{"actor":{"display_login":"pqarmitage"}}