Description of problem:
RHEL 4 servers are correctly replying to the SNMP variable request
The rpm is net-snmp-5.1.2-11.EL4.10
But for some reason RHEL 5 boxes are not displaying that variable
The rpms are
On a RHEL 5 system
# snmpwalk -c public -v 2c localhost HOST-RESOURCES-MIB::hrProcessorLoad
On RHEL 4,
# snmpwalk -c public -v 2c localhost HOST-RESOURCES-MIB::hrProcessorLoad (IN RHEL4)
HOST-RESOURCES-MIB::hrProcessorLoad.768 = INTEGER: 59
Steps to Reproduce:
This issue does not seem to have been resolved by the errata provided for
bugzilla 232870. The bugzilla request was only for
HOST-RESOURCES-MIB::hrSWInstalled and the errata was to include that. This IT -
as per the customer request - is to include HOST-RESOURCES-MIB::hrProcessorLoad
which still does not work using the errata package.
How to reproduce.
Here are the modifications to /etc/snmpd/snmpd.conf used to grant access:
# sec.name source community
com2sec testUser default public
# groupName securityModel securityName
group testGroup v1 testUser
group testGroup v2c testUser
view all included .1 80
access testGroup "" any noauth exact all none none
- Restart snmpd
Test result against RHEL4 net-snmp server.
[root@dhcp6-237 ~]# rpm -q net-snmp
[root@dhcp6-237 ~]# snmpwalk -v1 -c public localhost
HOST-RESOURCES-MIB::hrProcessorLoad.768 = INTEGER: 2
Test result against RHEL5 net-snmp-server.
[root@dhcp6-102 ~]# rpm -q net-snmp
[root@dhcp6-102 ~]# snmpwalk -v1 -c public localhost
Since this works fine in RHEL4, something is missing from RHEL5 and need to be
Also found the below entry in net-snmp FAQ. /usr/share/doc/net-snmp-5.3.1/FAQ -
which says that processor statistics as a whole is available. So it seems to be
a problem with RHEL5.
What about multi-processor systems?
Sorry - the CPU statistics (both original percentages, and the
newer raw statistics) both refer to the system as a whole. There
is currently no way to access individual statistics for a particular
processor (except on Solaris systems - see below).
Note that although the Host Resources table includes a hrProcessorTable,
the current implementation suffers from two major flaws. Firstly, it
doesn't currently recognise the presence of multiple processors, and
simply assumes that all systems have precisely one CPU. Secondly, it
doesn't calculate the hrProcessorLoad value correctly, and either returns
a dummy value (based on the load average) or nothing at all.
As of net-snmp version 5.1, the Solaris operating system delivers some
information about multiple CPU's such as speed and type.
Other than that, to monitor a multi-processor system, you're currently
out of luck. We hope to address this in a future release of the agent.
But you've got the source, so you can always have a go yourself :-)
Created attachment 293894 [details]
sysreport of affected system
The problem is that net-snmp-5.0 (=RHEL4) shows average length of run queue
instead of proper hrProcessorLoad value (=the average, over the last minute, of
the percentage of time that this processor was not idle.) - the value you see on
RHEL4 is completely wrong.
In net-snmp-5.3 (=RHEL5) upstream decided, that it's better to report nothing
than report completely misleading value - you do not see hrProcessorLoad in the
Later on, upstream finally decided to implement it properly. The implementation
is not perfect - it periodically gathers CPU load and estimates the one-minute
average in a way, that the value is not available for first minute after snmpd
start. After the first minute, it shows correct values. I'll try to port it back
to RHEL 5.
Note to self: look at SVN commits 15026-15027, 15030, 15100 and maybe more.
Created attachment 294204 [details]
patch for RHEL5
this should do the trick
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.