Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Cause
1. configure two rings
2. run an application that registers with the same group on each node
3. corosync-cpgtool
Consequence
% corosync-cpgtool
Group Name PID Node ID
aGroup\x00
4774 990357696 (10.0.0.910.0.0.9)
4694 1040689344 (10.0.0.110.0.0.1)
4682 1023912128 (10.0.0.210.0.0.2)
-> Duplicated ring IP
Fix
Fix cfg service to correctly return two interfaces instead of doubled one interface.
Result
% corosync-cpgtool
Group Name PID Node ID
aGroup\x00
4774 990357696 (192.168.7.59 10.0.0.9)
4694 1040689344 (192.168.7.61 10.0.0.1)
4682 1023912128 (192.168.7.62 10.0.0.2)
Description of problem:
The output of corosync-cpgtool reports the expanded 'Node ID' column with a concatenated repeat of one of the interfaces in a dual ring. An outstanding enhancement would be to include both interfaces in a dual ring with a space separating the two fields.
Version-Release number of selected component (if applicable):
corosync 3.0
How reproducible:
trivial
Steps to Reproduce:
1. configure two rings
2. run an application that registers with the same group on each node
3. corosync-cpgtool
Actual results:
% corosync-cpgtool
Group Name PID Node ID
aGroup\x00
4774 990357696 (10.0.0.910.0.0.9)
4694 1040689344 (10.0.0.110.0.0.1)
4682 1023912128 (10.0.0.210.0.0.2)
Expected results:
% corosync-cpgtool
Group Name PID Node ID
aGroup\x00
4774 990357696 (192.168.7.59 10.0.0.9)
4694 1040689344 (192.168.7.61 10.0.0.1)
4682 1023912128 (192.168.7.62 10.0.0.2)
Additional info:
When two rings are enabled with different IP subnets the output status
provides unexpected results for the node IP identifiers. It appears
that under the two ring situation one of the rings is arbitrarily
selected and used to provide the IP address data, concatenated and
duplicated.
Perhaps there is a simple fix to avoiding the concatenation
tools/corosync-cpgtool.c -- about line 84 adding a space ater the
print of the string (or fancier to consider 1 versus 2 rings)
inet_ntop(ss->ss_family, saddr, buf, sizeof(buf));
< fprintf(f, "%s", buf);
> fprintf(f, "%s ", buf);
In the example case above (based on the multiple ip addresses of the
source nodes) would it be more helpful to accurately represent each of
the node addresses? I did not find right away why a single IP
address was selected of the two which represent each node.
In this case the above expected results would provide a very powerful diagnostic to verify both rings and endpoints! It would be nice when specifying the delimiter field to get a similar output with new delimiters.
What is particularly interesting about the above output is that
provides a perspective across multiple nodes (given an application
utilizing a group).
Perhaps an additional diagnostic enhancement is providing the
multiple node perspective from the cfgtool which as seen below only
shows the current node, but none of the remaining members. An 'all nodes' query would be great to show all the endpoints across the system.
% corosync-cfgtool -s
Printing ring status.
Local node ID 1023912128
RING ID 0
id = 192.168.7.61
status = ring 0 active with no faults
RING ID 1
id = 10.0.0.1
status = ring 1 active with no faults
Thanks for an overall great start to some very helpful command line tools. I appreciate the consideration of this fine tuning!
Created attachment 486843[details]
Proposed patch for MAIN problem
Zero element array behavior is very different from normal array or
pointer. This behavior is root of problem in not returning correctly
filled array of addresses. This appeared only in rrp mode, where more
then one address is returned.
All memcpy's are now correctly converted to copy pointer to char.
Steve,
I'm pretty sure we should split bug to two parts:
- this part, which fixes root problem and we have patch, so it can be in 6.1. Simply because cfg contains problem, even if we ignore fact that rr mode is not supported
- second part, which is "put cpg groups informations to objdb". This is Fedora material (maybe even not in 6.3)
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause
1. configure two rings
2. run an application that registers with the same group on each node
3. corosync-cpgtool
Consequence
% corosync-cpgtool
Group Name PID Node ID
aGroup\x00
4774 990357696 (10.0.0.910.0.0.9)
4694 1040689344 (10.0.0.110.0.0.1)
4682 1023912128 (10.0.0.210.0.0.2)
-> Duplicated ring IP
Fix
Fix cfg service to correctly return two interfaces instead of doubled one interface.
Result
% corosync-cpgtool
Group Name PID Node ID
aGroup\x00
4774 990357696 (192.168.7.59 10.0.0.9)
4694 1040689344 (192.168.7.61 10.0.0.1)
4682 1023912128 (192.168.7.62 10.0.0.2)
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2011-1515.html
Description of problem: The output of corosync-cpgtool reports the expanded 'Node ID' column with a concatenated repeat of one of the interfaces in a dual ring. An outstanding enhancement would be to include both interfaces in a dual ring with a space separating the two fields. Version-Release number of selected component (if applicable): corosync 3.0 How reproducible: trivial Steps to Reproduce: 1. configure two rings 2. run an application that registers with the same group on each node 3. corosync-cpgtool Actual results: % corosync-cpgtool Group Name PID Node ID aGroup\x00 4774 990357696 (10.0.0.910.0.0.9) 4694 1040689344 (10.0.0.110.0.0.1) 4682 1023912128 (10.0.0.210.0.0.2) Expected results: % corosync-cpgtool Group Name PID Node ID aGroup\x00 4774 990357696 (192.168.7.59 10.0.0.9) 4694 1040689344 (192.168.7.61 10.0.0.1) 4682 1023912128 (192.168.7.62 10.0.0.2) Additional info: When two rings are enabled with different IP subnets the output status provides unexpected results for the node IP identifiers. It appears that under the two ring situation one of the rings is arbitrarily selected and used to provide the IP address data, concatenated and duplicated. Perhaps there is a simple fix to avoiding the concatenation tools/corosync-cpgtool.c -- about line 84 adding a space ater the print of the string (or fancier to consider 1 versus 2 rings) inet_ntop(ss->ss_family, saddr, buf, sizeof(buf)); < fprintf(f, "%s", buf); > fprintf(f, "%s ", buf); In the example case above (based on the multiple ip addresses of the source nodes) would it be more helpful to accurately represent each of the node addresses? I did not find right away why a single IP address was selected of the two which represent each node. In this case the above expected results would provide a very powerful diagnostic to verify both rings and endpoints! It would be nice when specifying the delimiter field to get a similar output with new delimiters. What is particularly interesting about the above output is that provides a perspective across multiple nodes (given an application utilizing a group). Perhaps an additional diagnostic enhancement is providing the multiple node perspective from the cfgtool which as seen below only shows the current node, but none of the remaining members. An 'all nodes' query would be great to show all the endpoints across the system. % corosync-cfgtool -s Printing ring status. Local node ID 1023912128 RING ID 0 id = 192.168.7.61 status = ring 0 active with no faults RING ID 1 id = 10.0.0.1 status = ring 1 active with no faults Thanks for an overall great start to some very helpful command line tools. I appreciate the consideration of this fine tuning!