Monit <= 4.10.x used statefile as described in the manual ... it created
statefile on start and updated it every cycle - if monit crashed, it
recovered the state from this file.
To stop monit you can use "monit quit" or send monit SIGTERM signal.
If you call "monit stop <service>|all" it stops the service and disables
it's monitoring - it doesn't stop monit. If monit was killed, then the
service is not monitred on monit start since the unmonitred state was
restored.
If statefile is problem for you on boot and monit was not stopped
gracefully, you can place the statefile to tmp filesystem, so it is
dropped
on reboot - for example:
set statefile /tmp/monit.state
Monit 5.x stores the monitoring state persistently (decomentation was
updated accordingly).
Note that during restart the service is temporarily unmonitored - service
state can show for example "unmonitored -- restart pending".
Martin
Nick Upson wrote:
I appear to have a situation where sometimes (as usual :) ) after a
reboot monit shows all processes as unmonitored and they just stay
that way - this is my big problem, also sometimes they are all shown
as unmonitored but they they change to initialising etc.
this is monit 4.10, What is the way to stop monit normally (see below)
when it's run via inittab
I found these quotes:
"the state file is used just in case that monit was either reloaded
(for example using "monit reload" or SIGHUP) or crashed and was
started again to recover last state. If monit is stopped normally, the
state file is not used on next start (it's unlinked/deleted on stop).
To test the state persistence, you can try "monit reload" or kill -9
monit and start monit ... the state including monitoring mode should
recover. "
and, in answer to a request for the state to survive a reboot
"The state was changed to be persistent even across monit restarts, it
will be part of next monit release.
"
--
To unsubscribe:
http://lists.nongnu.org/mailman/listinfo/monit-general
--
To unsubscribe:
http://lists.nongnu.org/mailman/listinfo/monit-general