devmon-support — General Devmon support

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

[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 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
>

[Devmon] Loris Serena is out of the office.

[<lor...@pn...>]

I will be out of the office starting  29/03/2010 and will not return until
06/04/2010.

Please contact its...@pn... with any queries.

Re: [Devmon] Devmon Sensatronics template

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

On Tuesday, 23 March 2010 16:05:07 Thomas, Laura M. wrote:
> I have the starts on a Senatronics EM-1 template.  But because of the way
>  the EM-1 reports unused probes with a value of -999.9 I had to give up on
>  using devmon.  I couldn't get those probes to stop reporting as too cold
>  or too dry.  I would have had to have had four templates for the same
>  sensors based on if they had 1, 2, 3, or 4 probes attached.
> 
> I only ever got temp working because there wasn't much point in continuing
>  down the path.  I could forward what I have. If you would like it.
> 

If you were using branch OIDs, it should be possible to do something with this 
using exceptions.

However, I have come across the need to apply exceptions to OIDs other than 
the primary OID. If this is your issue here, this would be a new feature that 
I need to put more priority on. A bug could have been filed on this issue ...

In the case of the APC UPS templates, a similar issue was worked around with 
transforms and thresholds.

Regards,
Buchan

Re: [Devmon] Devmon snmp v3

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

On Thursday, 25 March 2010 15:22:59 mario andre wrote:
> Hi Buchan, How are you?
> 
> I will start to try a patch in order to devmon support snmp v3, Do you have
> any hint on what files change?

The biggest problem is that SNMP_Session doesn't have SNMPv3 support.

The funny thing is that SNMP_Session is by the MRTG people, but they seem to 
have abandoned it from a maintenance point of view, and they have hacked 
SNMPv3 support into MRTG using some other modules, when it would have made 
more sense to add it to SNMP_Session.

The other question here is whether we should consider switching SNMP modules, 
to Net::SNMP (which seems to be a fork or alternative to SNMP_Session), which 
already has SNMPv3 support, or SNMP (from the net-snmp project) which has 
SNMPv3 support as well as MIB parsing support.

Maybe for now we should just investigate how much effort it is to switch to a 
different SNMP module without any new features. While I would really like MIB 
parsing (which would reduce the amount of effort in supporting new devices), 
there are disadvantages (people need to have all the MIB files) and requiring 
net-snmp could be a limiting factor for people on proprietary unix systems 
(though for linux distros it shouldn't be an issue ... and I always run devmon 
on linux myself).

> or If the best way is to do like MRTG and
> create in devmon.cfg a flag to enable v3? In bbhosts you think should be a
> good way to put a user/password definition?

I think we could treat SNMPv3 credentials similarly to SNMPv1/v2c community 
names, by allowing a list of default usernames/passwords etc. in the 
devmon.cfg, but also allow per-host overrides in bb-hosts (for now).

> You are interested in work together?

Of course. I would very much like to see SNMPv3 support in devmon, but it is 
not personally my highest priority (for work purposes, where e.g. MIB parsing, 
and better SNMP trap management in Xymon are more urgent). So, I welcome any 
assistance.

For now it might be best for you to work from an svn checkout of trunk, and 
send me the output of (e.g.) 'svn diff' or similar. Once we have something in 
progress we can consider if you want svn commit access, or whether I commit 
your changes.

I will try and assist you where necessary, but for now I won't have time to 
actually work on the actual SNMPv3 support directly.

BTW, we may also want to start documenting some of our plans on the wiki ... I 
actually have a bit of a roadmap I should put there. If you're interested, it 
is at http://sourceforge.net/apps/mediawiki/devmon/ . Let me know if you can 
edit there, if not I might have to add you to the project.



Regards,
Buchan

[Devmon] Devmon snmp v3

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

Hi Buchan, How are you?

I will start to try a patch in order to devmon support snmp v3, Do you have
any hint on what files change? or If the best way is to do like MRTG and
create in devmon.cfg a flag to enable v3? In bbhosts you think should be a
good way to put a user/password definition?

You are interested in work together?


Best regards,

Mario.

[Devmon] Is There a WeatherMap Builder Anywhere That I Can Use?

[<wis...@ho...>]

I hate to ask, but I am finding it difficult to emulate my current Visio network drawings on WeatherMap.  I recently heard about someone who has a GUI weathermap builder.  I am looking for an easy way to create my map template and any help would be greatly appreciated.  I am using Devmon and Xymon, in case it matters.

Thanks all,

.vp

 		 	   		  

[Devmon] Loris Serena is out of the office.

[<lor...@pn...>]

I will be out of the office starting  23/03/2010 and will not return until
24/03/2010.

Please contact its...@pn... with any queries.

Re: [Devmon] Devmon Sensatronics template

[Thomas, L. M. <LMT...@st...>]

I have the starts on a Senatronics EM-1 template.  But because of the way the EM-1 reports unused probes with a value of -999.9 I had to give up on using devmon.  I couldn't get those probes to stop reporting as too cold or too dry.  I would have had to have had four templates for the same sensors based on if they had 1, 2, 3, or 4 probes attached. 

I only ever got temp working because there wasn't much point in continuing down the path.  I could forward what I have. If you would like it.

Laura Thomas

-----Original Message-----
From: Buchan Milne [mailto:bg...@st...] 
Sent: Tuesday, March 23, 2010 9:58 AM
To: dev...@li...
Subject: Re: [Devmon] Devmon Sensatronics template

On Saturday, 20 March 2010 16:34:38 Lárus Rafn Halldórsson wrote:
> Hello all
> 
> I am very new to Devmon but have got it up and working fine with all my
>  Cisco switches and Hobbit 4.2
> 
> I am using the Sensatronics E4 (www.sensatronics.com) environment monitor
>  to monitor temperature in my 2 data centers and am trying to make my own
>  template since I have not found it even after extensive search on the
>  internet.
> 
> 
> Does anyone have a template for the Sensatronics E4 series and could share
>  it?

I guess no one has one.

I can provide assistance if you have problems creating a template, and I would 
prefer to have new templates added to the template collection (in svn 
initially, subsequently in new template releases ... I hope to make a template 
release this month or next, but I have some in progress which I want to 
finish).


Regards,
Buchan

------------------------------------------------------------------------------
Download Intel® 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

Re: [Devmon] Devmon Sensatronics template

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

On Saturday, 20 March 2010 16:34:38 Lárus Rafn Halldórsson wrote:
> Hello all
> 
> I am very new to Devmon but have got it up and working fine with all my
>  Cisco switches and Hobbit 4.2
> 
> I am using the Sensatronics E4 (www.sensatronics.com) environment monitor
>  to monitor temperature in my 2 data centers and am trying to make my own
>  template since I have not found it even after extensive search on the
>  internet.
> 
> 
> Does anyone have a template for the Sensatronics E4 series and could share
>  it?

I guess no one has one.

I can provide assistance if you have problems creating a template, and I would 
prefer to have new templates added to the template collection (in svn 
initially, subsequently in new template releases ... I hope to make a template 
release this month or next, but I have some in progress which I want to 
finish).


Regards,
Buchan

[Devmon] Devmon Sensatronics template

[Lárus R. H. <la...@sl...>]

Hello all
 
I am very new to Devmon but have got it up and working fine with all my Cisco switches and Hobbit 4.2
 
I am using the Sensatronics E4 (www.sensatronics.com) environment monitor to monitor temperature in my 2 data centers and am trying to make my own template since I have not found it even after extensive search on the internet.
 
 
Does anyone have a template for the Sensatronics E4 series and could share it? 

Re: [Devmon] devmon keeps going purple

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

On Friday, 12 March 2010 23:24:09 Stef Coene wrote:
> On Thursday 11 March 2010, you wrote:
> > On Thursday 11 March 2010, you wrote:
> > > Really, someone who can reproduce this within a regular interval needs
> > > to test the current svn version.
> >
> > I deployed devmon to 3 xymon servers and all stay green.  More
> > installations are planned.
> > I will keep you informed if it turns purple.
> 
> I just got a devmon going purple.  The dm check is also purple.
> This is version 0.3.1-beta1.
> What can I do to help debugging?

Supply me the log file from the start of the last successful polling period, 
and the info on the dm test when it was purple (should show how many forks 
were active etc.).

Re: [Devmon] devmon keeps going purple

[Stef C. <ste...@do...>]

On Thursday 11 March 2010, you wrote:
> On Thursday 11 March 2010, you wrote:
> > Really, someone who can reproduce this within a regular interval needs to
> > test the current svn version.
> 
> I deployed devmon to 3 xymon servers and all stay green.  More
> installations are planned.
> I will keep you informed if it turns purple.
I just got a devmon going purple.  The dm check is also purple.
This is version 0.3.1-beta1.
What can I do to help debugging?


Stef

Re: [Devmon] devmon keeps going purple

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

On Thursday, 11 March 2010 08:15:18 Stef Coene wrote:
> On Thursday 11 March 2010, Buchan Milne wrote:
> > If the problem persists, watch to see if the dm test for the polling
> > device goes yellow or red, or polled devices go purple, and provide the
> > log contents for at least the last two poll cycles before any of these
> > changes (or, the relevant problems).
> 
> For debugging, maybe you can trap a USR signal and dump the internal status
> information in the logfile.  So when the status turns purple, you can debug
>  the running process.

Let's first see if the problem is fixed or not, and if not if the logging shows 
(over a period of hours) what happened.

Note that the changes to the dm test show enough (IMHO) of what the master 
knows about the forks. As far as I can tell, the forks end up just waiting for 
the master to give them something to do, so there would be very little useful 
information they could give us ...

> I also use this myself to force a process to re-read it's config files and
>  re- open the log files.

I've used HUP re-opening log files, config reading is done by running a separate 
process to populate the db, and the db is read on every poll interval, I don't 
see much benefit to changing other configuration on a running process.

Really, someone who can reproduce this within a regular interval needs to test 
the current svn version.

Regards,
Buchan

[Devmon] svn message

[Stef C. <ste...@do...>]

Hi,

When adding devmon to my own subversion repository, I noticed in 
templates/cisco-msfc2/cpu some files left by svn after a conflict.

-rw-r--r-- 1 xymon www-data  245 2008-02-04 14:28 message
-rw-r--r-- 1 xymon www-data  245 2008-02-04 14:28 message.mine
-rw-r--r-- 1 xymon www-data  184 2008-02-04 14:28 message.r23
-rw-r--r-- 1 xymon www-data  231 2008-02-04 14:28 message.r34


Stef

Re: [Devmon] devmon keeps going purple

[Stef C. <ste...@do...>]

On Thursday 11 March 2010, Buchan Milne wrote:
> If the problem persists, watch to see if the dm test for the polling device
> goes yellow or red, or polled devices go purple, and provide the log
> contents for at least the last two poll cycles before any of these changes
> (or, the relevant problems).
For debugging, maybe you can trap a USR signal and dump the internal status 
information in the logfile.  So when the status turns purple, you can debug the 
running process.
I also use this myself to force a process to re-read it's config files and re-
open the log files.


Stef

Re: [Devmon] devmon keeps going purple

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

On Friday, 19 February 2010 17:58:57 Young, Tom wrote:
> Hi,
> 
> I have one of three devmon pollers that keeps going purple, every few hours
>  or so. Running wireshark shows it completely stops communicating with the
>  xymon server. Is there a fix to this other than restarting it every time
>  it goes purple, or restarting it ever X hours?

In the various environments I have/have had devmon running, I have always had 
problems reproducing this problem within any useful timeframe.

E.g., in a previous position, the production environment had 2 servers polling 
a total of about 80 devices, and I would experience this problem about once in 
two weeks.

However, I have now committed some changes I have been working on, that should 
hopefully:

1)Log more information in case of any socket communication errors
2)Provide information on fork behaviour in the dm test for the polling host
3)Provide for terminating forks that seem to be stalled (by sending data to 
idle forks to ensure they are alive), as a workaround that should prevent 
having to have scripts to restart devmon
4)Add timeouts for all socket communication (using "alarm" and "eval"), 
hopefully fixing the original problem

If you can reproduce this issue with any better frequency, I would appreciate 
it if you could run the version currently in subversion (rev 180 or later). 
Preferably, run it in debug mode with high (5) verbosity, e.g.:

./devmon --debug -vvvvv -d /var/lib/devmon/hosts.db -c /etc/devmon.cfg

If the problem persists, watch to see if the dm test for the polling device 
goes yellow or red, or polled devices go purple, and provide the log contents 
for at least the last two poll cycles before any of these changes (or, the 
relevant problems).

Ideally, provide your feedback on the SF tracker:

https://sourceforge.net/tracker/index.php?func=detail&aid=2897345&group_id=160720&atid=816977

Regards,
Buchan

Re: [Devmon] snmp browser

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

On Wednesday, 10 March 2010 16:41:08 Stef Coene wrote:
> Hi,
> 
> I'm looking for a snmp browser for linux that's simple to use.
> I tried some, but most of them where difficult to use.

Unfortunately, it seems there aren't any that are that great. The best I have 
found so far is tkmib, from net-snmp.

I usually just use snmpwalk, but there is a script in the contrib directory in 
svn that may be of use to you (assuming this is for developing templates).

Regards,
Buchan

Re: [Devmon] clear status

[Stef C. <ste...@do...>]

On Wednesday 10 March 2010, Stef Coene wrote:
> On Wednesday 10 March 2010, Patrick Nixon wrote:
> > I'd be interested in the template when you get it squared away.
> 
> See attached file.
The attaced file is stiped by the mail daemon.
You can download if from www.docum.org/temp/brocade.tar


Stef

[Devmon] snmp browser

[Stef C. <ste...@do...>]

Hi,

I'm looking for a snmp browser for linux that's simple to use.
I tried some, but most of them where difficult to use.


Stef

Re: [Devmon] clear status

[Stef C. <ste...@do...>]

On Wednesday 10 March 2010, Patrick Nixon wrote:
> I'd be interested in the template when you get it squared away.
See attached file.

If you test this template and everything is ok, let me know.  I tested it 
against 4 or 5 different models.

For SAN switches in blade centers, I had to force the model/type in bb-hosts.  
So add DEVMON:model(brocade;SANswitch) in stead of DEVMON.

This template gives you a report on the overal SAN switch status and a list of 
sensors and status.


Stef

Re: [Devmon] clear status

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

On Wednesday, 10 March 2010 14:09:06 Stef Coene wrote:
> On Wednesday 10 March 2010, you wrote:

> > AFAIK this only works on the "primary repeater" at present. See below for
> > changes that should make this (skip absent sensors in the table) work.
> 
> Ok, it's working.  The absent lines are gone.
> Still, the clear or blue status can be handle.  I don't want the message to
>  go clear of blue, but just that we can add a clear of blue button.

Feel free to log a feature request tracker item, and then I will be reminded 
to look at it whenever I go through the tracker.

Regards,
Buchan

Re: [Devmon] clear status

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

On Wednesday, 10 March 2010 14:10:23 Stef Coene wrote:
> On Wednesday 10 March 2010, Patrick Nixon wrote:
> > I'd be interested in the template when you get it squared away.
> 
> Ok, I will keep the list informed.
> I have a sensor and status check for brocade SAN switchen.
> 
> What's the best place to post new templates ?

Tracker item (preferably logged with an sf user account, not anonymous) with 
category "template", attach svn diff or tarball.

This allows tracking contributions, feedback/questions about the template.

Once all issues are resolved, I will commit to svn, and all users can get it 
there until a new template release is made

Regards,
Buchan

[Devmon] Fwd: Re: clear status

[Stef C. <ste...@do...>]

I noticed I didn't replied to the list ...

----------  Forwarded Message  ----------

Subject: Re: [Devmon] clear status
Date: Wednesday 10 March 2010, 11:49:29
From: Buchan Milne <bg...@st...>
To: dev...@li...
CC: Stef Coene <ste...@do...>

On Wednesday, 10 March 2010 10:05:58 Stef Coene wrote:
> Hi,
> 
> I'm making a template for a brocade SAN switch.  I can monitor the sensors,
> but I want to skip some absent sensors.

Do you prefer them to be visible (and clear or green), or not visible.

> I tried to define a clear message for the absent sensons in the thresholds
> files.  But this causes the check to be dropped by devmon.  I was hoping
>  that I was able to put a clear bullet next to the absent sensors.

There is some special handling of the clear status, I will look into this ...

> I also tried to define an exception rules, but this is ignored by devmon.

AFAIK this only works on the "primary repeater" at present. See below for 
changes that should make this (skip absent sensors in the table) work.

> 
> 
> Stef
> 
> 
> oids
> sensorType    : .1.3.6.1.4.1.1588.2.1.1.1.1.22.1.2 : branch
> sensorStatus  : .1.3.6.1.4.1.1588.2.1.1.1.1.22.1.3 : branch
> sensorValue   : .1.3.6.1.4.1.1588.2.1.1.1.1.22.1.4 : branch
> sensorMessage : .1.3.6.1.4.1.1588.2.1.1.1.1.22.1.5 : branch
> 
> exceptions
Change this line:
> sensorStatus : ignore : 6
to:
sensorStatus2: ignore : absent

> 
> transforms
> sensorStatus2   : SWITCH   : {sensorStatus} 1 = unknown , 2 = faulty , 3 =
> below-min , 4 = nominal , 5 = above-max , 6 = absent
> 
> thresholds
> sensorStatus2 : red   : faulty, below-min, above-max, offline : Errors
>  detected 

Remove this line:

>  sensorStatus2 : clear : absent
> sensorStatus2 : green : online, nominal      : No errors detected
> 
> message
> TABLE:
> Sensor status | Sensor message | Sensor value
> {sensorStatus2.color} {sensorStatus2}|{sensorMessage}|{sensorValue}


Regards,
Buchan


-----------------------------------------