Bug 67773 - enterprises.ucdavis.memory OIDs broken, -l option ignored
enterprises.ucdavis.memory OIDs broken, -l option ignored
Status: CLOSED DUPLICATE of bug 67610
Product: Red Hat Linux
Classification: Retired
Component: ucd-snmp (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2002-07-01 17:22 EDT by Andrei Ivanov
Modified: 2015-03-04 20:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-07-02 17:28:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrei Ivanov 2002-07-01 17:22:13 EDT
Description of Problem:

  After upgrade from ucd-snmp-4.2.3- to ucd-snmp-4.2.5-7.72.0
  enterprises.ucdavis.memory.* OIDs return useless values.

  Also, it looks like -l command line option is ignored ("Connection from <IP>"
  messages are written to /var/log/messages, although "-l /dev/null"
  option was specified on the command line).

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


  I have the following one-liner as /etc/snmp/snmpd.conf:

    rocommunity <RO-string> <IP>

Actual Results:

  # snmpwalk <hostname> <RO-string> .
  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)

Expected Results:

  # snmpwalk <hostname> <RO-string> .
  enterprises.ucdavis.memory.memIndex.0 = 0
  enterprises.ucdavis.memory.memErrorName.0 = swap
  enterprises.ucdavis.memory.memTotalSwap.0 = 1052216
  enterprises.ucdavis.memory.memAvailSwap.0 = 1052216
  enterprises.ucdavis.memory.memTotalReal.0 = 2059024
  enterprises.ucdavis.memory.memAvailReal.0 = 1859056
  enterprises.ucdavis.memory.memTotalFree.0 = 2911272
  enterprises.ucdavis.memory.memMinimumSwap.0 = 16000
  enterprises.ucdavis.memory.memShared.0 = 0
  enterprises.ucdavis.memory.memBuffer.0 = 65120
  enterprises.ucdavis.memory.memCached.0 = 60972
  enterprises.ucdavis.memory.memSwapError.0 = 0
  enterprises.ucdavis.memory.memSwapErrorMsg.0 = 

Additional Information:
  # cat /proc/meminfo 
          total:    used:    free:  shared: buffers:  cached:
  Mem:  2108440576 204726272 1903714304        0 66682880 62435328
  Swap: 1077469184        0 1077469184
  MemTotal:      2059024 kB
  MemFree:       1859096 kB
  MemShared:           0 kB
  Buffers:         65120 kB
  Cached:          60972 kB
  SwapCached:          0 kB
  Active:         111176 kB
  Inact_dirty:     14916 kB
  Inact_clean:         0 kB
  Inact_target:   524288 kB
  HighTotal:     1179648 kB
  HighFree:      1093632 kB
  LowTotal:       879376 kB
  LowFree:        765464 kB
  SwapTotal:     1052216 kB
  SwapFree:      1052216 kB
  # uname -mrspv
  Linux 2.4.9-34enterprise #1 SMP Sat Jun 1 06:05:54 EDT 2002 i686 unknown
Comment 1 Kevin M. Myer 2002-07-02 17:28:13 EDT
See my note on #67610 regarding memory.  I believe this is a duplicate of that bug.

I noticed the logging issue too, as my logs were deluged with "Connection
from..." and "Last message repeated XX times".  I'm curious about the log options:

When I recompiled the SRPM to back out the memory patch, I noticed that the log
file was defined as /var/log/snmpd.log (which doesn't exist on my system).  Yet
the snmpd init file has command line options to apparently override that to
/dev/null.  But it also contains the -s switch to log to syslog as well.  So are
-l and -s mutually exclusive?  Running strace on a snmpd process shows it
writing to both the syslog fd (6) and /dev/null (3) so I'm wondering if snmpd is
not actually behaving the way it should have all along and it was a bug before
that permitted SNMP requests weren't being logged (or maybe snmpd wasn't
compiled with libwrap??)

Personally, I rather like the old behaviour of not having anything logged but
unauthorized addresses or bad community strings.  Maybe there's a way to change
the log facilities that can accomodate this since allows are logged at LOG_INFO
but denys are logged at LOG_WARNING.  Then again, those appear to be LIBWRAP
ifdef'ed so I'm going to have to see how ACL in snmpd.conf and stuff done
through hosts.{allow,deny} interact.
Comment 2 Phil Knirsch 2002-07-17 08:20:02 EDT

*** This bug has been marked as a duplicate of 67610 ***

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