Re: monit deadlocks

[Eli Yukelzon]

Well, the system seems to be stable.
thanks alot!

On 11/9/05, Eli Yukelzon <address@hidden> wrote:
> what's not to like about cvs? :)
> I'll give it a spin and report back.
> thanks alot!
>
> On 11/7/05, Martin Pala <address@hidden> wrote:
> > Thanks,
> >
> > current cvs version should solve the problem. Can you test the current
> > cvs version? If you don't like cvs, we can prepare snapshot for you.
> >
> > Thanks,
> > Martin
> >
> >
> > Eli Yukelzon wrote:
> > > hi there.
> > > well, after a week of delay the problem creeped up.
> > > here's the gdb output:
> > > Thread 2 (Thread -1211012176 (LWP 11591)):
> > > #0  0xffffe410 in ?? ()
> > > #1  0xb7d16388 in ?? ()
> > > #2  0x00000000 in ?? ()
> > > #3  0xb7d162f0 in ?? ()
> > > #4  0xb7ddc751 in ___newselect_nocancel () from /lib/libc.so.6
> > > #5  0x08051532 in can_read (socket=6, timeout=-514) at net.c:475
> > > #6  0x08063791 in start_httpd (port=2812, backlog=-514,
> > > bindAddr=0xfffffdfe <Address 0xfffffdfe out of bounds>)
> > >     at engine.c:647
> > > #7  0x0804f05c in thread_wrapper (arg=0x0) at http.c:160
> > > #8  0xb7fd83cd in start_thread () from /lib/libpthread.so.0
> > > #9  0xb7de31da in clone () from /lib/libc.so.6
> > >
> > > Thread 1 (Thread -1210952016 (LWP 11589)):
> > > #0  0xffffe410 in ?? ()
> > > #1  0xbffff050 in ?? ()
> > > #2  0x00000002 in ?? ()
> > > #3  0x00000000 in ?? ()
> > > #4  0xb7def13e in __lll_mutex_lock_wait () from /lib/libc.so.6
> > > #5  0xb7d8fa1b in _L_mutex_lock_2967 () from /lib/libc.so.6
> > > #6  0x00005a54 in ?? ()
> > > #7  0x00000000 in ?? ()
> > > #8  0xb7e40ff4 in ?? () from /lib/libc.so.6
> > > #9  0x00000000 in ?? ()
> > > #10 0x00000000 in ?? ()
> > > #11 0xbffff0b8 in ?? ()
> > > #12 0xb7da4590 in tzset_internal () from /lib/libc.so.6
> > > #13 0xb7da4590 in tzset_internal () from /lib/libc.so.6
> > > #14 0xb7da504e in tzset () from /lib/libc.so.6
> > > #15 0xb7da9c94 in strftime_l () from /lib/libc.so.6
> > > #16 0xb7da9b6f in strftime () from /lib/libc.so.6
> > > #17 0x0804f16b in log_log (s=0x0) at log.c:226
> > > #18 <signal handler called>
> > > #19 0xb7d8c52c in _int_malloc () from /lib/libc.so.6
> > > #20 0xb7d8dd59 in calloc () from /lib/libc.so.6
> > > #21 0x0805de78 in xcalloc (count=-1209784240, nbytes=-1209784240) at
> > > xmalloc.c:93
> > > #22 0x08064f80 in connectchild (parent=0xb7e40ff4, child=0x80b5a60) at
> > > process_common.c:163
> > > #23 0x080526dc in initprocesstree (pt_r=0x80b5a60, size_r=0x808c350,
> > > oldpt_r=0x2298, oldsize_r=0x808c348) at process.c:354
> > > #24 0x0805b49d in validate () at validate.c:140
> > > #25 0x08050eb3 in main (argc=0, argv=0xbffff8f4) at monitor.c:470
> > > #0  0xffffe410 in ?? ()
> > >
> > > any ideas?
> > >
> > > On 10/20/05, Jan-Henrik Haukeland <address@hidden> wrote:
> > >
> > >>On 20. okt. 2005, at 16.26, Eli Yukelzon wrote:
> > >>
> > >>
> > >>>Ok. I'll keep an eye on my servers, and see when it happens.
> > >>
> > >>Great, but as you can see from the output you sent, there are no
> > >>debug info in the backtrace.  Make sure that you run the monit binary
> > >>with debug info as explained in a previous mail. Do a test run and
> > >>make sure that the backtrace looks similar to the one I sent. I.e.
> > >>you must have stuff like this in the trace so we can find the
> > >>function creating problems.
> > >>
> > >>#2  0x08050d69 in can_read (socket=5, timeout=-514) at net.c:475
> > >>
> > >>instead of ?? like you have here,
> > >>
> > >>#3  0xb7d152f0 in ?? ()
> > >>
> > >>
> > >>Regards
> > >>
> > >>--
> > >>Jan-Henrik Haukeland
> > >>Mobil +47 97141255
> > >>
> > >>
> > >>
> > >>--
> > >>To unsubscribe:
> > >>http://lists.nongnu.org/mailman/listinfo/monit-general
> > >>
> > >
> > >
> > >
> > > --
> > > 2B OR NOT 2B = FF
> > >
> > >
> > > --
> > > To unsubscribe:
> > > http://lists.nongnu.org/mailman/listinfo/monit-general
> >
> >
> >
> > --
> > To unsubscribe:
> > http://lists.nongnu.org/mailman/listinfo/monit-general
> >
>
>
> --
> 2B OR NOT 2B = FF
>


--
2B OR NOT 2B = FF