Hi (Martin?)
Please could you give me an update on progress resolving the issue
identified below? I've looked at the changelog for recent versions
of Monit but haven't been able to determine if the refactoring of
the test scheduler that you mentioned had began, has now been
completed.
Regards
Struan
On 23/06/2015 10:16, Martin Pala wrote:
There are many more changes in progress (process
engine refactoring, etc.) … may take ca. 1-2 months.
Thanks for
the swift response, and that's great to hear. Based on
your experience, do you think this is likely to take weeks
or months before being available?
On 22/06/2015 20:13, Martin
Pala wrote:
Hi,
the refactoring of the test scheduler
mentioned in the manual with fix for program execution
already begun.
Regards,
Martin
Hi
I'd like to query the rationale for a behaviour
I've experiencing in monit. I'm testing with the
following config:
# Test config start
set daemon 10
check program MyProgram with path "/bin/dash -c
'echo OK!; exit 1'"
every "06 * * * *"
if status != 0 then alert
# Test config end
As expected, monit runs the dash test program at
6 minutes past the hour. The dash script
finishes immediately. However, Monit doesn't
pick up, report or alert on the exit code in a
timely manner. Until the next time Monit is
scheduled to run the test script, the dash
script remains as a zombie. But that is an hour
later, which is a long time to wait to be
alerted to the script failing.
If the 'every' schedule was "06 0 * * *" then it
would seem one should expect to wait 24 hours
before being alerted to the script failing!
I realise the Monit manual explains:
"The asynchronous nature of the program check
[...] comes with a side-effect: when the program
has finished executing and is waiting for Monit
to collect the result, it becomes a so-called
"zombie" process [...] the zombie process is
removed from the system as soon as Monit
collects the exit status. This means that every
"check program" will be associated with either a
running process or a temporary zombie. This
unwanted zombie side-effect will be removed in a
later release of Monit."
That may be so, however why doesn't Monit reap
the child and collect the exit code at the *next
poll cycle after the child exits* (i.e. within
10 seconds of the test script finishing given
the 'set daemon 10' line in the test config
above) rather than when the program is next
scheduled to be run? Maybe I'm missing
something, but the current behaviour seems to
undermine the entire purpose of providing alerts
on program failure (when used in conjunction
with cron-style scheduling). That is the
behaviour I'd like to query the rationale for.
Thanks in advance.
Kind regards
Struan
--
To unsubscribe:
https://lists.nongnu.org/mailman/listinfo/monit-general
--
To unsubscribe:
https://lists.nongnu.org/mailman/listinfo/monit-general
--
Struan
Bartlett
NewsNow.co.uk
The UK's #1 News Portal:
> www.NewsNow.co.uk (est.
1998)
Tel: |
+44 (0)845 838 8890 |
Fax: |
+44 (0)845 838 8898 |
NewsNow
Publishing Limited, trading also as NewsNow.co.uk, is a
company registered in England and Wales under company no.
3435857 with registered office The Euston Office, 1 Euston
Square, 40 Melton Street, London NW1 2FD
|