Re: configuration patch - final version

[Jan-Henrik Haukeland]

Christian Hopp <address@hidden> writes:

> Just a paranoia question... what if the monitrc has changed more
> recent then the state file?  Or... monit runs... you edit the
> monitrc (which is not reloaded automatically)... monit writes state
> file... and monit stop... and monit starts with state file and
> monitrc not fitting to each other?

We always initialize the process structure from the current monitrc
file like we do today and then only change processes found in *both*
the monitrc file and in the state file.

Consider:

 You change the control file and add a new process (B) so the monitrc
 file now contains the processes: A B and C. The running monit daemon
 only knows the processes A and C. Upon SIGHUP (or restart after a
 crash) the monit daemon first read the monitrc file and creates the
 process list structure with A B and C. We then read the state file
 and update the process A and C since they are found in the state
 file, B is not found in this file and therefore not changed. 

 The same strategy is used if you remove a process, e.g. lets say you
 remove process A from monitrc; so when reading the state file,
 process A is not found in the current process list (the list is
 always generated from monitrc) and therefore A is simply discarded.

 
Anyway this design strategy has to be tested and tried and probably
fine tuned a bit. So I suggest that we (me) start implementing this
*after* the 3.2 release on friday. What do you think?

-- 
Jan-Henrik Haukeland