Hello,

don't know if this is places right here or if it is too kernel specific.

I have a funny problem with ucd-snmpd 4.2.4 rnuning here:

enterprises.ucdavis.memory.memIndex.0 = 0
enterprises.ucdavis.memory.memErrorName.0 = swap
enterprises.ucdavis.memory.memTotalSwap.0 = 66500
enterprises.ucdavis.memory.memAvailSwap.0 = 43916
enterprises.ucdavis.memory.memTotalReal.0 = 46848
enterprises.ucdavis.memory.memAvailReal.0 = 3840
enterprises.ucdavis.memory.memTotalSwapTXT.0 = -1
enterprises.ucdavis.memory.memAvailSwapTXT.0 = -1
enterprises.ucdavis.memory.memTotalRealTXT.0 = -1
enterprises.ucdavis.memory.memAvailRealTXT.0 = -1
enterprises.ucdavis.memory.memTotalFree.0 = 3840
enterprises.ucdavis.memory.memMinimumSwap.0 = 16000
enterprises.ucdavis.memory.memShared.0 = 0
enterprises.ucdavis.memory.memSwapError.0 = 1
enterprises.ucdavis.memory.memSwapErrorMsg.0 = Running out of swap space (0)

As you can see, memTotalFree is the same as memAvailReal. I think it should be
memTotalFree should be the sum of memAvailReal and memAvailSwap.

After reading the sources (documentation is too detailed :), i found the source of the value in ucd-snmp-4.2.4/agent/mibgroup/ucd-snmp/memory_netbsd1.c, it
is taken from vmtotal.t_free. So this value is reported by the uvm subsystem.
What should t_free deliver? The physical available RAM or the total available
memory? The comment is a bit weak (at least for me as non uvm-guru :)

        int32_t t_free;         /* free memory pages */

This sounds like it doesn't even need to be in KB, as it seems to be.

My question here is: is there a bug in the kernel reporting the incorrect
value, or is it a bug in ucd-snmp?

And to prevent the questions: i tried net-snmp 5.0.6 or so, but there i don't
find enterprises.ucdavis at all in snmpwalk. But i didn't had a closer look.

Any hints welcome.

...Michael

-- 
http://www.unixiron.org/    Home Powered by: (Net|Open|Free)BSD IRIX NonStop-UX
Solaris AIX HP-UX Tru64 MUNIX Ultrix VMS SINIX Dolphin_Unix OpenStep MacOS A/UX