Actually I think the behavior of the code now is correct, although not necessarily what you want, or what some people might expect.
In our mon environment we sometimes had a hostgroup or three that needed to be disabled for an extended period of time and we needed to make sure that the disabling configuration 'stuck' even when the mon server was reset. We used this feature of mon extensively. But I agree it may not be what you want.
Perhaps we need a "super reset" that also re-enables all hostgroups and maybe even re-scans in the auth.cf file. I've always found it a bit odd that none of the reset commands do the equivalent of a 'reload auth'. Your patch could then be something like:
if super reset {
@{$new_groups{$curgroup}} = split(/\s+/, $hosts);
reload("auth");
} else {
execute old code
}
At 07:10 PM 11/18/02 +0100, Erik Inge Bolsų wrote:
On Fri, 16 Aug 2002, Andrew Ryan wrote:
> If it is a bug, it's probably a big with mon, and not mon.cgi per se, since
> mon.cgi is just a mon client which executes a "reset" command on the server.
>
> It's worth trying to reproduce this same problem with the command line mon
> client, see if you get the same behavior. And to run the mon server in
> debug mode, to see the command which mon thinks is coming in.
Reproduced, tracked down and fixed. You're right, Andrew, it was a bug in
mon, present at least in 0.99.1 (which we still run on) and 0.99.2.
read_cf carried over disabled status of hosts, no matter what. After that,
reset_server called load_state only if keepstate was defined.
AFAICT, load_state should be enough to keep all state.
As a bonus, the only thing my patch does is remove code :)
Jim, please include in next release... patch attached.
--
Erik I. Bolsų, Triangel Software AS | Skybert AS
Tlf: 712 41 694 Mobil: 915 79 512
_______________________________________________ mon mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/mon
