Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
BTW, Centos 5.3, NET-SNMP 5.3.2.2 –  Nathan Milford Aug 3 '09 at 21:08
    
Not an answer, but I would think it would depend greatly on the host generating the data to support 64-bit counters. Not sure if it would require any 64-bitness on the receiving end. –  Kevin Kuphal Aug 3 '09 at 21:09

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.