Re: [monit] state file persistence

[Nick Upson]

I think I overcomplicated my explanation,

I need to shutdown and restart the entire (fedora 8) system such that
all processes controlled by monit are always monitored and started by
monit when it restarts, this is from manual command, power failure or
anything else.

2009/2/24 Martin Pala <address@hidden>:
> 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
>