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
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.
*** This bug has been marked as a duplicate of 67610 ***