NET-SNMP may be hitting a problem reporting partitions greater than 2TB

Question

We recently upgraded one of our MYSQL machines with an array that is 2.5TB.

After doing so OpenNMS stopped reporting information about our mysql data partition...

when I do a :

snmpwalk -v 1 localhost -c public .1.3.6.1.4.1.2021.9

I get this in the /var/log/messages

Aug  3 16:44:11 mysql6 snmpd[8789]: Connection from UDP: [127.0.0.1]:47333 
Aug  3 16:44:11 mysql6 snmpd[8789]: truncating signed value to 32 bits (10) 
Aug  3 16:44:11 mysql6 snmpd[8789]: truncating signed value to 32 bits (10) 

When I remove the partition from snmpd.conf it I got no notices... and the rest of the resource data is populated in OpenNMS.

From my googling it looks like a common problem but I couldn't find any solutions.

Anyone know of a work around?

Answer 1

This isn't really an answer, but it's too big for a comment.

• Linux 2.6.26-gentoo-r4 #10 SMP Sat Jan 17 22:38:48 EST 2009 i686 Intel(R) Celeron(R) CPU E1200 @ 1.60GHz GenuineIntel GNU/Linux
• NET-SNMP version: 5.4.2.1
• Logical Volume Size: 3.4TB

And I have no problems. I'm not sure if snmpd is compiled as 64bit though. I'd be happy to do any (non-intrusive) checks you like though.

Answer 2

I ran into this on a different platform. What I found out is what your log told you, it was returning a value that exceeded the signed 32-bit integer maximum. The particular SNMP daemon was returning negative numbers, which was how I figured out it was signed/unsigned Int problem. In my script I did the math to convert a signed integer to an unsigned integer, which will let me monitor this particular volume up to 4TB. At which point, I'm pretty much out of luck.

As for work-arounds... it doesn't sound like it'll let you get at the raw value, so you may have to write a script that'll execute when a specific OID is queried. This script will return the KB value of the volume, rather than the B value. Which should get you up to 16TB before it also hits the max.

In your snmpd.conf file, enter something kind of like this (I'm cribbing from some vmware notes, so the OID you use should be something else):

exec .1.3.6.1.4.1.6876.99999.2.0 sqlvolspace /usr/local/script/sqlvolspace /dev/mapper/volname

Then when you query that OID you'll get a value that fits inside a 32-bit integer. Of course, you'll have to write that script. It should return just a single integer.