Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 119688 - net-snmp does not support new meminfo format
Summary: net-snmp does not support new meminfo format
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: net-snmp
Version: 2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Radek Vokál
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC2Target FC3Target FC4Target
TreeView+ depends on / blocked
 
Reported: 2004-04-01 15:09 UTC by Hrunting Johnson
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-01-13 12:54:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
patch for memory and cpu gathering (deleted)
2004-04-01 15:10 UTC, Hrunting Johnson
no flags Details | Diff
corrected patch (deleted)
2004-04-01 15:29 UTC, Hrunting Johnson
no flags Details | Diff

Description Hrunting Johnson 2004-04-01 15:09:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
Gecko/20040206 Firefox/0.8

Description of problem:
net-snmp is still querying memory (and CPU statistics) based on old
2.4-style file formats in /proc/stat and /proc/meminfo.  The data
gathering routines need to be updated for the new file formats.

See the attached patch.

The only questionable choice I made was to include iowait with idle
cpu rather than breaking it out into its own field.  Net-SNMP has
support for returning iowait, so it could theoretically return it.  I
just wasn't quite sure how to do it properly.  This minimal patch at
least returns data that can accurately be compared with data that was
previously returned. 

Version-Release number of selected component (if applicable):
5.1-11.1

How reproducible:
Always

Steps to Reproduce:
1. start snmp
2. query memory or systemStats tables
3.
    

Actual Results:  memory is just completely wrong.  systemStats cpu
counters don't give the complete CPU information.

Expected Results:  memory is right.  systemStats at least give ALL
counters, even if they are summed in with others.

Additional info:

Comment 1 Hrunting Johnson 2004-04-01 15:10:56 UTC
Created attachment 99038 [details]
patch for memory and cpu gathering

This patch affects the memory and cpu gathering stats.	It also includes
support for gathering very large memory statistics.  No guarantees for
accuracy.

Comment 2 Hrunting Johnson 2004-04-01 15:29:02 UTC
Created attachment 99039 [details]
corrected patch

The prior patch was still dividing the memory total by 1024 even though it was
already reading a value in kB.	This patch removes the 1024 line.

Comment 3 Phil Knirsch 2004-04-08 15:26:03 UTC
The patch seems to be a little buggy:

You define static unsigned row[MAX_ROW + 1] and sometimes use it as a
char (as expected), other times you assigne a long value to it (row[i]
= 0xffffffff).

I'll take a look at it over the next few days, but i general i agree
that the memory reporting needs to be adapted to the latest kernel.

Read ya, Phil

Comment 4 Hrunting Johnson 2004-04-08 15:52:55 UTC
Yeah, it's rough and dirty.  It definitely works though (been using it
in production for over a week now).  Feel free to correct the messy parts.

Comment 5 Paul Lindner 2004-08-28 13:41:14 UTC
Any news on this?  I'd love to get rid of all these lines in /var/log/messages

Aug 28 06:30:05 10.0.10.3 snmpd[30425]: No page line in /proc/stat
Aug 28 06:30:05 10.0.10.3 snmpd[30425]: No swap line in /proc/stat

which I assume is the same problem here..

Comment 6 Radek Vokál 2004-10-14 12:04:21 UTC
This problem was fixed in upstream and might not have appear in
net-snmp-5.1.2 version. Paul, which version are you using now? 


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