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.
+++ This bug was initially created as a clone of Bug #1093157 +++
Description of problem: With bz#949617 as released with RHEL5.10, the CPU
socket information is now being reported to Satellite 5.6. However the socket
count using /proc/cpuinfo is not always correctly counted because the
"physical id" is not always a full ascending sequence.
Version-Release number of selected component (if applicable):
rhn-client-tools-0.4.20.1-6.el5
How reproducible:
Always but depends on the hardware
Steps to Reproduce:
1. Register a physical machine with multiple sockets, multi core RHEL5 machine
against 5.6 Satellite, i.e. a 2 socket with 2 cores per cpu
2. Run rhn-profile-sync
3. Check the System -> Details -> Hardware
Actual results:
Sockets: 4
Cores: 4
Expected results:
Sockets: 2
Cores: 4
Additional info:
The '__get_number_sockets() function from
rhn-client-tools-0.4.20.1/src/up2date_client/hardware.py tries different
methods to determine the sockets count:
1. /usr/bin/lscpu
2. /proc/cpuinfo
3. /usr/sbin/dmidecode
On RHEL5, lscpu does not exist and falls back to searching the highest
"physical id" in /proc/cpuinfo:
485 # Next try parsing /proc/cpuinfo
486 if os.access("/proc/cpuinfo", os.R_OK):
487 try:
488 lines = open("/proc/cpuinfo", 'r').readlines()
489 max_socket_index = -1
490 for line in lines:
491 if 'physical id' in line:
492 socket_index = int(line.split(':')[1].strip())
493 if socket_index > max_socket_index:
494 max_socket_index = socket_index
495 if max_socket_index > -1:
496 return 1 + max_socket_index
497 except:
498 pass
However this "physical id" is not fully sequential on all hardware. I.e. a
BL460G1 with two sockets and 2 cores / socket:
$ grep BL460 dmidecode
Product Name: ProLiant BL460c G1
$ grep "^physical id" proc/cpuinfo
physical id : 0
physical id : 3
physical id : 0
physical id : 3
This is not a bug on RHEL 7. See https://bugzilla.redhat.com/show_bug.cgi?id=1093157#c6
This was only a problem on RHEL 5 because lscpu was not included. On RHEL 7 lscpu is installed by util-linux (which you cannot uninstall). We use lscpu if it is present, so we will never try to parse /proc/cpuingo outselves on RHEL 7.