Bug 67773

Summary: enterprises.ucdavis.memory OIDs broken, -l option ignored
Product: [Retired] Red Hat Linux Reporter: Andrei Ivanov <iva>
Component: ucd-snmpAssignee: Phil Knirsch <pknirsch>
Status: CLOSED DUPLICATE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-07-02 21:28:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andrei Ivanov 2002-07-01 21:22:13 UTC
Description of Problem:

  After upgrade from ucd-snmp-4.2.3-1.7.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):

  ucd-snmp-4.2.5-7.72.0.i386.rpm

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

    rocommunity <RO-string> <IP>

Actual Results:

  # snmpwalk <hostname> <RO-string> .1.3.6.1.4.1.2021.4
  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> .1.3.6.1.4.1.2021.4
  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 21:28:13 UTC
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 12:20:02 UTC

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