Activity log for bug #1739033

Date Who What changed Old value New value Message
2017-12-19 14:00:31 Victor Tapia bug added bug
2017-12-19 15:29:56 Victor Tapia description [Description] Corosync sigaborts if it starts before the interface it has to bind to is ready. On boot, if no interface in the bindnetaddr range is up/configured, corosync binds to lo (127.0.0.1). Once an applicable interface is up, corosync crashes with the following error message: corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: Assertion `sender_node != NULL' failed. Aborted (core dumped) The last log entries show that the interface is trying to join the cluster: Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug [TOTEM ] totemsrp.c:2089 entering OPERATIONAL state. Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members joined: 704573706 During the quorum calculation, the generated nodeid (704573706) for the node is being used instead of the nodeid specified in the configuration file (1), and the assert fails because the nodeid is not present in the member list. Corosync should use the correct nodeid and continue running after the interface is up, as shown in a fixed corosync boot: Dec 19 11:50:56 [4824] xenial-corosync corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:80) was formed. Members joined: 1 [Environment] Xenial 16.04.3 Packages: ii corosync 2.3.5-3ubuntu1 amd64 cluster engine daemon and utilities ii libcorosync-common4:amd64 2.3.5-3ubuntu1 amd64 cluster engine common library [Reproducer] Config: totem { version: 2 transport: udpu crypto_cipher: none crypto_hash: none interface { ringnumber: 0 member { memberaddr: 169.254.241.10 } member { memberaddr: 169.254.241.20 } bindnetaddr: 169.254.241.0 mcastport: 5405 ttl: 1 } } quorum { provider: corosync_votequorum expected_votes: 2 } nodelist { node { ring0_addr: 169.254.241.10 nodeid: 1 } node { ring0_addr: 169.254.241.20 nodeid: 2 } } 1. ifdown interface (169.254.241.10) 2. start corosync (/usr/sbin/corosync -f) 3. ifup interface [Fix] Commit https://github.com/corosync/corosync/commit/aab55a004bb12ebe78db341dc56759dfe710c1b2 fixes the way the CMAP is populated, and seems to fix this bug. [Description] Corosync sigaborts if it starts before the interface it has to bind to is ready. On boot, if no interface in the bindnetaddr range is up/configured, corosync binds to lo (127.0.0.1). Once an applicable interface is up, corosync crashes with the following error message: corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: Assertion `sender_node != NULL' failed. Aborted (core dumped) The last log entries show that the interface is trying to join the cluster: Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug [TOTEM ] totemsrp.c:2089 entering OPERATIONAL state. Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members joined: 704573706 During the quorum calculation, the generated nodeid (704573706) for the node is being used instead of the nodeid specified in the configuration file (1), and the assert fails because the nodeid is not present in the member list. Corosync should use the correct nodeid and continue running after the interface is up, as shown in a fixed corosync boot: Dec 19 11:50:56 [4824] xenial-corosync corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:80) was formed. Members joined: 1 [Environment] Xenial 16.04.3 Packages: ii corosync 2.3.5-3ubuntu1 amd64 cluster engine daemon and utilities ii libcorosync-common4:amd64 2.3.5-3ubuntu1 amd64 cluster engine common library [Reproducer] Config: totem {         version: 2         transport: udpu         crypto_cipher: none         crypto_hash: none         interface {                 ringnumber: 0                 member {                         memberaddr: 169.254.241.10                 }                 member {                         memberaddr: 169.254.241.20                 }                 bindnetaddr: 169.254.241.0                 mcastport: 5405                 ttl: 1         } } quorum {         provider: corosync_votequorum         expected_votes: 2 } nodelist {         node {                 ring0_addr: 169.254.241.10                 nodeid: 1         }         node {                 ring0_addr: 169.254.241.20                 nodeid: 2         } } 1. ifdown interface (169.254.241.10) 2. start corosync (/usr/sbin/corosync -f) 3. ifup interface
2017-12-19 15:54:54 Victor Tapia description [Description] Corosync sigaborts if it starts before the interface it has to bind to is ready. On boot, if no interface in the bindnetaddr range is up/configured, corosync binds to lo (127.0.0.1). Once an applicable interface is up, corosync crashes with the following error message: corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: Assertion `sender_node != NULL' failed. Aborted (core dumped) The last log entries show that the interface is trying to join the cluster: Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug [TOTEM ] totemsrp.c:2089 entering OPERATIONAL state. Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members joined: 704573706 During the quorum calculation, the generated nodeid (704573706) for the node is being used instead of the nodeid specified in the configuration file (1), and the assert fails because the nodeid is not present in the member list. Corosync should use the correct nodeid and continue running after the interface is up, as shown in a fixed corosync boot: Dec 19 11:50:56 [4824] xenial-corosync corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:80) was formed. Members joined: 1 [Environment] Xenial 16.04.3 Packages: ii corosync 2.3.5-3ubuntu1 amd64 cluster engine daemon and utilities ii libcorosync-common4:amd64 2.3.5-3ubuntu1 amd64 cluster engine common library [Reproducer] Config: totem {         version: 2         transport: udpu         crypto_cipher: none         crypto_hash: none         interface {                 ringnumber: 0                 member {                         memberaddr: 169.254.241.10                 }                 member {                         memberaddr: 169.254.241.20                 }                 bindnetaddr: 169.254.241.0                 mcastport: 5405                 ttl: 1         } } quorum {         provider: corosync_votequorum         expected_votes: 2 } nodelist {         node {                 ring0_addr: 169.254.241.10                 nodeid: 1         }         node {                 ring0_addr: 169.254.241.20                 nodeid: 2         } } 1. ifdown interface (169.254.241.10) 2. start corosync (/usr/sbin/corosync -f) 3. ifup interface [Description] Corosync sigaborts if it starts before the interface it has to bind to is ready. On boot, if no interface in the bindnetaddr range is up/configured, corosync binds to lo (127.0.0.1). Once an applicable interface is up, corosync crashes with the following error message: corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: Assertion `sender_node != NULL' failed. Aborted (core dumped) The last log entries show that the interface is trying to join the cluster: Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug [TOTEM ] totemsrp.c:2089 entering OPERATIONAL state. Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members joined: 704573706 During the quorum calculation, the generated nodeid (704573706) for the node is being used instead of the nodeid specified in the configuration file (1), and the assert fails because the nodeid is not present in the member list. Corosync should use the correct nodeid and continue running after the interface is up, as shown in a fixed corosync boot: Dec 19 11:50:56 [4824] xenial-corosync corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:80) was formed. Members joined: 1 [Environment] Xenial 16.04.3 Packages: ii corosync 2.3.5-3ubuntu1 amd64 cluster engine daemon and utilities ii libcorosync-common4:amd64 2.3.5-3ubuntu1 amd64 cluster engine common library [Reproducer] Config: totem {         version: 2         transport: udpu         crypto_cipher: none         crypto_hash: none nodeid: 1         interface {                 ringnumber: 0                 member {                         memberaddr: 169.254.241.10                 }                 member {                         memberaddr: 169.254.241.20                 }                 bindnetaddr: 169.254.241.0                 mcastport: 5405                 ttl: 1         } } quorum {         provider: corosync_votequorum         expected_votes: 2 } nodelist {         node {                 ring0_addr: 169.254.241.10                 nodeid: 1         }         node {                 ring0_addr: 169.254.241.20                 nodeid: 2         } } 1. ifdown interface (169.254.241.10) 2. start corosync (/usr/sbin/corosync -f) 3. ifup interface
2017-12-19 18:20:54 Victor Tapia description [Description] Corosync sigaborts if it starts before the interface it has to bind to is ready. On boot, if no interface in the bindnetaddr range is up/configured, corosync binds to lo (127.0.0.1). Once an applicable interface is up, corosync crashes with the following error message: corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: Assertion `sender_node != NULL' failed. Aborted (core dumped) The last log entries show that the interface is trying to join the cluster: Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug [TOTEM ] totemsrp.c:2089 entering OPERATIONAL state. Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members joined: 704573706 During the quorum calculation, the generated nodeid (704573706) for the node is being used instead of the nodeid specified in the configuration file (1), and the assert fails because the nodeid is not present in the member list. Corosync should use the correct nodeid and continue running after the interface is up, as shown in a fixed corosync boot: Dec 19 11:50:56 [4824] xenial-corosync corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:80) was formed. Members joined: 1 [Environment] Xenial 16.04.3 Packages: ii corosync 2.3.5-3ubuntu1 amd64 cluster engine daemon and utilities ii libcorosync-common4:amd64 2.3.5-3ubuntu1 amd64 cluster engine common library [Reproducer] Config: totem {         version: 2         transport: udpu         crypto_cipher: none         crypto_hash: none nodeid: 1         interface {                 ringnumber: 0                 member {                         memberaddr: 169.254.241.10                 }                 member {                         memberaddr: 169.254.241.20                 }                 bindnetaddr: 169.254.241.0                 mcastport: 5405                 ttl: 1         } } quorum {         provider: corosync_votequorum         expected_votes: 2 } nodelist {         node {                 ring0_addr: 169.254.241.10                 nodeid: 1         }         node {                 ring0_addr: 169.254.241.20                 nodeid: 2         } } 1. ifdown interface (169.254.241.10) 2. start corosync (/usr/sbin/corosync -f) 3. ifup interface [Description] Corosync sigaborts if it starts before the interface it has to bind to is ready. On boot, if no interface in the bindnetaddr range is up/configured, corosync binds to lo (127.0.0.1). Once an applicable interface is up, corosync crashes with the following error message: corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: Assertion `sender_node != NULL' failed. Aborted (core dumped) The last log entries show that the interface is trying to join the cluster: Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug [TOTEM ] totemsrp.c:2089 entering OPERATIONAL state. Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members joined: 704573706 During the quorum calculation, the generated nodeid (704573706) for the node is being used instead of the nodeid specified in the configuration file (1), and the assert fails because the nodeid is not present in the member list. Corosync should use the correct nodeid and continue running after the interface is up, as shown in a fixed corosync boot: Dec 19 11:50:56 [4824] xenial-corosync corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:80) was formed. Members joined: 1 [Environment] Xenial 16.04.3 Packages: ii corosync 2.3.5-3ubuntu1 amd64 cluster engine daemon and utilities ii libcorosync-common4:amd64 2.3.5-3ubuntu1 amd64 cluster engine common library [Reproducer] Config: totem {         version: 2         member {                 memberaddr: 169.254.241.10         }         member {                 memberaddr: 169.254.241.20         }         transport: udpu         crypto_cipher: none         crypto_hash: none         nodeid: 1         interface {                 ringnumber: 0                 bindnetaddr: 169.254.241.0                 mcastport: 5405                 ttl: 1         } } quorum {         provider: corosync_votequorum         expected_votes: 2 } nodelist {         node {                 ring0_addr: 169.254.241.10                 nodeid: 1         }         node {                 ring0_addr: 169.254.241.20                 nodeid: 2         } } 1. ifdown interface (169.254.241.10) 2. start corosync (/usr/sbin/corosync -f) 3. ifup interface
2017-12-20 10:54:57 Victor Tapia nominated for series Ubuntu Xenial
2017-12-20 10:54:57 Victor Tapia nominated for series Ubuntu Trusty
2017-12-20 13:09:43 Eric Desrochers bug task added corosync (Ubuntu Xenial)
2017-12-20 13:09:48 Eric Desrochers bug task added corosync (Ubuntu Trusty)
2017-12-20 13:10:41 Eric Desrochers bug added subscriber STS Sponsors
2017-12-20 13:15:33 Eric Desrochers tags sts sts-sponsor-ddstreet
2017-12-20 13:53:47 Eric Desrochers corosync (Ubuntu): status New Fix Released
2017-12-20 13:53:58 Eric Desrochers corosync (Ubuntu Trusty): assignee Victor Tapia (vtapia)
2017-12-20 13:54:06 Eric Desrochers corosync (Ubuntu Xenial): assignee Victor Tapia (vtapia)
2017-12-20 13:54:09 Eric Desrochers corosync (Ubuntu Xenial): status New In Progress
2017-12-20 13:54:11 Eric Desrochers corosync (Ubuntu Trusty): status New In Progress
2017-12-20 13:54:13 Eric Desrochers corosync (Ubuntu Trusty): importance Undecided Medium
2017-12-20 13:54:15 Eric Desrochers corosync (Ubuntu Xenial): importance Undecided Medium
2017-12-20 15:34:53 Victor Tapia attachment added Trusty patch https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1739033/+attachment/5025215/+files/fix-lp1739033-trusty.debdiff
2017-12-20 15:35:23 Victor Tapia attachment added Xenial patch https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1739033/+attachment/5025216/+files/fix-lp1739033-xenial.debdiff
2017-12-20 16:04:07 Eric Desrochers bug added subscriber Eric Desrochers
2017-12-20 21:55:12 Dan Streetman description [Description] Corosync sigaborts if it starts before the interface it has to bind to is ready. On boot, if no interface in the bindnetaddr range is up/configured, corosync binds to lo (127.0.0.1). Once an applicable interface is up, corosync crashes with the following error message: corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: Assertion `sender_node != NULL' failed. Aborted (core dumped) The last log entries show that the interface is trying to join the cluster: Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug [TOTEM ] totemsrp.c:2089 entering OPERATIONAL state. Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members joined: 704573706 During the quorum calculation, the generated nodeid (704573706) for the node is being used instead of the nodeid specified in the configuration file (1), and the assert fails because the nodeid is not present in the member list. Corosync should use the correct nodeid and continue running after the interface is up, as shown in a fixed corosync boot: Dec 19 11:50:56 [4824] xenial-corosync corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:80) was formed. Members joined: 1 [Environment] Xenial 16.04.3 Packages: ii corosync 2.3.5-3ubuntu1 amd64 cluster engine daemon and utilities ii libcorosync-common4:amd64 2.3.5-3ubuntu1 amd64 cluster engine common library [Reproducer] Config: totem {         version: 2         member {                 memberaddr: 169.254.241.10         }         member {                 memberaddr: 169.254.241.20         }         transport: udpu         crypto_cipher: none         crypto_hash: none         nodeid: 1         interface {                 ringnumber: 0                 bindnetaddr: 169.254.241.0                 mcastport: 5405                 ttl: 1         } } quorum {         provider: corosync_votequorum         expected_votes: 2 } nodelist {         node {                 ring0_addr: 169.254.241.10                 nodeid: 1         }         node {                 ring0_addr: 169.254.241.20                 nodeid: 2         } } 1. ifdown interface (169.254.241.10) 2. start corosync (/usr/sbin/corosync -f) 3. ifup interface [Impact] Corosync sigaborts if it starts before the interface it has to bind to is ready. On boot, if no interface in the bindnetaddr range is up/configured, corosync binds to lo (127.0.0.1). Once an applicable interface is up, corosync crashes with the following error message: corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: Assertion `sender_node != NULL' failed. Aborted (core dumped) The last log entries show that the interface is trying to join the cluster: Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug [TOTEM ] totemsrp.c:2089 entering OPERATIONAL state. Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members joined: 704573706 During the quorum calculation, the generated nodeid (704573706) for the node is being used instead of the nodeid specified in the configuration file (1), and the assert fails because the nodeid is not present in the member list. Corosync should use the correct nodeid and continue running after the interface is up, as shown in a fixed corosync boot: Dec 19 11:50:56 [4824] xenial-corosync corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:80) was formed. Members joined: 1 [Environment] Xenial 16.04.3 Packages: ii corosync 2.3.5-3ubuntu1 amd64 cluster engine daemon and utilities ii libcorosync-common4:amd64 2.3.5-3ubuntu1 amd64 cluster engine common library [Test Case] Config: totem {         version: 2         member {                 memberaddr: 169.254.241.10         }         member {                 memberaddr: 169.254.241.20         }         transport: udpu         crypto_cipher: none         crypto_hash: none         nodeid: 1         interface {                 ringnumber: 0                 bindnetaddr: 169.254.241.0                 mcastport: 5405                 ttl: 1         } } quorum {         provider: corosync_votequorum         expected_votes: 2 } nodelist {         node {                 ring0_addr: 169.254.241.10                 nodeid: 1         }         node {                 ring0_addr: 169.254.241.20                 nodeid: 2         } } 1. ifdown interface (169.254.241.10) 2. start corosync (/usr/sbin/corosync -f) 3. ifup interface [Regression Potential] This patch affects corosync boot; the regression potential is for other problems during corosync startup and/or configuration parsing.
2017-12-21 09:01:03 John Lewis bug added subscriber John Lewis
2017-12-21 14:19:06 Eric Desrochers tags sts sts-sponsor-ddstreet sts sts-sponsor-ddstreet-done
2017-12-21 17:01:16 Brian Murray corosync (Ubuntu Xenial): status In Progress Incomplete
2017-12-21 17:01:21 Brian Murray bug added subscriber Brian Murray
2017-12-21 17:29:25 Dan Streetman corosync (Ubuntu Xenial): status Incomplete In Progress
2017-12-21 17:36:28 Eric Desrochers nominated for series Ubuntu Artful
2017-12-21 17:36:28 Eric Desrochers bug task added corosync (Ubuntu Artful)
2017-12-21 17:36:28 Eric Desrochers nominated for series Ubuntu Zesty
2017-12-21 17:36:28 Eric Desrochers bug task added corosync (Ubuntu Zesty)
2017-12-21 17:36:35 Eric Desrochers corosync (Ubuntu Zesty): status New Fix Released
2017-12-21 17:36:38 Eric Desrochers corosync (Ubuntu Artful): status New Fix Released
2017-12-21 17:40:18 Eric Desrochers description [Impact] Corosync sigaborts if it starts before the interface it has to bind to is ready. On boot, if no interface in the bindnetaddr range is up/configured, corosync binds to lo (127.0.0.1). Once an applicable interface is up, corosync crashes with the following error message: corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: Assertion `sender_node != NULL' failed. Aborted (core dumped) The last log entries show that the interface is trying to join the cluster: Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug [TOTEM ] totemsrp.c:2089 entering OPERATIONAL state. Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members joined: 704573706 During the quorum calculation, the generated nodeid (704573706) for the node is being used instead of the nodeid specified in the configuration file (1), and the assert fails because the nodeid is not present in the member list. Corosync should use the correct nodeid and continue running after the interface is up, as shown in a fixed corosync boot: Dec 19 11:50:56 [4824] xenial-corosync corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:80) was formed. Members joined: 1 [Environment] Xenial 16.04.3 Packages: ii corosync 2.3.5-3ubuntu1 amd64 cluster engine daemon and utilities ii libcorosync-common4:amd64 2.3.5-3ubuntu1 amd64 cluster engine common library [Test Case] Config: totem {         version: 2         member {                 memberaddr: 169.254.241.10         }         member {                 memberaddr: 169.254.241.20         }         transport: udpu         crypto_cipher: none         crypto_hash: none         nodeid: 1         interface {                 ringnumber: 0                 bindnetaddr: 169.254.241.0                 mcastport: 5405                 ttl: 1         } } quorum {         provider: corosync_votequorum         expected_votes: 2 } nodelist {         node {                 ring0_addr: 169.254.241.10                 nodeid: 1         }         node {                 ring0_addr: 169.254.241.20                 nodeid: 2         } } 1. ifdown interface (169.254.241.10) 2. start corosync (/usr/sbin/corosync -f) 3. ifup interface [Regression Potential] This patch affects corosync boot; the regression potential is for other problems during corosync startup and/or configuration parsing. [Impact] Corosync sigaborts if it starts before the interface it has to bind to is ready. On boot, if no interface in the bindnetaddr range is up/configured, corosync binds to lo (127.0.0.1). Once an applicable interface is up, corosync crashes with the following error message: corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: Assertion `sender_node != NULL' failed. Aborted (core dumped) The last log entries show that the interface is trying to join the cluster: Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug [TOTEM ] totemsrp.c:2089 entering OPERATIONAL state. Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members joined: 704573706 During the quorum calculation, the generated nodeid (704573706) for the node is being used instead of the nodeid specified in the configuration file (1), and the assert fails because the nodeid is not present in the member list. Corosync should use the correct nodeid and continue running after the interface is up, as shown in a fixed corosync boot: Dec 19 11:50:56 [4824] xenial-corosync corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:80) was formed. Members joined: 1 [Environment] Xenial 16.04.3 Packages: ii corosync 2.3.5-3ubuntu1 amd64 cluster engine daemon and utilities ii libcorosync-common4:amd64 2.3.5-3ubuntu1 amd64 cluster engine common library [Test Case] Config: totem {         version: 2         member {                 memberaddr: 169.254.241.10         }         member {                 memberaddr: 169.254.241.20         }         transport: udpu         crypto_cipher: none         crypto_hash: none         nodeid: 1         interface {                 ringnumber: 0                 bindnetaddr: 169.254.241.0                 mcastport: 5405                 ttl: 1         } } quorum {         provider: corosync_votequorum         expected_votes: 2 } nodelist {         node {                 ring0_addr: 169.254.241.10                 nodeid: 1         }         node {                 ring0_addr: 169.254.241.20                 nodeid: 2         } } 1. ifdown interface (169.254.241.10) 2. start corosync (/usr/sbin/corosync -f) 3. ifup interface [Regression Potential] This patch affects corosync boot; the regression potential is for other problems during corosync startup and/or configuration parsing. [Other info] # Upstream corosync commit : https://github.com/corosync/corosync/commit/aab55a004bb12ebe78db341dc56759dfe710c1b2 * Corosync upstream commit : # git describe aab55a004bb12ebe78db341dc56759dfe710c1b2 v2.3.5-45-gaab55a0 * Ubuntu # rmadison corosync corosync | 2.3.3-1ubuntu1 | trusty | source, amd64, arm64, armhf, i386, powerpc, ppc64el corosync | 2.3.3-1ubuntu3 | trusty-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el corosync | 2.3.5-3ubuntu1 | xenial | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x corosync | 2.4.2-3build1 | zesty | source, amd64, arm64, armhf, i386, ppc64el, s390x corosync | 2.4.2-3build1 | artful | source, amd64, arm64, armhf, i386, ppc64el, s390x corosync | 2.4.2-3build1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
2017-12-21 17:40:59 Eric Desrochers description [Impact] Corosync sigaborts if it starts before the interface it has to bind to is ready. On boot, if no interface in the bindnetaddr range is up/configured, corosync binds to lo (127.0.0.1). Once an applicable interface is up, corosync crashes with the following error message: corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: Assertion `sender_node != NULL' failed. Aborted (core dumped) The last log entries show that the interface is trying to join the cluster: Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug [TOTEM ] totemsrp.c:2089 entering OPERATIONAL state. Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members joined: 704573706 During the quorum calculation, the generated nodeid (704573706) for the node is being used instead of the nodeid specified in the configuration file (1), and the assert fails because the nodeid is not present in the member list. Corosync should use the correct nodeid and continue running after the interface is up, as shown in a fixed corosync boot: Dec 19 11:50:56 [4824] xenial-corosync corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:80) was formed. Members joined: 1 [Environment] Xenial 16.04.3 Packages: ii corosync 2.3.5-3ubuntu1 amd64 cluster engine daemon and utilities ii libcorosync-common4:amd64 2.3.5-3ubuntu1 amd64 cluster engine common library [Test Case] Config: totem {         version: 2         member {                 memberaddr: 169.254.241.10         }         member {                 memberaddr: 169.254.241.20         }         transport: udpu         crypto_cipher: none         crypto_hash: none         nodeid: 1         interface {                 ringnumber: 0                 bindnetaddr: 169.254.241.0                 mcastport: 5405                 ttl: 1         } } quorum {         provider: corosync_votequorum         expected_votes: 2 } nodelist {         node {                 ring0_addr: 169.254.241.10                 nodeid: 1         }         node {                 ring0_addr: 169.254.241.20                 nodeid: 2         } } 1. ifdown interface (169.254.241.10) 2. start corosync (/usr/sbin/corosync -f) 3. ifup interface [Regression Potential] This patch affects corosync boot; the regression potential is for other problems during corosync startup and/or configuration parsing. [Other info] # Upstream corosync commit : https://github.com/corosync/corosync/commit/aab55a004bb12ebe78db341dc56759dfe710c1b2 * Corosync upstream commit : # git describe aab55a004bb12ebe78db341dc56759dfe710c1b2 v2.3.5-45-gaab55a0 * Ubuntu # rmadison corosync corosync | 2.3.3-1ubuntu1 | trusty | source, amd64, arm64, armhf, i386, powerpc, ppc64el corosync | 2.3.3-1ubuntu3 | trusty-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el corosync | 2.3.5-3ubuntu1 | xenial | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x corosync | 2.4.2-3build1 | zesty | source, amd64, arm64, armhf, i386, ppc64el, s390x corosync | 2.4.2-3build1 | artful | source, amd64, arm64, armhf, i386, ppc64el, s390x corosync | 2.4.2-3build1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x [Impact] Corosync sigaborts if it starts before the interface it has to bind to is ready. On boot, if no interface in the bindnetaddr range is up/configured, corosync binds to lo (127.0.0.1). Once an applicable interface is up, corosync crashes with the following error message: corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: Assertion `sender_node != NULL' failed. Aborted (core dumped) The last log entries show that the interface is trying to join the cluster: Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug [TOTEM ] totemsrp.c:2089 entering OPERATIONAL state. Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members joined: 704573706 During the quorum calculation, the generated nodeid (704573706) for the node is being used instead of the nodeid specified in the configuration file (1), and the assert fails because the nodeid is not present in the member list. Corosync should use the correct nodeid and continue running after the interface is up, as shown in a fixed corosync boot: Dec 19 11:50:56 [4824] xenial-corosync corosync notice [TOTEM ] totemsrp.c:2095 A new membership (169.254.241.10:80) was formed. Members joined: 1 [Environment] Xenial 16.04.3 Packages: ii corosync 2.3.5-3ubuntu1 amd64 cluster engine daemon and utilities ii libcorosync-common4:amd64 2.3.5-3ubuntu1 amd64 cluster engine common library [Test Case] Config: totem {         version: 2         member {                 memberaddr: 169.254.241.10         }         member {                 memberaddr: 169.254.241.20         }         transport: udpu         crypto_cipher: none         crypto_hash: none         nodeid: 1         interface {                 ringnumber: 0                 bindnetaddr: 169.254.241.0                 mcastport: 5405                 ttl: 1         } } quorum {         provider: corosync_votequorum         expected_votes: 2 } nodelist {         node {                 ring0_addr: 169.254.241.10                 nodeid: 1         }         node {                 ring0_addr: 169.254.241.20                 nodeid: 2         } } 1. ifdown interface (169.254.241.10) 2. start corosync (/usr/sbin/corosync -f) 3. ifup interface [Regression Potential] This patch affects corosync boot; the regression potential is for other problems during corosync startup and/or configuration parsing. [Other info] # Upstream corosync commit : https://github.com/corosync/corosync/commit/aab55a004bb12ebe78db341dc56759dfe710c1b2 # git describe aab55a004bb12ebe78db341dc56759dfe710c1b2 v2.3.5-45-gaab55a0 # rmadison corosync corosync | 2.3.3-1ubuntu1 | trusty | source, amd64, arm64, armhf, i386, powerpc, ppc64el corosync | 2.3.3-1ubuntu3 | trusty-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el corosync | 2.3.5-3ubuntu1 | xenial | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x corosync | 2.4.2-3build1 | zesty | source, amd64, arm64, armhf, i386, ppc64el, s390x corosync | 2.4.2-3build1 | artful | source, amd64, arm64, armhf, i386, ppc64el, s390x corosync | 2.4.2-3build1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
2017-12-21 17:41:45 Brian Murray removed subscriber Brian Murray
2017-12-21 17:44:15 Brian Murray corosync (Ubuntu Xenial): status In Progress Fix Committed
2017-12-21 17:44:17 Brian Murray bug added subscriber Ubuntu Stable Release Updates Team
2017-12-21 17:44:19 Brian Murray bug added subscriber SRU Verification
2017-12-21 17:44:23 Brian Murray tags sts sts-sponsor-ddstreet-done sts sts-sponsor-ddstreet-done verification-needed verification-needed-xenial
2017-12-21 17:45:29 Brian Murray corosync (Ubuntu Trusty): status In Progress Fix Committed
2017-12-21 17:45:36 Brian Murray tags sts sts-sponsor-ddstreet-done verification-needed verification-needed-xenial sts sts-sponsor-ddstreet-done verification-needed verification-needed-trusty verification-needed-xenial
2017-12-22 13:25:30 Victor Tapia tags sts sts-sponsor-ddstreet-done verification-needed verification-needed-trusty verification-needed-xenial sts sts-sponsor-ddstreet-done verification-done verification-done-trusty verification-done-xenial
2018-01-02 11:05:15 Łukasz Zemczak removed subscriber Ubuntu Stable Release Updates Team
2018-01-02 11:05:13 Launchpad Janitor corosync (Ubuntu Xenial): status Fix Committed Fix Released
2018-01-02 11:18:31 Launchpad Janitor corosync (Ubuntu Trusty): status Fix Committed Fix Released
2018-01-03 06:49:15 Dominique Poulain bug added subscriber Dominique Poulain
2018-01-08 13:09:38 Janåke Rönnblom bug added subscriber Janåke Rönnblom