Bug 67610 - snmpd does not provide memory information
Summary: snmpd does not provide memory information
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ucd-snmp (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact: Brock Organ
: 67773 69137 71385 73809 77701 82249 89175 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-06-28 08:57 UTC by Lukasz Engel
Modified: 2015-03-05 01:10 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-09-24 20:51:35 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2002:159 normal SHIPPED_LIVE Updated ucd-snmp packages available 2003-09-24 04:00:00 UTC
Red Hat Product Errata RHEA-2003:210 normal SHIPPED_LIVE Updated ucd-snmp packages available 2003-12-19 05:00:00 UTC

Description Lukasz Engel 2002-06-28 08:57:55 UTC
Description of Problem: 
After upgrading to last version (4.2.5) of ucd-snmp on several RH 7.3, 7.2 and 
7.0 boxes (all running kernel 2.4.x) snmpd does not provide memory usage 
Version-Release number of selected component (if applicable): 
ucd-snmp-4.2.5-7.73.0 (RH 7.3, kernel 2.4.18-4 (from dist.)) 
ucd-snmp-4.2.5-7.72.0 (RH 7.2, kernel 2.4.17) 
ucd-snmp-4.2.5-7.70.0 (RH 7.0, kernel 2.4.17) 
Steps to Reproduce: 
1. Install new ucd-snmp package 
2. query (snmpwalk) enterprises.ucdavis.memory SNMP tree branch 
3. compare results with /proc/meminfo 
Actual Results: 
$ snmpwalk placek mrtg enterprises.ucdavis.memory 
enterprises.ucdavis.memory.memIndex.0 = 0 
enterprises.ucdavis.memory.memErrorName.0 = swap 
enterprises.ucdavis.memory.memTotalSwap.0 = -1 
enterprises.ucdavis.memory.memAvailSwap.0 = -1 
enterprises.ucdavis.memory.memTotalReal.0 = -1 
enterprises.ucdavis.memory.memAvailReal.0 = -1 
enterprises.ucdavis.memory.memTotalFree.0 = -2 
enterprises.ucdavis.memory.memMinimumSwap.0 = 16000 
enterprises.ucdavis.memory.memShared.0 = -1 
enterprises.ucdavis.memory.memBuffer.0 = -1 
enterprises.ucdavis.memory.memCached.0 = -1 
enterprises.ucdavis.memory.memSwapError.0 = 1 
enterprises.ucdavis.memory.memSwapErrorMsg.0 = Running out of swap space (-1) 
placek$ cat /proc/meminfo 
        total:    used:    free:  shared: buffers:  cached: 
Mem:  1055617024 1028292608 27324416        0 193048576 601260032 
Swap: 2154938368 11403264 2143535104 
MemTotal:      1030876 kB 
MemFree:         26684 kB 
MemShared:           0 kB 
Buffers:        188524 kB 
Cached:         586660 kB 
SwapCached:        508 kB 
Active:         393048 kB 
Inact_dirty:    346076 kB 
Inact_clean:     50008 kB 
Inact_target:   157824 kB 
HighTotal:      130880 kB 
HighFree:         2208 kB 
LowTotal:       899996 kB 
LowFree:         24476 kB 
SwapTotal:     2104432 kB 
SwapFree:      2093296 kB 
Committed_AS:    44132 kB 
Expected Results: 
snmpwalk should receive information as shown in /proc/meminfo

Comment 1 Kevin M. Myer 2002-07-01 15:27:04 UTC
I can confirm this on several additional boxes running 7.2 and 7.3.  The upgrade
breaks memory usage.  Ugh - first the disk directive blew up, then was fixed. 
Now the memory directive blew up....

Comment 2 Kevin M. Myer 2002-07-02 20:48:57 UTC

It looks like this is a bug in agent/mibgroup/ucd-snmp/memory.c

I downgraded just that file to the one from 4.2.4 and things work.

The patch that appears to have caused the problem was supposed to be a fix for
values that were greater than a 32bit unsigned integer (either that or the fix
to handle 2^32-1 that apparently was added to this patch a little later, judging
from the CVS log):

Its patch 548663.


Comment 3 Mario Mikocevic 2002-07-03 11:31:12 UTC

this is _the_ patch that worked for me ->

# cat /usr/src/redhat/SOURCES/ucd-snmp-4.2.5-memory.patch 
--- ucd-snmp-4.2.5/agent/mibgroup/ucd-snmp/memory.c.orig        Wed Jul  3
13:15:04 2002
+++ ucd-snmp-4.2.5/agent/mibgroup/ucd-snmp/memory.c     Wed Jul  3 13:18:47 2002
@@ -272,9 +272,9 @@
     for (i=0; i < MAX_ROW && *p; i++) {                /* loop over rows */
        while(*p && !isdigit(*p)) p++;          /* skip chars until a digit */
        for (j=0; j < MAX_COL && *p; j++) {     /* scanf column-by-column */
-           l = sscanf(p, "%u%n", &m, &k);
+           l = sscanf(p, "%lu%n", &m, &k);
            m /= 1024;
-           if (4294967295 > m) {
+           if (m > 4294967295) {
                *(row[i] + j) = 4294967295;
            } else {
                *(row[i] + j) = (unsigned) m;

I reconstructed it from URL above, thanks guys, memory is showing
fine now ...
I added it into .spec file as Patch10 and rebuilded package.
Spec diff _is_ also available on request.


Comment 4 Darren Gamble 2002-07-10 15:47:30 UTC
Could we get a Rawhide SRPM/RPM with this patch?

Please and Thank You. =)

Comment 5 Phil Knirsch 2002-07-17 12:19:58 UTC
*** Bug 67773 has been marked as a duplicate of this bug. ***

Comment 6 Phil Knirsch 2002-07-17 13:43:39 UTC
Errata will follow sometime next week with this patch.

Read ya, Phil

Comment 7 Phil Knirsch 2002-07-18 07:38:59 UTC
*** Bug 69137 has been marked as a duplicate of this bug. ***

Comment 8 Phil Knirsch 2002-07-30 09:44:36 UTC
OK, took a couple of days longer, but a fixed ucd-snmp package is being built at
the moment and the errata process has been initiated.

The final errata should appear sometime the end of this week or around next (if
all goes well ;-).

Read ya, Phil

Comment 9 Phil Knirsch 2002-08-13 07:23:29 UTC
*** Bug 71385 has been marked as a duplicate of this bug. ***

Comment 10 Tim Korsrud 2002-09-30 21:38:48 UTC
Will this be released as errata soon?

Comment 11 Phil Knirsch 2002-10-04 12:14:53 UTC
*** Bug 73809 has been marked as a duplicate of this bug. ***

Comment 12 Ken 2002-10-04 18:14:57 UTC
Is there any update in regards to this bug, besides the duplicate bug reports? 
There is a fix, but there has yet to be an Errata released.

Comment 13 Phil Knirsch 2002-10-04 18:27:58 UTC
I've bugged our QA department already, it's still in QA here (QA was swamped
with work due to our latest Red Hat LInux 8.0 release).

I won't make any promised anymore, but it's due to be released real soon now(tm).

Sorry for the inconvenience and thanks for your patience.

Read ya, Phil

Comment 14 poueck 2002-11-12 13:47:41 UTC
*** Bug 77701 has been marked as a duplicate of this bug. ***

Comment 15 Jim 2003-01-17 17:40:31 UTC
It has now been nearly six months since this bug was recognized and an errata 
was promised.  According to RH policy, 7.3 is still a fully supported version 
and this is becoming somewhat ridiculous.  When can we expect an errata?  Can 
we, at the _very_ least, have an SRPM for this?  I realize I can patch it 
myself, but this is not why I am paying RH for their Enterprise RHN service.  
Can someone please post an update?  Thanks.  Jim

Comment 16 Ken 2003-01-17 19:11:57 UTC
I would like to 2nd that argument.  What is going on?   RedHat still supports
the 7.3 release, which comes with ucd-snmp.  If its too much of a burden for QA
to verify the ucd-snmp patches, then at least backport the net-snmp program from

Either way, there is a supported OS that is not getting supported.

Comment 17 Phil Knirsch 2003-01-20 15:21:33 UTC
*** Bug 82249 has been marked as a duplicate of this bug. ***

Comment 18 Phil Knirsch 2003-01-20 15:29:47 UTC
I know this must sound like a lame excuse, but i'm still bugging our QA
departement to finish up and release this errata.

I'll see if i can force it to be released soon.

In the meantime i'll provide the source and binary rpms on my people.redhat.com


Again, i can only apologize for this unexcusable delay, but as much as i'd like
to i can't force the QA folks to work on it.

Read ya, Phil

Comment 19 Peter Bates 2003-03-14 13:00:06 UTC
Did this pending errata ever get released for 7.3? It seems to be now two 
months since anyone complained at it not appearing... or are we supposed to 
have all moved to 8.0 by now? 

Comment 20 Phil Knirsch 2003-05-02 10:08:52 UTC
*** Bug 89175 has been marked as a duplicate of this bug. ***

Comment 21 Phil Knirsch 2003-09-24 20:51:35 UTC
An errata 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 the 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.


Comment 22 Kevin M. Myer 2003-09-25 11:29:58 UTC
Talk about speedy resolution - 1 year and nearly three months after the bug was
opened, you finally release an errata that claims to fix it.  Off to verify
those claims... (and you should've just waited until Jan 1, 2004, since 7.3
isn't supported anymore at that point - but thats another bone I have to pick...)

This is getting as bad as the time cycle for big UNIX vendors to release
patches.....I guess Red Hat has finally "arrived".

Note You need to log in before you can comment on or make changes to this bug.