Re: monit monitor.c monitor.h control.c

[rory]

Except for the fact that cervlet.c calls check_process directly, I believe
I'd have a recursion problem on my hand.
It seems that the only thing I have left to do is to nail down the precise
spot where I twiddle p->visited, as I'm now just slightly out of phase.
It didn't occur to me what was happening till I set some breakpoints in
gdb, then was trying to figure out why I didn't reach them... Oh yeah,
it's a separate process.
In any case, I think as we move forward with later releases, having an
external storage(db) will very much simplify things.
I'm also thinking we should maybe deprecate the mode where we run w/o the
server.
> Rory Toma <address@hidden> writes:
>
>> Log message:
>>      Fix the "clobbering" of p->do_validate. It wasn't really getting
>>      clobbered, rather, the second instance of monit was changing
>>      it's structure, and the running monit's structure was not being
>>      changed. We now pass this through cervlet.c so we change the
>>      correct structure.
>
> Good work! To bad I didn't have time to check this before since I
> think I would have nailed it pretty fast since I think this is more or
> less aligned with the original logic I used in version <= 3.0.
>
> Just a thought, if you move the code
>
> +      if( exist_daemon() ) {
> +     d_check_process(P, "stop");
>
> into check_process and do the test there you could save some space in
> monitor.c:do_action :-)
>
> --
> Jan-Henrik Haukeland
>
>
> _______________________________________________
> monit-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/monit-dev