--On Monday, July 26, 2004 4:41 PM +0800 Christopher DeMarco <[EMAIL PROTECTED]> wrote:
Hi everybody... I really hope this isn't a FAQ (I did search the archives)...
Nope, not a FAQ. It's an impressively convoluted example, but I think I understand what you're trying to do.
I have a simple mon.cf in which I check http on "sunrise" and "sunset" and if both are down, perform an action. Downing the httpd processes causes the correct actions to be taken (file.alert). Once both hosts' httpd processes are down, the final alert is processed. Bringing them back up works as expected - the upalert is processed for each, but the monitor for the third isn't. When I bring both hosts down again, their individual alerts are processed, but the "both down" alert isn't - *even though its monitor is processed and returns 1*.
In my mon.cf (below) you'll see I'm using a custom ipvs alert (which I'll contribute after it's successfully in production) - but the file.alert isn't working either.
Please, what am I doing worng? Why won't successive outages trigger an alert which worked just fine for the first outage?
I think the problem is that you're somehow expecting the bugs:realservers service to magically get back into an OK state. That can only ever happen if the monitor script is run and returns 0. But you seem to have a fake monitor script that always returns 1. So no amount of dependency manipulation will solve that.
I think what you *really* want is to add an argument to http.monitor that causes it to only return failure if all servers are failing, and run it that way on on a service group with both machines in it. Then dependencies are irrelevant.
(Also, I think you have another problem here that you haven't noticed. You can only have one dependency entry on a service, so what you want is
'depend !sunrise:http && !sunset:http'. But thats not relevant to your problem, I just wanted to point it out so others don't get confused.)
You probably should be looking at the status of your services in Mon when running your test cases. Either via something simple like moncmd or monshow, or install the incredily useful (but slightly ugly) mon.cgi. I think you would have noticed that your service starts in the untested state, eventually goes to a failure state, and never becomes OK.
-David
David Nolan <*> [EMAIL PROTECTED] curses: May you be forced to grep the termcap of an unclean yacc while a herd of rogue emacs fsck your troff and vgrind your pathalias!
_______________________________________________ mon mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/mon
