This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 119688 - net-snmp does not support new meminfo format
net-snmp does not support new meminfo format
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: net-snmp (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
:
Depends On:
Blocks: FC2Target FC3Target FC4Target
  Show dependency treegraph
 
Reported: 2004-04-01 10:09 EST by Hrunting Johnson
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-13 07:54:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Hrunting Johnson 2004-04-01 10:09:18 EST
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 10:10:56 EST
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 10:29:02 EST
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 11:26:03 EDT
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 11:52:55 EDT
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 09:41:14 EDT
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 08:04:21 EDT
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.