I have seen this as well.  I finally determined it was caused by ATM interfaces.  Devmon does not give different components of an ATM circuit (the physical interface, the -atm layer, .0 sub interface, -aal5 layer) unique names.  So rrd was receiving data for 5 interfaces all with the same name.  As a temporary interface, I stopped monitoring the atm interfaces, but this is a bug.<br>
<br>Interface names:<br>ATM5/0/0<br>ATM5/0/0-atm layer<br>ATM5/0/0.0-atm subif<br>ATM5/0/0-aal5 layer<br>ATM5/0/0.0-aal5 layer<br><br>Devmon sees these all as: ATM5/0/0  because devmon templates (atleast for 6509's) are looking at ifName as the main identifier, which is not always unique.  Not sure on a solution yet.  MRTG uses ifIndex as it's unique key.<br>
<br>Robert<br><br><div class="gmail_quote">On Fri, Oct 31, 2008 at 3:15 AM, Buchan Milne <span dir="ltr"><<a href="mailto:bgmilne@staff.telkomsa.net">bgmilne@staff.telkomsa.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Friday 31 October 2008 05:51:42 Everett, Vernon wrote:<br>
> Hi all<br>
><br>
> Devmon was causing the hobbitd_rrd module to crash and burn.<br>
> Now this could be a bug, but it could also be a PEBKAC. I am hoping<br>
> somebody can assist either way.<br>
><br>
> I added a Cisco 2851 to Hobbit, using devmon.<br>
> Now here is the possible PEBKAC<br>
> Since Devmon doesn't have templates for the 2851, I used the template for<br>
> the Cisco 2811. (Network guru told me they are pretty much the same, except<br>
> for a few extra bells and whistles on the 2851.)<br>
><br>
> The data for the device started appearing in Hobbit, and all looked good.<br>
> Devmon even created the rrd files for the new Cisco device.<br>
><br>
> However, the hobbitd_rrd module started core dumping, and the Hobbit server<br>
> page started displaying red for hobbitd_rrd with the crash detected<br>
> message. See core data below.<br>
> Took the new Cisco device out of Hobbit, and cores stopped, and life was<br>
> good again.<br>
><br>
> Is there a significant enough difference between the 2851 and the 2811 to<br>
> cause this, or are we looking at a genuine bug?<br>
<br>
</div>Real bug. I see it on the temperature tests on a new IOS.<br>
<div><div></div><div class="Wj3C7c"><br>
> I am leaning towards a bug,<br>
> because even if the collected data was complete rubbish, should it cause<br>
> the module to core?<br>
><br>
> Regards<br>
>      Vernon<br>
><br>
> My Linux guy reckons this is the important stuff from the core.<br>
> uname -a<br>
> Linux las006 2.6.18-92.1.1.el5 #1 SMP Thu May 22 09:01:47 EDT 2008 x86_64<br>
> x86_64 x86_64 GNU/Linux cat /etc/redhat-release Red Hat Enterprise Linux<br>
> Client release 5.2 (Tikanga)<br>
><br>
> gdb -c core.8550 /usr/lib/hobbit/server/bin/hobbitd_rrd<br>
> GNU gdb Red Hat Linux (6.5-37.el5_2.1rh) Copyright (C) 2006 Free Software<br>
> Foundation, Inc. GDB is free software, covered by the GNU General Public<br>
> License, and you are welcome to change it and/or distribute copies of it<br>
> under certain conditions. Type "show copying" to see the conditions.<br>
> There is absolutely no warranty for GDB.  Type "show warranty" for details.<br>
> This GDB was configured as "x86_64-redhat-linux-gnu"...Using host<br>
> libthread_db library "/lib64/libthread_db.so.1".<br>
><br>
> Reading symbols from /usr/lib64/librrd.so.2...done.<br>
> Loaded symbols for /usr/lib64/librrd.so.2 Reading symbols from<br>
> /usr/lib64/libpng12.so.0...done. Loaded symbols for<br>
> /usr/lib64/libpng12.so.0 Reading symbols from /lib64/libpcre.so.0...done.<br>
> Loaded symbols for /lib64/libpcre.so.0<br>
> Reading symbols from /lib64/libc.so.6...done.<br>
> Loaded symbols for /lib64/libc.so.6<br>
> Reading symbols from /usr/lib64/libfreetype.so.6...done.<br>
> Loaded symbols for /usr/lib64/libfreetype.so.6 Reading symbols from<br>
> /usr/lib64/libz.so.1...done. Loaded symbols for /usr/lib64/libz.so.1<br>
> Reading symbols from /usr/lib64/libart_lgpl_2.so.2...done.<br>
> Loaded symbols for /usr/lib64/libart_lgpl_2.so.2 Reading symbols from<br>
> /lib64/libm.so.6...done. Loaded symbols for /lib64/libm.so.6<br>
> Reading symbols from /lib64/ld-linux-x86-64.so.2...done.<br>
> Loaded symbols for /lib64/ld-linux-x86-64.so.2 Core was generated by<br>
> `hobbitd_rrd --rrddir=/var/lib/hobbit/rrd --debug'. Program terminated with<br>
> signal 6, Aborted.<br>
> #0  0x0000003db7a30155 in raise () from /lib64/libc.so.6<br>
> (gdb) bt<br>
> #0  0x0000003db7a30155 in raise () from /lib64/libc.so.6<br>
> #1  0x0000003db7a31bf0 in abort () from /lib64/libc.so.6<br>
> #2  0x00000000004119f3 in sigsegv_handler (signum=<value optimized out>) at<br>
> sig.c:57 #3  <signal handler called><br>
> #4  0x0000003db7a77ac0 in strcat () from /lib64/libc.so.6<br>
> #5  0x000000000040462a in do_devmon_rrd (hostname=0x2ada311e2806<br>
> "PERIR205", testname=0x2ada311e280f "if_load", msg=<value optimized out>,<br>
> tstamp=<value optimized out>) at rrd/do_devmon.c:87<br>
> #6  0x000000000040b656 in update_rrd (hostname=0x2ada311e2806 "PERIR205",<br>
> testname=0x2ada311e280f "if_load", msg=0x2ada311e2842 "status<br>
> PERIR205.if_load green Fri Oct 31 10:31:39 2008", tstamp=1225416699,<br>
> sender=<value optimized out>, ldef=0xfeffffffffffff00) at do_rrd.c:372 #7<br>
> 0x000000000040261d in main (argc=<value optimized out>,<br>
> argv=0x7fff7a088318) at hobbitd_rrd.c:153 (gdb)<br>
<br>
<br>
</div></div>Could you show the Devmon RRD section of the message for the if_load test on<br>
the PERIR205 host? I can confirm the cause, and maybe offer a workaround.<br>
<br>
I am actually (constantly) reproducing the issue on my workstation against the<br>
new IOS that can trigger this, I have a workaround in place in production, and<br>
was hoping to get around to fixing this next week.<br>
<br>
Regards,<br>
Buchan<br>
<br>
<br>
To unsubscribe from the hobbit list, send an e-mail to<br>
<a href="mailto:hobbit-unsubscribe@hswn.dk">hobbit-unsubscribe@hswn.dk</a><br>
<br>
<br>
</blockquote></div><br>