devmon-support

Re: [Devmon] [hobbit] Re: Devmon causing core dumps

[Buchan M. <bg...@st...>]

On Monday 03 November 2008 09:46:42 Buchan Milne wrote:
> On Friday 31 October 2008 19:55:35 Robert Holden wrote:
> > When I run snmpwalk on my interfaces I get the following:
> > (I believe that the devmon template is using this ... notice that they
> > are all the same.
>
> Depending on the SNMP implementation (and may differ on different IOS
> versions).
>
> > A transform won't help)
> > IF-MIB::ifName.70 = STRING: AT5/0/0
> > IF-MIB::ifName.71 = STRING: AT5/0/0
> > IF-MIB::ifName.72 = STRING: AT5/0/0
> > IF-MIB::ifName.73 = STRING: AT5/0/0
> > IF-MIB::ifName.74 = STRING: AT5/0/0
>
> One of our 7613's has:
>
> IF-MIB::ifName.1 = STRING: Gi3/1
> [...]
> IF-MIB::ifName.128 = STRING: ATM10/1/0.0-atm subif
> IF-MIB::ifName.129 = STRING: ATM10/1/0-aal5 layer
> IF-MIB::ifName.130 = STRING: ATM10/1/0.0-aal5 layer
> IF-MIB::ifName.131 = STRING: VLAN-1
>
> > (This could be used, but you would end up w/ very long names.  G0/0 would
> > become GigabitEthernet0/0)
> > IF-MIB::ifDescr.70 = STRING: ATM5/0/0
> > IF-MIB::ifDescr.71 = STRING: ATM5/0/0-atm layer
> > IF-MIB::ifDescr.72 = STRING: ATM5/0/0.0-atm subif
> > IF-MIB::ifDescr.73 = STRING: ATM5/0/0-aal5 layer
> > IF-MIB::ifDescr.74 = STRING: ATM5/0/0.0-aal5 layer
>
> On the same device as above:
>
> IF-MIB::ifDescr.1 = STRING: GigabitEthernet3/1
> [...]
> IF-MIB::ifDescr.128 = STRING: ATM10/1/0.0-atm subif
> IF-MIB::ifDescr.129 = STRING: ATM10/1/0-aal5 layer
> IF-MIB::ifDescr.130 = STRING: ATM10/1/0.0-aal5 layer
> IF-MIB::ifDescr.131 = STRING: unrouted VLAN 1
>
> > (This may be helpful ... somehow ignore all type 37 and type 49, and sub
> > interface 0 ??)
> > IF-MIB::ifType.70 = INTEGER: sonet(39)
> > IF-MIB::ifType.71 = INTEGER: atm(37)
> > IF-MIB::ifType.72 = INTEGER: atmSubInterface(134)
> > IF-MIB::ifType.73 = INTEGER: aal5(49)
> > IF-MIB::ifType.74 = INTEGER: aal5(49)
>
> But, in my case, I want to graph:
> IF-MIB::ifName.103 = STRING: ATM10/1/0.1-aal5 layer
>
> (it is the only interface which shows the correct traffic)
>
> > I will open a bug if you like.  Is the issue that originated this thread
> > the same as the one I am experiencing?
>
> Well, there are two aspects to the bug:
>
> 1)Devmon should strip invalid characters out of interface names for the RRD
> data sent with the status message.
>
> 2)The Hobbit RRD collector module for devmon should not segfault if data is
> not in the format:
>
> <name_without_spaces> value[:value[:value]]

I fixed this one last night. You can either grab the new do_devmon.c, and run 
'make' again, and copy the hobbitd_rrd over the previous binary, or you can 
grab the new complete patch for a build from scratch:

http://devmon.svn.sourceforge.net/viewvc/devmon?view=rev&revision=90

(at present, viewvc seems to be a bit bust on sourceforge, but these should be 
the URLs to the current versions of the files when it is working:
http://devmon.svn.sourceforge.net/viewvc/devmon/trunk/extras/do_devmon.c
http://devmon.svn.sourceforge.net/viewvc/devmon/trunk/extras/hobbit-4.2.0-
devmon-complete.patch
)

I will update my Hobbit packages with this once I've upgraded my production 
Hobbit box (but the SRPM is in Mandriva cooker already).

Regards,
Buchan

Re: [Devmon] [hobbit] Re: Devmon causing core dumps

[mario a. <row...@gm...>]

Hi,

Bunchan.

I'm getting hobbitd_rrd crash. I'm running 4.2.3 RC1 with your do_devmon.c
revision 154.
I figured that the core file are repeating for the same equipments. cisco
6513 and cisco 4507 for if_load.

THis could be because of the number of interfaces? What do you think?

Thanks in advance,

Mario.

Cisco 4507:

Alarming on (Gi1/1,Gi1/2,Gi2/1,Gi2/2,Gi3/1,Gi3/2,Gi3/3,Gi3/4,Gi3/5,Gi3/6,Gi3/7)
Alarming on (Gi3/8,Gi3/9,Gi3/10,Gi3/11,Gi3/12,Gi3/13,Gi3/14,Gi3/15)
Alarming on (Gi3/16,Gi3/17,Gi3/18,Gi3/19,Gi3/20,Gi3/21,Gi3/22)
Alarming on (Gi3/23,Gi3/24,Gi3/25,Gi3/26,Gi3/27,Gi3/28,Gi3/29)
Alarming on (Gi3/30,Gi3/31,Gi3/32,Gi3/33,Gi3/34,Gi3/35,Gi3/36)
Alarming on (Gi3/37,Gi3/38,Gi3/39,Gi3/40,Gi3/41,Gi3/42,Gi3/43)
Alarming on (Gi3/44,Gi3/45,Gi3/46,Gi3/47,Gi3/48,Gi4/1,Gi4/2,Gi4/3)
Alarming on (Gi4/4,Gi4/5,Gi4/6,Gi4/7,Gi4/8,Gi4/9,Gi4/10,Gi4/11)
Alarming on (Gi4/12,Gi4/13,Gi4/14,Gi4/15,Gi4/16,Gi4/17,Gi4/18)
Alarming on (Gi4/19,Gi4/20,Gi4/21,Gi4/22,Gi4/23,Gi4/24,Gi4/25)
Alarming on (Gi4/26,Gi4/27,Gi4/28,Gi4/29,Gi4/30,Gi4/31,Gi4/32)
Alarming on (Gi4/33,Gi4/34,Gi4/35,Gi4/36,Gi4/37,Gi4/38,Gi4/39)
Alarming on (Gi4/40,Gi4/41,Gi4/42,Gi4/43,Gi4/44,Gi4/45,Gi4/46)
Alarming on (Gi4/47,Gi4/48,Gi5/1,Gi5/2,Gi5/3,Gi5/4,Gi5/5,Gi5/6)
Alarming on (Gi5/7,Gi5/8,Gi5/9,Gi5/10,Gi5/11,Gi5/12,Gi5/13,Gi5/14)
Alarming on (Gi5/15,Gi5/16,Gi5/17,Gi5/18,Gi5/19,Gi5/20,Gi5/21)
Alarming on (Gi5/22,Gi5/23,Gi5/24,Gi5/25,Gi5/26,Gi5/27,Gi5/28)
Alarming on (Gi5/29,Gi5/30,Gi5/31,Gi5/32,Gi5/33,Gi5/34,Gi5/35)
Alarming on (Gi5/36,Gi5/37,Gi5/38,Gi5/39,Gi5/40,Gi5/41,Gi5/42)
Alarming on (Gi5/43,Gi5/44,Gi5/45,Gi5/46,Gi5/47,Gi5/48,Gi6/1)
Alarming on (Gi6/2,Gi6/3,Gi6/4,Gi6/5,Gi6/6,Gi6/7,Gi6/8,Gi6/9)
Alarming on (Gi6/10,Gi6/11,Gi6/12,Gi6/13,Gi6/14,Gi6/15,Gi6/16)
Alarming on (Gi6/17,Gi6/18,Gi6/19,Gi6/20,Gi6/21,Gi6/22,Gi6/23)
Alarming on (Gi6/24,Gi6/25,Gi6/26,Gi6/27,Gi6/28,Gi6/29,Gi6/30)
Alarming on (Gi6/31,Gi6/32,Gi6/33,Gi6/34,Gi6/35,Gi6/36,Gi6/37)
Alarming on (Gi6/38,Gi6/39,Gi6/40,Gi6/41,Gi6/42,Gi6/43,Gi6/44)
Alarming on (Gi6/45,Gi6/46,Gi6/47,Gi6/48)



And Cisco 6513:

Input load:  yellow=75%, red=95%
Output load: yellow=75%, red=95%
Alarming on (Gi1/1,Gi1/2,Gi2/1,Gi2/2,Gi3/1,Gi3/2,Gi3/3,Gi3/4,Gi3/5,Gi3/6,Gi3/7)
Alarming on (Gi3/8,Gi3/9,Gi3/10,Gi3/11,Gi3/12,Gi3/13,Gi3/14,Gi3/15)
Alarming on (Gi3/16,Gi3/17,Gi3/18,Gi3/19,Gi3/20,Gi3/21,Gi3/22)
Alarming on (Gi3/23,Gi3/24,Gi3/25,Gi3/26,Gi3/27,Gi3/28,Gi3/29)
Alarming on (Gi3/30,Gi3/31,Gi3/32,Gi3/33,Gi3/34,Gi3/35,Gi3/36)
Alarming on (Gi3/37,Gi3/38,Gi3/39,Gi3/40,Gi3/41,Gi3/42,Gi3/43)
Alarming on (Gi3/44,Gi3/45,Gi3/46,Gi3/47,Gi3/48,Fa6/1,Fa6/2,Fa6/3)
Alarming on (Fa6/4,Fa6/5,Fa6/6,Fa6/7,Fa6/8,Fa6/9,Fa6/10,Fa6/11)
Alarming on (Fa6/12,Fa6/13,Fa6/14,Fa6/15,Fa6/16,Fa6/17,Fa6/18)
Alarming on (Fa6/19,Fa6/20,Fa6/21,Fa6/22,Fa6/23,Fa6/24,Fa6/25)
Alarming on (Fa6/26,Fa6/27,Fa6/28,Fa6/29,Fa6/30,Fa6/31,Fa6/32)
Alarming on (Fa6/33,Fa6/34,Fa6/35,Fa6/36,Fa6/37,Fa6/38,Fa6/39)
Alarming on (Fa6/40,Fa6/41,Fa6/42,Fa6/43,Fa6/44,Fa6/45,Fa6/46)
Alarming on (Fa6/47,Fa6/48,Fa9/1,Fa9/2,Fa9/3,Fa9/4,Fa9/5,Fa9/6)
Alarming on (Fa9/7,Fa9/8,Fa9/9,Fa9/10,Fa9/11,Fa9/12,Fa9/13,Fa9/14)
Alarming on (Fa9/15,Fa9/16,Fa9/17,Fa9/18,Fa9/19,Fa9/20,Fa9/21)
Alarming on (Fa9/22,Fa9/23,Fa9/24,Fa9/25,Fa9/26,Fa9/27,Fa9/28)
Alarming on (Fa9/29,Fa9/30,Fa9/31,Fa9/32,Fa9/33,Fa9/34,Fa9/35)
Alarming on (Fa9/36,Fa9/37,Fa9/38,Fa9/39,Fa9/40,Fa9/41,Fa9/42)
Alarming on (Fa9/43,Fa9/44,Fa9/45,Fa9/46,Fa9/47,Fa9/48,Fa10/1)
Alarming on (Fa10/2,Fa10/3,Fa10/4,Fa10/5,Fa10/6,Fa10/7,Fa10/8)
Alarming on (Fa10/9,Fa10/10,Fa10/11,Fa10/12,Fa10/13,Fa10/14,Fa10/15)
Alarming on (Fa10/16,Fa10/17,Fa10/18,Fa10/19,Fa10/20,Fa10/21)
Alarming on (Fa10/22,Fa10/23,Fa10/24,Fa10/25,Fa10/26,Fa10/27)
Alarming on (Fa10/28,Fa10/29,Fa10/30,Fa10/31,Fa10/32,Fa10/33)
Alarming on (Fa10/34,Fa10/35,Fa10/36,Fa10/37,Fa10/38,Fa10/39)
Alarming on (Fa10/40,Fa10/41,Fa10/42,Fa10/43,Fa10/44,Fa10/45)
Alarming on (Fa10/46,Fa10/47,Fa10/48,Gi11/1,Gi11/2,Gi11/3,Gi11/4)
Alarming on (Gi11/5,Gi11/6,Gi11/7,Gi11/8,Gi11/9,Gi11/10,Gi11/11)
Alarming on (Gi11/12,Gi11/13,Gi11/14,Gi11/15,Gi11/16,Gi12/1,Gi12/2)
Alarming on (Gi12/3,Gi12/4,Gi12/5,Gi12/6,Gi12/7,Gi12/8,Gi12/9)
Alarming on (Gi12/10,Gi12/11,Gi12/12,Gi12/13,Gi12/14,Gi12/15)
Alarming on (Gi12/16,Gi13/1,Gi13/2,Gi13/3,Gi13/4,Gi13/5,Gi13/6)
Alarming on (Gi13/7,Gi13/8,Gi13/9,Gi13/10,Gi13/11,Gi13/12,Gi13/13)
Alarming on (Gi13/14,Gi13/15,Gi13/16,EO0/0,Po1,Po2,Po7,Po8,Gi5/1)
Alarming on (Gi5/2,Gi5/3,Gi5/4,Gi5/5,Gi5/6,Gi5/7,Gi5/8,Gi5/9)
Alarming on (Gi5/10,Gi5/11,Gi5/12,Gi5/13,Gi5/14,Gi5/15,Gi5/16)
Alarming on (Gi5/17,Gi5/18,Gi5/19,Gi5/20,Gi5/21,Gi5/22,Gi5/23)
Alarming on (Gi5/24,Gi5/25,Gi5/26,Gi5/27,Gi5/28,Gi5/29,Gi5/30)
Alarming on (Gi5/31,Gi5/32,Gi5/33,Gi5/34,Gi5/35,Gi5/36,Gi5/37)
Alarming on (Gi5/38,Gi5/39,Gi5/40,Gi5/41,Gi5/42,Gi5/43,Gi5/44)
Alarming on (Gi5/45,Gi5/46,Gi5/47,Gi5/48,Po10,Po30,Po50)







On Fri, Nov 7, 2008 at 7:28 AM, Buchan Milne <bg...@st...>wrote:

> On Monday 03 November 2008 09:46:42 Buchan Milne wrote:
> > On Friday 31 October 2008 19:55:35 Robert Holden wrote:
> > > When I run snmpwalk on my interfaces I get the following:
> > > (I believe that the devmon template is using this ... notice that they
> > > are all the same.
> >
> > Depending on the SNMP implementation (and may differ on different IOS
> > versions).
> >
> > > A transform won't help)
> > > IF-MIB::ifName.70 = STRING: AT5/0/0
> > > IF-MIB::ifName.71 = STRING: AT5/0/0
> > > IF-MIB::ifName.72 = STRING: AT5/0/0
> > > IF-MIB::ifName.73 = STRING: AT5/0/0
> > > IF-MIB::ifName.74 = STRING: AT5/0/0
> >
> > One of our 7613's has:
> >
> > IF-MIB::ifName.1 = STRING: Gi3/1
> > [...]
> > IF-MIB::ifName.128 = STRING: ATM10/1/0.0-atm subif
> > IF-MIB::ifName.129 = STRING: ATM10/1/0-aal5 layer
> > IF-MIB::ifName.130 = STRING: ATM10/1/0.0-aal5 layer
> > IF-MIB::ifName.131 = STRING: VLAN-1
> >
> > > (This could be used, but you would end up w/ very long names.  G0/0
> would
> > > become GigabitEthernet0/0)
> > > IF-MIB::ifDescr.70 = STRING: ATM5/0/0
> > > IF-MIB::ifDescr.71 = STRING: ATM5/0/0-atm layer
> > > IF-MIB::ifDescr.72 = STRING: ATM5/0/0.0-atm subif
> > > IF-MIB::ifDescr.73 = STRING: ATM5/0/0-aal5 layer
> > > IF-MIB::ifDescr.74 = STRING: ATM5/0/0.0-aal5 layer
> >
> > On the same device as above:
> >
> > IF-MIB::ifDescr.1 = STRING: GigabitEthernet3/1
> > [...]
> > IF-MIB::ifDescr.128 = STRING: ATM10/1/0.0-atm subif
> > IF-MIB::ifDescr.129 = STRING: ATM10/1/0-aal5 layer
> > IF-MIB::ifDescr.130 = STRING: ATM10/1/0.0-aal5 layer
> > IF-MIB::ifDescr.131 = STRING: unrouted VLAN 1
> >
> > > (This may be helpful ... somehow ignore all type 37 and type 49, and
> sub
> > > interface 0 ??)
> > > IF-MIB::ifType.70 = INTEGER: sonet(39)
> > > IF-MIB::ifType.71 = INTEGER: atm(37)
> > > IF-MIB::ifType.72 = INTEGER: atmSubInterface(134)
> > > IF-MIB::ifType.73 = INTEGER: aal5(49)
> > > IF-MIB::ifType.74 = INTEGER: aal5(49)
> >
> > But, in my case, I want to graph:
> > IF-MIB::ifName.103 = STRING: ATM10/1/0.1-aal5 layer
> >
> > (it is the only interface which shows the correct traffic)
> >
> > > I will open a bug if you like.  Is the issue that originated this
> thread
> > > the same as the one I am experiencing?
> >
> > Well, there are two aspects to the bug:
> >
> > 1)Devmon should strip invalid characters out of interface names for the
> RRD
> > data sent with the status message.
> >
> > 2)The Hobbit RRD collector module for devmon should not segfault if data
> is
> > not in the format:
> >
> > <name_without_spaces> value[:value[:value]]
>
> I fixed this one last night. You can either grab the new do_devmon.c, and
> run
> 'make' again, and copy the hobbitd_rrd over the previous binary, or you can
> grab the new complete patch for a build from scratch:
>
> http://devmon.svn.sourceforge.net/viewvc/devmon?view=rev&revision=90
>
> (at present, viewvc seems to be a bit bust on sourceforge, but these should
> be
> the URLs to the current versions of the files when it is working:
> http://devmon.svn.sourceforge.net/viewvc/devmon/trunk/extras/do_devmon.c
> http://devmon.svn.sourceforge.net/viewvc/devmon/trunk/extras/hobbit-4.2.0-
> devmon-complete.patch<http://devmon.svn.sourceforge.net/viewvc/devmon/trunk/extras/hobbit-4.2.0-%0Adevmon-complete.patch>
> )
>
> I will update my Hobbit packages with this once I've upgraded my production
> Hobbit box (but the SRPM is in Mandriva cooker already).
>
> Regards,
> Buchan
>
>
> To unsubscribe from the hobbit list, send an e-mail to
> hob...@hs...
>
>
>

Re: [Devmon] [hobbit] Re: Devmon causing core dumps

[Buchan M. <bg...@st...>]

On Thursday, 19 November 2009 18:49:28 mario andre wrote:
> Hi,
>
> Bunchan.
>
> I'm getting hobbitd_rrd crash. I'm running 4.2.3 RC1

Any reason not to use the final release of 4.2.3?

> with your do_devmon.c
> revision 154.
> I figured that the core file are repeating for the same equipments. cisco
> 6513 and cisco 4507 for if_load.

How did you determine this?

> THis could be because of the number of interfaces? What do you think?

Unlikely. Some 6509's and 7613's I was monitoring had about the same number or 
more ports and didn't have problems.

> Thanks in advance,
>
> Mario.
>
> Cisco 4507:
>
> Alarming on
> (Gi1/1,Gi1/2,Gi2/1,Gi2/2,Gi3/1,Gi3/2,Gi3/3,Gi3/4,Gi3/5,Gi3/6,Gi3/7)
> Alarming on (Gi3/8,Gi3/9,Gi3/10,Gi3/11,Gi3/12,Gi3/13,Gi3/14,Gi3/15)
> Alarming on (Gi3/16,Gi3/17,Gi3/18,Gi3/19,Gi3/20,Gi3/21,Gi3/22)
> Alarming on (Gi3/23,Gi3/24,Gi3/25,Gi3/26,Gi3/27,Gi3/28,Gi3/29)
> Alarming on (Gi3/30,Gi3/31,Gi3/32,Gi3/33,Gi3/34,Gi3/35,Gi3/36)
> Alarming on (Gi3/37,Gi3/38,Gi3/39,Gi3/40,Gi3/41,Gi3/42,Gi3/43)
> Alarming on (Gi3/44,Gi3/45,Gi3/46,Gi3/47,Gi3/48,Gi4/1,Gi4/2,Gi4/3)
> Alarming on (Gi4/4,Gi4/5,Gi4/6,Gi4/7,Gi4/8,Gi4/9,Gi4/10,Gi4/11)
> Alarming on (Gi4/12,Gi4/13,Gi4/14,Gi4/15,Gi4/16,Gi4/17,Gi4/18)
> Alarming on (Gi4/19,Gi4/20,Gi4/21,Gi4/22,Gi4/23,Gi4/24,Gi4/25)
> Alarming on (Gi4/26,Gi4/27,Gi4/28,Gi4/29,Gi4/30,Gi4/31,Gi4/32)
> Alarming on (Gi4/33,Gi4/34,Gi4/35,Gi4/36,Gi4/37,Gi4/38,Gi4/39)
> Alarming on (Gi4/40,Gi4/41,Gi4/42,Gi4/43,Gi4/44,Gi4/45,Gi4/46)
> Alarming on (Gi4/47,Gi4/48,Gi5/1,Gi5/2,Gi5/3,Gi5/4,Gi5/5,Gi5/6)
> Alarming on (Gi5/7,Gi5/8,Gi5/9,Gi5/10,Gi5/11,Gi5/12,Gi5/13,Gi5/14)
> Alarming on (Gi5/15,Gi5/16,Gi5/17,Gi5/18,Gi5/19,Gi5/20,Gi5/21)
> Alarming on (Gi5/22,Gi5/23,Gi5/24,Gi5/25,Gi5/26,Gi5/27,Gi5/28)
> Alarming on (Gi5/29,Gi5/30,Gi5/31,Gi5/32,Gi5/33,Gi5/34,Gi5/35)
> Alarming on (Gi5/36,Gi5/37,Gi5/38,Gi5/39,Gi5/40,Gi5/41,Gi5/42)
> Alarming on (Gi5/43,Gi5/44,Gi5/45,Gi5/46,Gi5/47,Gi5/48,Gi6/1)
> Alarming on (Gi6/2,Gi6/3,Gi6/4,Gi6/5,Gi6/6,Gi6/7,Gi6/8,Gi6/9)
> Alarming on (Gi6/10,Gi6/11,Gi6/12,Gi6/13,Gi6/14,Gi6/15,Gi6/16)
> Alarming on (Gi6/17,Gi6/18,Gi6/19,Gi6/20,Gi6/21,Gi6/22,Gi6/23)
> Alarming on (Gi6/24,Gi6/25,Gi6/26,Gi6/27,Gi6/28,Gi6/29,Gi6/30)
> Alarming on (Gi6/31,Gi6/32,Gi6/33,Gi6/34,Gi6/35,Gi6/36,Gi6/37)
> Alarming on (Gi6/38,Gi6/39,Gi6/40,Gi6/41,Gi6/42,Gi6/43,Gi6/44)
> Alarming on (Gi6/45,Gi6/46,Gi6/47,Gi6/48)
>
>
>
> And Cisco 6513:
>
> Input load:  yellow=75%, red=95%
> Output load: yellow=75%, red=95%
> Alarming on
> (Gi1/1,Gi1/2,Gi2/1,Gi2/2,Gi3/1,Gi3/2,Gi3/3,Gi3/4,Gi3/5,Gi3/6,Gi3/7)
> Alarming on (Gi3/8,Gi3/9,Gi3/10,Gi3/11,Gi3/12,Gi3/13,Gi3/14,Gi3/15)
> Alarming on (Gi3/16,Gi3/17,Gi3/18,Gi3/19,Gi3/20,Gi3/21,Gi3/22)
> Alarming on (Gi3/23,Gi3/24,Gi3/25,Gi3/26,Gi3/27,Gi3/28,Gi3/29)
> Alarming on (Gi3/30,Gi3/31,Gi3/32,Gi3/33,Gi3/34,Gi3/35,Gi3/36)
> Alarming on (Gi3/37,Gi3/38,Gi3/39,Gi3/40,Gi3/41,Gi3/42,Gi3/43)
> Alarming on (Gi3/44,Gi3/45,Gi3/46,Gi3/47,Gi3/48,Fa6/1,Fa6/2,Fa6/3)
> Alarming on (Fa6/4,Fa6/5,Fa6/6,Fa6/7,Fa6/8,Fa6/9,Fa6/10,Fa6/11)
> Alarming on (Fa6/12,Fa6/13,Fa6/14,Fa6/15,Fa6/16,Fa6/17,Fa6/18)
> Alarming on (Fa6/19,Fa6/20,Fa6/21,Fa6/22,Fa6/23,Fa6/24,Fa6/25)
> Alarming on (Fa6/26,Fa6/27,Fa6/28,Fa6/29,Fa6/30,Fa6/31,Fa6/32)
> Alarming on (Fa6/33,Fa6/34,Fa6/35,Fa6/36,Fa6/37,Fa6/38,Fa6/39)
> Alarming on (Fa6/40,Fa6/41,Fa6/42,Fa6/43,Fa6/44,Fa6/45,Fa6/46)
> Alarming on (Fa6/47,Fa6/48,Fa9/1,Fa9/2,Fa9/3,Fa9/4,Fa9/5,Fa9/6)
> Alarming on (Fa9/7,Fa9/8,Fa9/9,Fa9/10,Fa9/11,Fa9/12,Fa9/13,Fa9/14)
> Alarming on (Fa9/15,Fa9/16,Fa9/17,Fa9/18,Fa9/19,Fa9/20,Fa9/21)
> Alarming on (Fa9/22,Fa9/23,Fa9/24,Fa9/25,Fa9/26,Fa9/27,Fa9/28)
> Alarming on (Fa9/29,Fa9/30,Fa9/31,Fa9/32,Fa9/33,Fa9/34,Fa9/35)
> Alarming on (Fa9/36,Fa9/37,Fa9/38,Fa9/39,Fa9/40,Fa9/41,Fa9/42)
> Alarming on (Fa9/43,Fa9/44,Fa9/45,Fa9/46,Fa9/47,Fa9/48,Fa10/1)
> Alarming on (Fa10/2,Fa10/3,Fa10/4,Fa10/5,Fa10/6,Fa10/7,Fa10/8)
> Alarming on (Fa10/9,Fa10/10,Fa10/11,Fa10/12,Fa10/13,Fa10/14,Fa10/15)
> Alarming on (Fa10/16,Fa10/17,Fa10/18,Fa10/19,Fa10/20,Fa10/21)
> Alarming on (Fa10/22,Fa10/23,Fa10/24,Fa10/25,Fa10/26,Fa10/27)
> Alarming on (Fa10/28,Fa10/29,Fa10/30,Fa10/31,Fa10/32,Fa10/33)
> Alarming on (Fa10/34,Fa10/35,Fa10/36,Fa10/37,Fa10/38,Fa10/39)
> Alarming on (Fa10/40,Fa10/41,Fa10/42,Fa10/43,Fa10/44,Fa10/45)
> Alarming on (Fa10/46,Fa10/47,Fa10/48,Gi11/1,Gi11/2,Gi11/3,Gi11/4)
> Alarming on (Gi11/5,Gi11/6,Gi11/7,Gi11/8,Gi11/9,Gi11/10,Gi11/11)
> Alarming on (Gi11/12,Gi11/13,Gi11/14,Gi11/15,Gi11/16,Gi12/1,Gi12/2)
> Alarming on (Gi12/3,Gi12/4,Gi12/5,Gi12/6,Gi12/7,Gi12/8,Gi12/9)
> Alarming on (Gi12/10,Gi12/11,Gi12/12,Gi12/13,Gi12/14,Gi12/15)
> Alarming on (Gi12/16,Gi13/1,Gi13/2,Gi13/3,Gi13/4,Gi13/5,Gi13/6)
> Alarming on (Gi13/7,Gi13/8,Gi13/9,Gi13/10,Gi13/11,Gi13/12,Gi13/13)
> Alarming on (Gi13/14,Gi13/15,Gi13/16,EO0/0,Po1,Po2,Po7,Po8,Gi5/1)
> Alarming on (Gi5/2,Gi5/3,Gi5/4,Gi5/5,Gi5/6,Gi5/7,Gi5/8,Gi5/9)
> Alarming on (Gi5/10,Gi5/11,Gi5/12,Gi5/13,Gi5/14,Gi5/15,Gi5/16)
> Alarming on (Gi5/17,Gi5/18,Gi5/19,Gi5/20,Gi5/21,Gi5/22,Gi5/23)
> Alarming on (Gi5/24,Gi5/25,Gi5/26,Gi5/27,Gi5/28,Gi5/29,Gi5/30)
> Alarming on (Gi5/31,Gi5/32,Gi5/33,Gi5/34,Gi5/35,Gi5/36,Gi5/37)
> Alarming on (Gi5/38,Gi5/39,Gi5/40,Gi5/41,Gi5/42,Gi5/43,Gi5/44)
> Alarming on (Gi5/45,Gi5/46,Gi5/47,Gi5/48,Po10,Po30,Po50)

There are no funny names here, which is what would have caused problems in 
previous versions of the devmon collector (but rev 154 shouldn't).

Can you provide a backtrace from one of the core files? It will provide at 
least the devmon test name that triggered the core, and possibly information 
that would help to fix the issue. You can do that with something like:

gdb /path/to/xymon-4.2.3RC1/hobbitd/hobbitd_rrd -c /path/to/core.xxxx

Where the path to hobbitd above is the hobbitd in the source directory where 
you built the hobbitd in question. Then, in the gdb prompt, type 'bt full'

It would also help more to provide the output of something like:

bb localhost 'hobbitdlog hostname.if_load'. This would allow me to test with 
the exact data your server is getting.

Regards,
Buchan

Re: [Devmon] [hobbit] Re: Devmon causing core dumps

[Buchan M. <bg...@st...>]

On Monday, 8 February 2010 16:37:35 mario andre wrote:
> Hi Buchan, How are you?

Please keep mail on the mailing lists.

> My friend I've upgrade to xymon 4.3.0 beta2 because I was needing the new
> features reports from this version.

Please use the version in xymon / hobbitmon 4.3.0 branch svn.

> But after I upgrade I came with the hobbitd_rrd fatal errors as I have
> before talking to you and install the do_devmon.c revision 164.

The fixes didn't make it into 4.3.0-beta2.

> The do_devmon.c version from henrik package is different from the revision
> 164 that I was using and produced the hobbitd_rrd errors.

Yes, some changes were made to the API for the RRD changes in 4.3.x, so the 
version(s) for 4.2.x won't compile.

> I've tried to
> compile the do_devmon.c rev 164 but I'm getting the folowing errors:
> 
> In file included from do_rrd.c:567:
> rrd/do_devmon.c: In function 'do_devmon_rrd':
> rrd/do_devmon.c:78: error: 'rra1' undeclared (first use in this function)
> rrd/do_devmon.c:78: error: (Each undeclared identifier is reported only
>  once rrd/do_devmon.c:78: error: for each function it appears in.)
> rrd/do_devmon.c:79: error: 'rra2' undeclared (first use in this function)
> rrd/do_devmon.c:80: error: 'rra3' undeclared (first use in this function)
> rrd/do_devmon.c:81: error: 'rra4' undeclared (first use in this function)
> rrd/do_devmon.c:84: warning: assignment from incompatible pointer type
> rrd/do_devmon.c:118: warning: passing argument 3 of 'create_and_update_rrd'
> from incompatible pointer type
> rrd/do_devmon.c:118: error: too few arguments to function
> 'create_and_update_rrd'
> do_rrd.c: In function 'update_rrd':
> do_rrd.c:649: warning: passing argument 4 of 'do_devmon_rrd' makes integer
> from pointer without a cast
> do_rrd.c:649: error: too many arguments to function 'do_devmon_rrd'
> make[1]: *** [do_rrd.o] Error 1
> make[1]: Leaving directory `/home/xymon/xymon-4.3.0-beta2/hobbitd'
> make: *** [hobbitd-build] Error 2

I haven't personally tested, but the changes I committed in rev 6222 of the 
hobbitmon svn repo should address both:

http://hobbitmon.svn.sf.net/viewvc/hobbitmon?view=rev&revision=6222

Please let me know if it works for you.

Regards,
Buchan

Re: [Devmon] [hobbit] Re: Devmon causing core dumps

[mario a. <row...@gm...>]

Hello Bunchan,

First of all sorry to not write to the list first.
The revision 6222 compiled well. I will keep monitoring if other hobbitd_rrd
fatal errors occurs again.

When you say "use the version in xymon / hobbitmon 4.3.0 branch svn" where I
can get this version?
What's the difference between branch and beta2?
I would like to be a contributor of henrik xymon. I've made a lot of
customizations and reports that I think can improve xymon tool.

Best regards,

Mario.





On Mon, Feb 8, 2010 at 6:41 PM, Buchan Milne <bg...@st...>wrote:

> On Monday, 8 February 2010 16:37:35 mario andre wrote:
> > Hi Buchan, How are you?
>
> Please keep mail on the mailing lists.
>
> > My friend I've upgrade to xymon 4.3.0 beta2 because I was needing the new
> > features reports from this version.
>
> Please use the version in xymon / hobbitmon 4.3.0 branch svn.
>
> > But after I upgrade I came with the hobbitd_rrd fatal errors as I have
> > before talking to you and install the do_devmon.c revision 164.
>
> The fixes didn't make it into 4.3.0-beta2.
>
> > The do_devmon.c version from henrik package is different from the
> revision
> > 164 that I was using and produced the hobbitd_rrd errors.
>
> Yes, some changes were made to the API for the RRD changes in 4.3.x, so the
> version(s) for 4.2.x won't compile.
>
> > I've tried to
> > compile the do_devmon.c rev 164 but I'm getting the folowing errors:
> >
> > In file included from do_rrd.c:567:
> > rrd/do_devmon.c: In function 'do_devmon_rrd':
> > rrd/do_devmon.c:78: error: 'rra1' undeclared (first use in this function)
> > rrd/do_devmon.c:78: error: (Each undeclared identifier is reported only
> >  once rrd/do_devmon.c:78: error: for each function it appears in.)
> > rrd/do_devmon.c:79: error: 'rra2' undeclared (first use in this function)
> > rrd/do_devmon.c:80: error: 'rra3' undeclared (first use in this function)
> > rrd/do_devmon.c:81: error: 'rra4' undeclared (first use in this function)
> > rrd/do_devmon.c:84: warning: assignment from incompatible pointer type
> > rrd/do_devmon.c:118: warning: passing argument 3 of
> 'create_and_update_rrd'
> > from incompatible pointer type
> > rrd/do_devmon.c:118: error: too few arguments to function
> > 'create_and_update_rrd'
> > do_rrd.c: In function 'update_rrd':
> > do_rrd.c:649: warning: passing argument 4 of 'do_devmon_rrd' makes
> integer
> > from pointer without a cast
> > do_rrd.c:649: error: too many arguments to function 'do_devmon_rrd'
> > make[1]: *** [do_rrd.o] Error 1
> > make[1]: Leaving directory `/home/xymon/xymon-4.3.0-beta2/hobbitd'
> > make: *** [hobbitd-build] Error 2
>
> I haven't personally tested, but the changes I committed in rev 6222 of the
> hobbitmon svn repo should address both:
>
> http://hobbitmon.svn.sf.net/viewvc/hobbitmon?view=rev&revision=6222
>
> Please let me know if it works for you.
>
> Regards,
> Buchan
>

Re: [Devmon] [hobbit] Re: Devmon causing core dumps

[mario a. <row...@gm...>]

Hi Bunchan,

I've got lot of core with rev 6222.

-------------------- Core files with do_devmon.c from revision 6222

[root@isslu410 core_old]# gdb ../../bin/hobbitd_rrd core.6545
GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
Cannot access memory at address 0x524149
(gdb) bt
#0  0x0086a402 in ?? ()
#1  0x00513040 in ?? ()
#2  0x0062eff4 in ?? ()
#3  0xb7f636c0 in ?? ()
#4  0xbf94c2c8 in ?? ()
#5  0x00514a21 in ?? ()
#6  0x00000006 in ?? ()
#7  0xbf94c23c in ?? ()
#8  0x00000000 in ?? ()

----------------- COre files with original do_devmon.c from xymon 4.3.0
beta2

(gdb) bt
#0  0x00fc7402 in __kernel_vsyscall ()
#1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
#2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
#3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
#4  <signal handler called>
#5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
#6  0x0804e704 in do_devmon_rrd (hostname=0xb7f0f6ab "Cisco_4507R_02",
testname=0xb7f0f6ba "if_load",
    classname=0xb7f0f6ee "cosc/network/601_El_Camino_Real,cosc/temp",
pagepaths=0x80700be "",
    msg=0xb7f0f718 "status Cisco_4507R_02.if_load green Wed Feb  3 20:12:57
2010", tstamp=1265256364) at rrd/do_devmon.c:83
#7  0x080598e4 in update_rrd (hostname=0xb7f0f6ab "Cisco_4507R_02",
testname=0xb7f0f6ba "if_load",
    msg=0xb7f0f718 "status Cisco_4507R_02.if_load green Wed Feb  3 20:12:57
2010", tstamp=1265256364, sender=0xb7f0f69b "172.29.186.131",
    ldef=0x8f4cb08, classname=0xb7f0f6ee
"cosc/network/601_El_Camino_Real,cosc/temp", pagepaths=0x80700be "") at
do_rrd.c:649
#8  0x0804a420 in main (argc=2, argv=0xbfc803a4) at hobbitd_rrd.c:349


Thanks in advance,

Mario.


On Tue, Feb 9, 2010 at 12:10 PM, mario andre <row...@gm...> wrote:

> Hello Bunchan,
>
> First of all sorry to not write to the list first.
> The revision 6222 compiled well. I will keep monitoring if other
> hobbitd_rrd fatal errors occurs again.
>
> When you say "use the version in xymon / hobbitmon 4.3.0 branch svn" where
> I can get this version?
> What's the difference between branch and beta2?
> I would like to be a contributor of henrik xymon. I've made a lot of
> customizations and reports that I think can improve xymon tool.
>
> Best regards,
>
> Mario.
>
>
>
>
>
>
> On Mon, Feb 8, 2010 at 6:41 PM, Buchan Milne <bg...@st...>wrote:
>
>> On Monday, 8 February 2010 16:37:35 mario andre wrote:
>> > Hi Buchan, How are you?
>>
>> Please keep mail on the mailing lists.
>>
>> > My friend I've upgrade to xymon 4.3.0 beta2 because I was needing the
>> new
>> > features reports from this version.
>>
>> Please use the version in xymon / hobbitmon 4.3.0 branch svn.
>>
>> > But after I upgrade I came with the hobbitd_rrd fatal errors as I have
>> > before talking to you and install the do_devmon.c revision 164.
>>
>> The fixes didn't make it into 4.3.0-beta2.
>>
>> > The do_devmon.c version from henrik package is different from the
>> revision
>> > 164 that I was using and produced the hobbitd_rrd errors.
>>
>> Yes, some changes were made to the API for the RRD changes in 4.3.x, so
>> the
>> version(s) for 4.2.x won't compile.
>>
>> > I've tried to
>> > compile the do_devmon.c rev 164 but I'm getting the folowing errors:
>> >
>> > In file included from do_rrd.c:567:
>> > rrd/do_devmon.c: In function 'do_devmon_rrd':
>> > rrd/do_devmon.c:78: error: 'rra1' undeclared (first use in this
>> function)
>> > rrd/do_devmon.c:78: error: (Each undeclared identifier is reported only
>> >  once rrd/do_devmon.c:78: error: for each function it appears in.)
>> > rrd/do_devmon.c:79: error: 'rra2' undeclared (first use in this
>> function)
>> > rrd/do_devmon.c:80: error: 'rra3' undeclared (first use in this
>> function)
>> > rrd/do_devmon.c:81: error: 'rra4' undeclared (first use in this
>> function)
>> > rrd/do_devmon.c:84: warning: assignment from incompatible pointer type
>> > rrd/do_devmon.c:118: warning: passing argument 3 of
>> 'create_and_update_rrd'
>> > from incompatible pointer type
>> > rrd/do_devmon.c:118: error: too few arguments to function
>> > 'create_and_update_rrd'
>> > do_rrd.c: In function 'update_rrd':
>> > do_rrd.c:649: warning: passing argument 4 of 'do_devmon_rrd' makes
>> integer
>> > from pointer without a cast
>> > do_rrd.c:649: error: too many arguments to function 'do_devmon_rrd'
>> > make[1]: *** [do_rrd.o] Error 1
>> > make[1]: Leaving directory `/home/xymon/xymon-4.3.0-beta2/hobbitd'
>> > make: *** [hobbitd-build] Error 2
>>
>> I haven't personally tested, but the changes I committed in rev 6222 of
>> the
>> hobbitmon svn repo should address both:
>>
>> http://hobbitmon.svn.sf.net/viewvc/hobbitmon?view=rev&revision=6222
>>
>> Please let me know if it works for you.
>>
>> Regards,
>> Buchan
>>
>
>

Re: [Devmon] [hobbit] Re: Devmon causing core dumps

[Buchan M. <bg...@st...>]

On Tuesday, 9 February 2010 19:41:19 mario andre wrote:
> Hi Bunchan,
> 
> I've got lot of core with rev 6222.
> 
> -------------------- Core files with do_devmon.c from revision 6222
> 
> [root@isslu410 core_old]# gdb ../../bin/hobbitd_rrd core.6545
> GNU gdb Fedora (6.8-37.el5)
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
>  <http://gnu.org/licenses/gpl.html
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i386-redhat-linux-gnu"...
> Cannot access memory at address 0x524149
> (gdb) bt
> #0  0x0086a402 in ?? ()
> #1  0x00513040 in ?? ()
> #2  0x0062eff4 in ?? ()
> #3  0xb7f636c0 in ?? ()
> #4  0xbf94c2c8 in ?? ()
> #5  0x00514a21 in ?? ()
> #6  0x00000006 in ?? ()
> #7  0xbf94c23c in ?? ()
> #8  0x00000000 in ?? ()
> 

This binary is stripped, so this backtrace is quite useless. It would help if 
you could try again with a non-stripped hobbitd_rrd with debugging enabled.


> ----------------- COre files with original do_devmon.c from xymon 4.3.0
> beta2
> 
> (gdb) bt
> #0  0x00fc7402 in __kernel_vsyscall ()
> #1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
> #2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
> #3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
> #4  <signal handler called>
> #5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
> #6  0x0804e704 in do_devmon_rrd (hostname=0xb7f0f6ab "Cisco_4507R_02",
> testname=0xb7f0f6ba "if_load",
>     classname=0xb7f0f6ee "cosc/network/601_El_Camino_Real,cosc/temp",
> pagepaths=0x80700be "",
>     msg=0xb7f0f718 "status Cisco_4507R_02.if_load green Wed Feb  3 20:12:57
> 2010", tstamp=1265256364) at rrd/do_devmon.c:83
> #7  0x080598e4 in update_rrd (hostname=0xb7f0f6ab "Cisco_4507R_02",
> testname=0xb7f0f6ba "if_load",
>     msg=0xb7f0f718 "status Cisco_4507R_02.if_load green Wed Feb  3 20:12:57
> 2010", tstamp=1265256364, sender=0xb7f0f69b "172.29.186.131",
>     ldef=0x8f4cb08, classname=0xb7f0f6ee
> "cosc/network/601_El_Camino_Real,cosc/temp", pagepaths=0x80700be "") at
> do_rrd.c:649
> #8  0x0804a420 in main (argc=2, argv=0xbfc803a4) at hobbitd_rrd.c:349
> 

The first part (lines 93-96 according to the lines on the side) of hunk 4 (the 
"Line 79 Line 90" one) of this patch should have fixed this:

http://hobbitmon.svn.sf.net/viewvc/hobbitmon/branches/4.3.0/hobbitd/rrd/do_devmon.c?r1=6171&r2=6222

This was forward-ported from the fixes for 4.2.x. I will try and test this 
myself the coming weekend.

Regards,
Buchan

Re: [Devmon] [hobbit] Re: Devmon causing core dumps

[Mario A. P. <row...@gm...>]

HI Bunchan, How are ayou?!

I'm still having problems with the revision 6222, do you have a new
revision?

Thanks in advance,

Mario.


#0  0x00cf8402 in __kernel_vsyscall ()
#1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
#2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
#3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
#4  <signal handler called>
#5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
#6  0x0804e750 in do_devmon_rrd (hostname=0xb7f5e337 "b304-s10",
testname=0xb7f5e340 "if_load",
    classname=0xb7f5e374 "imation/imation_network/Infrastructure_Devices",
pagepaths=0x80700be "",
    msg=0xb7f5e3a3 "status b304-s10.if_load green Wed Mar 31 09:37:26 2010",
tstamp=1270039405) at rrd/do_devmon.c:87
#7  0x080598e4 in update_rrd (hostname=0xb7f5e337 "b304-s10",
testname=0xb7f5e340 "if_load",
    msg=0xb7f5e3a3 "status b304-s10.if_load green Wed Mar 31 09:37:26 2010",
tstamp=1270039405, sender=0xb7f5e328 "129.220.11.51",
    ldef=0x857fd08, classname=0xb7f5e374
"imation/imation_network/Infrastructure_Devices", pagepaths=0x80700be "") at
do_rrd.c:649
#8  0x0804a420 in main (argc=2, argv=0xbfe26434) at hobbitd_rrd.c:349

[New process 5633]
#0  0x00bd6402 in __kernel_vsyscall ()
(gdb) bt
#0  0x00bd6402 in __kernel_vsyscall ()
#1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
#2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
#3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
#4  <signal handler called>
#5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
#6  0x0804e704 in do_devmon_rrd (hostname=0xb7ed434b "neuss-r1",
testname=0xb7ed4354 "if_load",
    classname=0xb7ed4388 "imation/imation_network/Infrastructure_Devices",
pagepaths=0x80700be "",
    msg=0xb7ed43b7 "status neuss-r1.if_load green Wed Mar 31 09:38:02 2010",
tstamp=1270039405) at rrd/do_devmon.c:83
#7  0x080598e4 in update_rrd (hostname=0xb7ed434b "neuss-r1",
testname=0xb7ed4354 "if_load",
    msg=0xb7ed43b7 "status neuss-r1.if_load green Wed Mar 31 09:38:02 2010",
tstamp=1270039405, sender=0xb7ed433c "129.220.11.51",
    ldef=0x8fe97f8, classname=0xb7ed4388
"imation/imation_network/Infrastructure_Devices", pagepaths=0x80700be "") at
do_rrd.c:649
#8  0x0804a420 in main (argc=2, argv=0xbffe0854) at hobbitd_rrd.c:349

[New process 32473]
#0  0x00bee402 in __kernel_vsyscall ()
(gdb) bt
#0  0x00bee402 in __kernel_vsyscall ()
#1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
#2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
#3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
#4  <signal handler called>
#5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
#6  0x0804e750 in do_devmon_rrd (hostname=0xb7fb0e0a "b304-s2",
testname=0xb7fb0e12 "if_load",
    classname=0xb7fb0e46 "imation/imation_network/Infrastructure_Devices",
pagepaths=0x80700be "",
    msg=0xb7fb0e75 "status b304-s2.if_load green Wed Mar 31 08:22:07 2010",
tstamp=1270034884) at rrd/do_devmon.c:87
#7  0x080598e4 in update_rrd (hostname=0xb7fb0e0a "b304-s2",
testname=0xb7fb0e12 "if_load",
    msg=0xb7fb0e75 "status b304-s2.if_load green Wed Mar 31 08:22:07 2010",
tstamp=1270034884, sender=0xb7fb0dfb "129.220.11.51",
    ldef=0x9635758, classname=0xb7fb0e46
"imation/imation_network/Infrastructure_Devices", pagepaths=0x80700be "") at
do_rrd.c:649
#8  0x0804a420 in main (argc=2, argv=0xbfb1c324) at hobbitd_rrd.c:349


[New process 29610]
#0  0x00ddb402 in __kernel_vsyscall ()
(gdb) bt
#0  0x00ddb402 in __kernel_vsyscall ()
#1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
#2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
#3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
#4  <signal handler called>
#5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
#6  0x0804e704 in do_devmon_rrd (hostname=0xb7f18544 "b304-s4",
testname=0xb7f1854c "if_load",
    classname=0xb7f18580 "imation/imation_network/Infrastructure_Devices",
pagepaths=0x80700be "",
    msg=0xb7f185af "status b304-s4.if_load green Wed Mar 31 07:37:03 2010",
tstamp=1270032173) at rrd/do_devmon.c:83
#7  0x080598e4 in update_rrd (hostname=0xb7f18544 "b304-s4",
testname=0xb7f1854c "if_load",
    msg=0xb7f185af "status b304-s4.if_load green Wed Mar 31 07:37:03 2010",
tstamp=1270032173, sender=0xb7f18535 "129.220.11.51",
    ldef=0x93c45c8, classname=0xb7f18580
"imation/imation_network/Infrastructure_Devices", pagepaths=0x80700be "") at
do_rrd.c:649
#8  0x0804a420 in main (argc=2, argv=0xbff54ef4) at hobbitd_rrd.c:349

#0  0x00aac402 in __kernel_vsyscall ()
(gdb) bt
#0  0x00aac402 in __kernel_vsyscall ()
#1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
#2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
#3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
#4  <signal handler called>
#5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
#6  0x0804e750 in do_devmon_rrd (hostname=0xb7ee3151 "b304-s3",
testname=0xb7ee3159 "if_load",
    classname=0xb7ee318d "imation/imation_network/Infrastructure_Devices",
pagepaths=0x80700be "",
    msg=0xb7ee31bc "status b304-s3.if_load green Wed Mar 31 05:51:59 2010",
tstamp=1270025883) at rrd/do_devmon.c:87
#7  0x080598e4 in update_rrd (hostname=0xb7ee3151 "b304-s3",
testname=0xb7ee3159 "if_load",
    msg=0xb7ee31bc "status b304-s3.if_load green Wed Mar 31 05:51:59 2010",
tstamp=1270025883, sender=0xb7ee3142 "129.220.11.51",
    ldef=0x8b5fb40, classname=0xb7ee318d
"imation/imation_network/Infrastructure_Devices", pagepaths=0x80700be "") at
do_rrd.c:649
#8  0x0804a420 in main (argc=2, argv=0xbfcfea64) at hobbitd_rrd.c:349




On Wed, Feb 10, 2010 at 7:34 AM, Buchan Milne <bg...@st...>wrote:

> On Tuesday, 9 February 2010 19:41:19 mario andre wrote:
> > Hi Bunchan,
> >
> > I've got lot of core with rev 6222.
> >
> > -------------------- Core files with do_devmon.c from revision 6222
> >
> > [root@isslu410 core_old]# gdb ../../bin/hobbitd_rrd core.6545
> > GNU gdb Fedora (6.8-37.el5)
> > Copyright (C) 2008 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> >  <http://gnu.org/licenses/gpl.html
> >
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> > and "show warranty" for details.
> > This GDB was configured as "i386-redhat-linux-gnu"...
> > Cannot access memory at address 0x524149
> > (gdb) bt
> > #0  0x0086a402 in ?? ()
> > #1  0x00513040 in ?? ()
> > #2  0x0062eff4 in ?? ()
> > #3  0xb7f636c0 in ?? ()
> > #4  0xbf94c2c8 in ?? ()
> > #5  0x00514a21 in ?? ()
> > #6  0x00000006 in ?? ()
> > #7  0xbf94c23c in ?? ()
> > #8  0x00000000 in ?? ()
> >
>
> This binary is stripped, so this backtrace is quite useless. It would help
> if
> you could try again with a non-stripped hobbitd_rrd with debugging enabled.
>
>
> > ----------------- COre files with original do_devmon.c from xymon 4.3.0
> > beta2
> >
> > (gdb) bt
> > #0  0x00fc7402 in __kernel_vsyscall ()
> > #1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
> > #2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
> > #3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
> > #4  <signal handler called>
> > #5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
> > #6  0x0804e704 in do_devmon_rrd (hostname=0xb7f0f6ab "Cisco_4507R_02",
> > testname=0xb7f0f6ba "if_load",
> >     classname=0xb7f0f6ee "cosc/network/601_El_Camino_Real,cosc/temp",
> > pagepaths=0x80700be "",
> >     msg=0xb7f0f718 "status Cisco_4507R_02.if_load green Wed Feb  3
> 20:12:57
> > 2010", tstamp=1265256364) at rrd/do_devmon.c:83
> > #7  0x080598e4 in update_rrd (hostname=0xb7f0f6ab "Cisco_4507R_02",
> > testname=0xb7f0f6ba "if_load",
> >     msg=0xb7f0f718 "status Cisco_4507R_02.if_load green Wed Feb  3
> 20:12:57
> > 2010", tstamp=1265256364, sender=0xb7f0f69b "172.29.186.131",
> >     ldef=0x8f4cb08, classname=0xb7f0f6ee
> > "cosc/network/601_El_Camino_Real,cosc/temp", pagepaths=0x80700be "") at
> > do_rrd.c:649
> > #8  0x0804a420 in main (argc=2, argv=0xbfc803a4) at hobbitd_rrd.c:349
> >
>
> The first part (lines 93-96 according to the lines on the side) of hunk 4
> (the
> "Line 79 Line 90" one) of this patch should have fixed this:
>
>
> http://hobbitmon.svn.sf.net/viewvc/hobbitmon/branches/4.3.0/hobbitd/rrd/do_devmon.c?r1=6171&r2=6222
>
> This was forward-ported from the fixes for 4.2.x. I will try and test this
> myself the coming weekend.
>
> Regards,
> Buchan
>

Re: [Devmon] [hobbit] Re: Devmon causing core dumps

[Mario A. P. <row...@gm...>]

Buchan,


The revision 164 do_devmon.c from the devmon svn was working good with 4.2.3

After upgrade to 4.3.0 beta2 the revision 6171 and 6222 ( from xymon svn) do
not work.
Even with the last branch 4.3.0 from the svn I'm having lot of core files
and rrdctl. files?
Do you know why the rrdctl files?

But my question is what changes are really necessary at the revision 164 in
order to work with 4.3.0 ?


The diff is between 164(devmon) and 6222(svn xymon) :

diff xymon-4.2.3/hobbitd/rrd/do_devmon.c diff/6222
4c4
< /* Copyright (C) 2004-2006 Henrik Storner <he...@hs...>
*/
---
> /* Copyright (C) 2004-2009 Henrik Storner <he...@hs...>
*/
14c14
< int do_devmon_rrd(char *hostname, char *testname, char *msg, time_t
tstamp)
---
> int do_devmon_rrd(char *hostname, char *testname, char *classname, char
*pagepaths, char *msg, time_t tstamp)
18c18
<       static char *devmon_tpl      = NULL;
---
>       static void *devmon_tpl      = NULL;
68,69d67
<                       devmon_params[0] = "rrdcreate";
<                       devmon_params[1] = rrdfn;
74c72
<                               devmon_params[numds+2] =
xstrdup(columns[numds]);
---
>                               devmon_params[numds] =
xstrdup(columns[numds]);
78,82c76
<                       devmon_params[numds+2] = rra1;
<                       devmon_params[numds+3] = rra2;
<                       devmon_params[numds+4] = rra3;
<                       devmon_params[numds+5] = rra4;
<                       devmon_params[numds+6] = NULL;
---
>                       devmon_params[numds] = NULL;
115,116c109
<               snprintf(rrdfn, sizeof(rrdfn)-1, "%s.%s.rrd", rrdbasename,
ifname);
<               rrdfn[sizeof(rrdfn)-1] = '\0';
---
>               setupfn2("%s.%s.rrd", rrdbasename, ifname);
118c111
<               create_and_update_rrd(hostname, rrdfn, devmon_params,
devmon_tpl);
---
>               create_and_update_rrd(hostname, testname, classname,
pagepaths, devmon_params, devmon_tpl);
127a121
>

Thanks in advance,

Mario.




On Wed, Mar 31, 2010 at 12:21 PM, Mario Andre Panza
<row...@gm...>wrote:

> HI Bunchan, How are ayou?!
>
> I'm still having problems with the revision 6222, do you have a new
> revision?
>
> Thanks in advance,
>
> Mario.
>
>
> #0  0x00cf8402 in __kernel_vsyscall ()
>
> #1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
> #2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
> #3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
> #4  <signal handler called>
> #5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
>  #6  0x0804e750 in do_devmon_rrd (hostname=0xb7f5e337 "b304-s10",
> testname=0xb7f5e340 "if_load",
>     classname=0xb7f5e374 "imation/imation_network/Infrastructure_Devices",
> pagepaths=0x80700be "",
>     msg=0xb7f5e3a3 "status b304-s10.if_load green Wed Mar 31 09:37:26
> 2010", tstamp=1270039405) at rrd/do_devmon.c:87
> #7  0x080598e4 in update_rrd (hostname=0xb7f5e337 "b304-s10",
> testname=0xb7f5e340 "if_load",
>     msg=0xb7f5e3a3 "status b304-s10.if_load green Wed Mar 31 09:37:26
> 2010", tstamp=1270039405, sender=0xb7f5e328 "129.220.11.51",
>     ldef=0x857fd08, classname=0xb7f5e374
> "imation/imation_network/Infrastructure_Devices", pagepaths=0x80700be "") at
> do_rrd.c:649
> #8  0x0804a420 in main (argc=2, argv=0xbfe26434) at hobbitd_rrd.c:349
>
> [New process 5633]
> #0  0x00bd6402 in __kernel_vsyscall ()
> (gdb) bt
> #0  0x00bd6402 in __kernel_vsyscall ()
>
> #1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
> #2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
> #3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
> #4  <signal handler called>
> #5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
>  #6  0x0804e704 in do_devmon_rrd (hostname=0xb7ed434b "neuss-r1",
> testname=0xb7ed4354 "if_load",
>     classname=0xb7ed4388 "imation/imation_network/Infrastructure_Devices",
> pagepaths=0x80700be "",
>     msg=0xb7ed43b7 "status neuss-r1.if_load green Wed Mar 31 09:38:02
> 2010", tstamp=1270039405) at rrd/do_devmon.c:83
> #7  0x080598e4 in update_rrd (hostname=0xb7ed434b "neuss-r1",
> testname=0xb7ed4354 "if_load",
>     msg=0xb7ed43b7 "status neuss-r1.if_load green Wed Mar 31 09:38:02
> 2010", tstamp=1270039405, sender=0xb7ed433c "129.220.11.51",
>     ldef=0x8fe97f8, classname=0xb7ed4388
> "imation/imation_network/Infrastructure_Devices", pagepaths=0x80700be "") at
> do_rrd.c:649
> #8  0x0804a420 in main (argc=2, argv=0xbffe0854) at hobbitd_rrd.c:349
>
> [New process 32473]
> #0  0x00bee402 in __kernel_vsyscall ()
> (gdb) bt
> #0  0x00bee402 in __kernel_vsyscall ()
>
> #1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
> #2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
> #3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
> #4  <signal handler called>
> #5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
>  #6  0x0804e750 in do_devmon_rrd (hostname=0xb7fb0e0a "b304-s2",
> testname=0xb7fb0e12 "if_load",
>     classname=0xb7fb0e46 "imation/imation_network/Infrastructure_Devices",
> pagepaths=0x80700be "",
>     msg=0xb7fb0e75 "status b304-s2.if_load green Wed Mar 31 08:22:07 2010",
> tstamp=1270034884) at rrd/do_devmon.c:87
> #7  0x080598e4 in update_rrd (hostname=0xb7fb0e0a "b304-s2",
> testname=0xb7fb0e12 "if_load",
>     msg=0xb7fb0e75 "status b304-s2.if_load green Wed Mar 31 08:22:07 2010",
> tstamp=1270034884, sender=0xb7fb0dfb "129.220.11.51",
>     ldef=0x9635758, classname=0xb7fb0e46
> "imation/imation_network/Infrastructure_Devices", pagepaths=0x80700be "") at
> do_rrd.c:649
> #8  0x0804a420 in main (argc=2, argv=0xbfb1c324) at hobbitd_rrd.c:349
>
>
> [New process 29610]
> #0  0x00ddb402 in __kernel_vsyscall ()
> (gdb) bt
> #0  0x00ddb402 in __kernel_vsyscall ()
>
> #1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
> #2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
> #3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
> #4  <signal handler called>
> #5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
>  #6  0x0804e704 in do_devmon_rrd (hostname=0xb7f18544 "b304-s4",
> testname=0xb7f1854c "if_load",
>     classname=0xb7f18580 "imation/imation_network/Infrastructure_Devices",
> pagepaths=0x80700be "",
>     msg=0xb7f185af "status b304-s4.if_load green Wed Mar 31 07:37:03 2010",
> tstamp=1270032173) at rrd/do_devmon.c:83
> #7  0x080598e4 in update_rrd (hostname=0xb7f18544 "b304-s4",
> testname=0xb7f1854c "if_load",
>     msg=0xb7f185af "status b304-s4.if_load green Wed Mar 31 07:37:03 2010",
> tstamp=1270032173, sender=0xb7f18535 "129.220.11.51",
>     ldef=0x93c45c8, classname=0xb7f18580
> "imation/imation_network/Infrastructure_Devices", pagepaths=0x80700be "") at
> do_rrd.c:649
> #8  0x0804a420 in main (argc=2, argv=0xbff54ef4) at hobbitd_rrd.c:349
>
> #0  0x00aac402 in __kernel_vsyscall ()
> (gdb) bt
> #0  0x00aac402 in __kernel_vsyscall ()
>
> #1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
> #2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
> #3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
> #4  <signal handler called>
> #5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
>  #6  0x0804e750 in do_devmon_rrd (hostname=0xb7ee3151 "b304-s3",
> testname=0xb7ee3159 "if_load",
>     classname=0xb7ee318d "imation/imation_network/Infrastructure_Devices",
> pagepaths=0x80700be "",
>     msg=0xb7ee31bc "status b304-s3.if_load green Wed Mar 31 05:51:59 2010",
> tstamp=1270025883) at rrd/do_devmon.c:87
> #7  0x080598e4 in update_rrd (hostname=0xb7ee3151 "b304-s3",
> testname=0xb7ee3159 "if_load",
>     msg=0xb7ee31bc "status b304-s3.if_load green Wed Mar 31 05:51:59 2010",
> tstamp=1270025883, sender=0xb7ee3142 "129.220.11.51",
>     ldef=0x8b5fb40, classname=0xb7ee318d
> "imation/imation_network/Infrastructure_Devices", pagepaths=0x80700be "") at
> do_rrd.c:649
> #8  0x0804a420 in main (argc=2, argv=0xbfcfea64) at hobbitd_rrd.c:349
>
>
>
>
>
> On Wed, Feb 10, 2010 at 7:34 AM, Buchan Milne <bg...@st...>wrote:
>
>> On Tuesday, 9 February 2010 19:41:19 mario andre wrote:
>> > Hi Bunchan,
>> >
>> > I've got lot of core with rev 6222.
>> >
>> > -------------------- Core files with do_devmon.c from revision 6222
>> >
>> > [root@isslu410 core_old]# gdb ../../bin/hobbitd_rrd core.6545
>> > GNU gdb Fedora (6.8-37.el5)
>> > Copyright (C) 2008 Free Software Foundation, Inc.
>> > License GPLv3+: GNU GPL version 3 or later
>> >  <http://gnu.org/licenses/gpl.html
>> >
>> > This is free software: you are free to change and redistribute it.
>> > There is NO WARRANTY, to the extent permitted by law.  Type "show
>> copying"
>> > and "show warranty" for details.
>> > This GDB was configured as "i386-redhat-linux-gnu"...
>> > Cannot access memory at address 0x524149
>> > (gdb) bt
>> > #0  0x0086a402 in ?? ()
>> > #1  0x00513040 in ?? ()
>> > #2  0x0062eff4 in ?? ()
>> > #3  0xb7f636c0 in ?? ()
>> > #4  0xbf94c2c8 in ?? ()
>> > #5  0x00514a21 in ?? ()
>> > #6  0x00000006 in ?? ()
>> > #7  0xbf94c23c in ?? ()
>> > #8  0x00000000 in ?? ()
>> >
>>
>> This binary is stripped, so this backtrace is quite useless. It would help
>> if
>> you could try again with a non-stripped hobbitd_rrd with debugging
>> enabled.
>>
>>
>> > ----------------- COre files with original do_devmon.c from xymon 4.3.0
>> > beta2
>> >
>> > (gdb) bt
>> > #0  0x00fc7402 in __kernel_vsyscall ()
>> > #1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
>> > #2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
>> > #3  0x08069eb3 in sigsegv_handler (signum=11) at sig.c:57
>> > #4  <signal handler called>
>> > #5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
>> > #6  0x0804e704 in do_devmon_rrd (hostname=0xb7f0f6ab "Cisco_4507R_02",
>> > testname=0xb7f0f6ba "if_load",
>> >     classname=0xb7f0f6ee "cosc/network/601_El_Camino_Real,cosc/temp",
>> > pagepaths=0x80700be "",
>> >     msg=0xb7f0f718 "status Cisco_4507R_02.if_load green Wed Feb  3
>> 20:12:57
>> > 2010", tstamp=1265256364) at rrd/do_devmon.c:83
>> > #7  0x080598e4 in update_rrd (hostname=0xb7f0f6ab "Cisco_4507R_02",
>> > testname=0xb7f0f6ba "if_load",
>> >     msg=0xb7f0f718 "status Cisco_4507R_02.if_load green Wed Feb  3
>> 20:12:57
>> > 2010", tstamp=1265256364, sender=0xb7f0f69b "172.29.186.131",
>> >     ldef=0x8f4cb08, classname=0xb7f0f6ee
>> > "cosc/network/601_El_Camino_Real,cosc/temp", pagepaths=0x80700be "") at
>> > do_rrd.c:649
>> > #8  0x0804a420 in main (argc=2, argv=0xbfc803a4) at hobbitd_rrd.c:349
>> >
>>
>> The first part (lines 93-96 according to the lines on the side) of hunk 4
>> (the
>> "Line 79 Line 90" one) of this patch should have fixed this:
>>
>>
>> http://hobbitmon.svn.sf.net/viewvc/hobbitmon/branches/4.3.0/hobbitd/rrd/do_devmon.c?r1=6171&r2=6222
>>
>> This was forward-ported from the fixes for 4.2.x. I will try and test this
>> myself the coming weekend.
>>
>> Regards,
>> Buchan
>>
>
>

Re: [Devmon] [hobbit] Re: Devmon causing core dumps

[Mario A. P. <row...@gm...>]

Hi all,

I´m getting a lot of core files because of devmon if_load tests for a cisco
6509.

I´m running xymon4.3.0-beta2, I´ve already tried xymon-4.3.0.-beta2 latest
branch with do_devmon.c revision 6222 with no success.
My rrdtool version is 1.3.9.

This core is generated with the default package from xymon-4.3.0-beta2

#0  0x0063b402 in __kernel_vsyscall ()
#1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
#2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
#3  0x08069e93 in sigsegv_handler (signum=11) at sig.c:57
#4  <signal handler called>
#5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
#6  0x0804e6e4 in do_devmon_rrd (hostname=0xb7b42207 "neuss-r1",
testname=0xb7b42210 "if_load",
    classname=0xb7b42244 "imat/imat_network/Infrastructure_Devices",
pagepaths=0x807009e "",
    msg=0xb7b42273 "status neuss-r1.if_load green Mon Apr  5 14:20:17 2010",
tstamp=1270488357) at rrd/do_devmon.c:83
#7  0x080598c4 in update_rrd (hostname=0xb7b42207 "neuss-r1",
testname=0xb7b42210 "if_load",
    msg=0xb7b42273 "status neuss-r1.if_load green Mon Apr  5 14:20:17 2010",
tstamp=1270488357, sender=0xb7b421f8 "199.200.11.51",
    ldef=0x8506588, classname=0xb7b42244
"imat/imat_network/Infrastructure_Devices", pagepaths=0x807009e "") at
do_rrd.c:649
#8  0x0804a400 in main (argc=3, argv=0xbf88c524) at hobbitd_rrd.c:349

Does anyone here is facing the same problem?

Thanks in advance,

Mario.










On Wed, Mar 31, 2010 at 5:28 PM, Mario Andre Panza
<row...@gm...>wrote:

> Buchan,
>
>
> The revision 164 do_devmon.c from the devmon svn was working good with
> 4.2.3
>
> After upgrade to 4.3.0 beta2 the revision 6171 and 6222 ( from xymon svn)
> do not work.
> Even with the last branch 4.3.0 from the svn I'm having lot of core files
> and rrdctl. files?
> Do you know why the rrdctl files?
>
> But my question is what changes are really necessary at the revision 164 in
> order to work with 4.3.0 ?
>
>
> The diff is between 164(devmon) and 6222(svn xymon) :
>
> diff xymon-4.2.3/hobbitd/rrd/do_devmon.c diff/6222
> 4c4
> < /* Copyright (C) 2004-2006 Henrik Storner <he...@hs...>
> */
> ---
> > /* Copyright (C) 2004-2009 Henrik Storner <he...@hs...>
> */
> 14c14
> < int do_devmon_rrd(char *hostname, char *testname, char *msg, time_t
> tstamp)
> ---
> > int do_devmon_rrd(char *hostname, char *testname, char *classname, char
> *pagepaths, char *msg, time_t tstamp)
> 18c18
> <       static char *devmon_tpl      = NULL;
> ---
> >       static void *devmon_tpl      = NULL;
> 68,69d67
> <                       devmon_params[0] = "rrdcreate";
> <                       devmon_params[1] = rrdfn;
> 74c72
> <                               devmon_params[numds+2] =
> xstrdup(columns[numds]);
> ---
> >                               devmon_params[numds] =
> xstrdup(columns[numds]);
> 78,82c76
> <                       devmon_params[numds+2] = rra1;
> <                       devmon_params[numds+3] = rra2;
> <                       devmon_params[numds+4] = rra3;
> <                       devmon_params[numds+5] = rra4;
> <                       devmon_params[numds+6] = NULL;
> ---
> >                       devmon_params[numds] = NULL;
> 115,116c109
> <               snprintf(rrdfn, sizeof(rrdfn)-1, "%s.%s.rrd", rrdbasename,
> ifname);
> <               rrdfn[sizeof(rrdfn)-1] = '\0';
> ---
> >               setupfn2("%s.%s.rrd", rrdbasename, ifname);
> 118c111
> <               create_and_update_rrd(hostname, rrdfn, devmon_params,
> devmon_tpl);
> ---
> >               create_and_update_rrd(hostname, testname, classname,
> pagepaths, devmon_params, devmon_tpl);
> 127a121
> >
>
> Thanks in advance,
>
> Mario.
>
>
>
>
>

Re: [Devmon] [hobbit] Re: Devmon causing core dumps

[White, B. <be...@fe...>]

Mario,

I am running on Red Hat 5.2 with Xymon 4.3.0-beta2, Devmon 0.3.1-beta1, rrd 1.2.23-1 without any core dumps.  I am monitoring a cisco 6509 and all graphs are working fine.

    .....Bruce  


 
 Bruce White
 Senior Enterprise Systems Engineer | Phone: 630-671-5169 | Fax: 630-893-1648 | be...@fe... | http://www.fellowes.com/
 
 
 
Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Fellowes, Inc.
 
-----Original Message-----
From: Mario Andre Panza [mailto:row...@gm...] 
Sent: Monday, April 05, 2010 4:12 PM
To: dev...@li...; ho...@hs...
Subject: Re: [Devmon] [hobbit] Re: Devmon causing core dumps

Hi all,

I´m getting a lot of core files because of devmon if_load tests for a cisco 6509.

I´m running xymon4.3.0-beta2, I´ve already tried xymon-4.3.0.-beta2 latest branch with do_devmon.c revision 6222 with no success.
My rrdtool version is 1.3.9.

This core is generated with the default package from xymon-4.3.0-beta2

#0  0x0063b402 in __kernel_vsyscall ()
#1  0x00513040 in raise () from /lib/i686/nosegneg/libc.so.6
#2  0x00514a21 in abort () from /lib/i686/nosegneg/libc.so.6
#3  0x08069e93 in sigsegv_handler (signum=11) at sig.c:57
#4  <signal handler called>
#5  0x0055a4c9 in strcat () from /lib/i686/nosegneg/libc.so.6
#6  0x0804e6e4 in do_devmon_rrd (hostname=0xb7b42207 "neuss-r1", testname=0xb7b42210 "if_load",
    classname=0xb7b42244 "imat/imat_network/Infrastructure_Devices",
pagepaths=0x807009e "",
    msg=0xb7b42273 "status neuss-r1.if_load green Mon Apr  5 14:20:17 2010",
tstamp=1270488357) at rrd/do_devmon.c:83
#7  0x080598c4 in update_rrd (hostname=0xb7b42207 "neuss-r1", testname=0xb7b42210 "if_load",
    msg=0xb7b42273 "status neuss-r1.if_load green Mon Apr  5 14:20:17 2010", tstamp=1270488357, sender=0xb7b421f8 "199.200.11.51",
    ldef=0x8506588, classname=0xb7b42244 "imat/imat_network/Infrastructure_Devices", pagepaths=0x807009e "") at
do_rrd.c:649
#8  0x0804a400 in main (argc=3, argv=0xbf88c524) at hobbitd_rrd.c:349

Does anyone here is facing the same problem?

Thanks in advance,

Mario.










On Wed, Mar 31, 2010 at 5:28 PM, Mario Andre Panza
<row...@gm...>wrote:

> Buchan,
>
>
> The revision 164 do_devmon.c from the devmon svn was working good with
> 4.2.3
>
> After upgrade to 4.3.0 beta2 the revision 6171 and 6222 ( from xymon 
> svn) do not work.
> Even with the last branch 4.3.0 from the svn I'm having lot of core 
> files and rrdctl. files?
> Do you know why the rrdctl files?
>
> But my question is what changes are really necessary at the revision 
> 164 in order to work with 4.3.0 ?
>
>
> The diff is between 164(devmon) and 6222(svn xymon) :
>
> diff xymon-4.2.3/hobbitd/rrd/do_devmon.c diff/6222
> 4c4
> < /* Copyright (C) 2004-2006 Henrik Storner <he...@hs...> */
> ---
> > /* Copyright (C) 2004-2009 Henrik Storner <he...@hs...>
> */
> 14c14
> < int do_devmon_rrd(char *hostname, char *testname, char *msg, time_t
> tstamp)
> ---
> > int do_devmon_rrd(char *hostname, char *testname, char *classname, 
> > char
> *pagepaths, char *msg, time_t tstamp)
> 18c18
> <       static char *devmon_tpl      = NULL;
> ---
> >       static void *devmon_tpl      = NULL;
> 68,69d67
> <                       devmon_params[0] = "rrdcreate";
> <                       devmon_params[1] = rrdfn;
> 74c72
> <                               devmon_params[numds+2] =
> xstrdup(columns[numds]);
> ---
> >                               devmon_params[numds] =
> xstrdup(columns[numds]);
> 78,82c76
> <                       devmon_params[numds+2] = rra1;
> <                       devmon_params[numds+3] = rra2;
> <                       devmon_params[numds+4] = rra3;
> <                       devmon_params[numds+5] = rra4;
> <                       devmon_params[numds+6] = NULL;
> ---
> >                       devmon_params[numds] = NULL;
> 115,116c109
> <               snprintf(rrdfn, sizeof(rrdfn)-1, "%s.%s.rrd", rrdbasename,
> ifname);
> <               rrdfn[sizeof(rrdfn)-1] = '\0';
> ---
> >               setupfn2("%s.%s.rrd", rrdbasename, ifname);
> 118c111
> <               create_and_update_rrd(hostname, rrdfn, devmon_params,
> devmon_tpl);
> ---
> >               create_and_update_rrd(hostname, testname, classname,
> pagepaths, devmon_params, devmon_tpl);
> 127a121
> >
>
> Thanks in advance,
>
> Mario.
>
>
>
>
>
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Devmon-support mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devmon-support