[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [monit] monit fails mysteriously on refresh after upgrade from Debia

From: Martin Pala
Subject: Re: [monit] monit fails mysteriously on refresh after upgrade from Debian etch to lenny
Date: Tue, 24 Feb 2009 23:52:43 +0100
User-agent: Thunderbird (X11/20090105)

Jenny Hopkins wrote:
2009/2/24 Martin Pala <address@hidden>:
The configuration looks good. The problem is very strange - Monit cannot die
this way without either crash or receiving signal to stop.

Please can you run monit with "-vI" options? The -v enable verbose as you
did + the -I will let in run in foreground.

1.) stop monit

2.) enable coredumps:
ulimit -c unlimited

3.) start monit verbose/foreground:
monit -vI

... you will see the same verbose output, but in terminal. If monit will
crash or receive signal to stop, you will get message about it (as well if
there will be any other error).

Martin - great! At last we have an error trapped:

sudo /usr/sbin/monit -d 10 -vI -c /etc/monit/monitrc -s
Last three lines -
'xinetd' PID has not changed since last cycle
'xinetd' PPID has not changed since last cycle
Floating point exception (core dumped)

Does this mean anything?

floating point exception could bean divide by zero ... one matching bug was fixed in upcoming monit-5.x:

* Fixed possible crash when monit is watching VPS environment on
  Linux which reports number of CPUs as 0. Thanks to Marius
  Schmidt for report.

=> is monit running in virtual environment? if so (and if linux host reports 0 CPUs), upgrade to monit 5.x will solve the problem. You can get the monit source code here:

To get the root cause, you can analyze the coredump using gdb:

1.) gdb <path to monit> <path to coredump>
2.) bt

This will show backtrace and also allows to compare the data. If you will need help, let me know.

(By the way: do I need to turn coredump enabling off again?)

coredumps are usually helpful for root causing crashes - you can disbale it, but in general it doesn't hurt - i usually use it everywhere in production so if something bad happens to any process, it's possible to backtrace the reason


reply via email to

[Prev in Thread] Current Thread [Next in Thread]