Bug 119688 - net-snmp does not support new meminfo format
Summary: net-snmp does not support new meminfo format
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: net-snmp (Show other bugs)
(Show other bugs)
Version: 2
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Radek Vokal
QA Contact:
URL:
Whiteboard:
Keywords:
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:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-13 12:54:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for memory and cpu gathering (5.28 KB, patch)
2004-04-01 15:10 UTC, Hrunting Johnson
no flags Details | Diff
corrected patch (5.28 KB, patch)
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 Vokal 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.