monit-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Patch] Revised resource-support [aka. "proc"-support]


From: Jan-Henrik Haukeland
Subject: Re: [Patch] Revised resource-support [aka. "proc"-support]
Date: 13 Aug 2002 01:56:41 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service)

Christian Hopp <address@hidden> writes:

> I don't understand so much about software engineering and it's really
> impressing to me how you got it started and how keep it together.
> That's why I wanna keep you as the first author.
> *

This is appreciated!

> The thing is,  Linux can still use this feature as a normal user.

Indeed, so it seems, very cool

> I have defined so called "actions".  Right now there are "restart",
> "stop", "alert" and "ignore".  All of them reset the cycle counter to
> 0.  Of course you can mention e.g. cpuusage more then once that you
> get an alert if it's over 80% for 5 cycles and it stops if it's over
> 90% for 10 cycles.
> 
> For "ignore" you just get a log entry.
> 
> Unfortunately that option is mandatory otherwise I gonna get
> shifting/reducing options. 

That's why you see languages with constructs like IF expr THEN expr
ENDIF. But in this case what you want the parser to do is to reduce to
the production that has the no action ending:

resource_no_action -> if memkbyte is greated than 90M  for 2 cycles 
resource -> if memkbyte is greated than 90M  for 2 cycles then ACTION

Adding 
%left resource_no_action

Will fix the shift/reduce conflict, probably. If not, I should be able
to fix this when I get a copy of the new grammar.

> Hey it's the first time that I have to yacc and bison.  I am usually
> a heavy user of regex in high level languages to make configs. (-:

Yeah, but you have to admit that working with a real lexer and parser
is very cool stuff. For instance it would be impossible to parser all
the different variations of a monitrc with standard Perl regex.

> I had to define two new alerts... "stop" and "resource".  "resource"
> alert do happened when e.g. cpuusage throws and alert with the alert
> statement.  In any other case "stop" or "restart" is used.

Excellent

> We have a new "do_stop" function in validate.c.  There I first send
> the alert wait 3 seconds then stop it.  In case we might stop the mail
> server. (-:

Yeah, I found that out the hard way with restart :)

> > > 3) Web interface support (maybe with all the nice performance statistics)
> >
> > Yeah, that would be nice, after everything runs okay.
> 
> Too nice to wait for it... it's running. (-:

Now I'm really excited to see the new code!

> 2) Solaris does only check process data if is not a zombie.  /proc
> gets strongly reduced for zombies.

We should probably do: if zombie, then do restart right away without
bothering to test, or what do you think?

> the code is soon ready to be synced... but before that I need help
> with the FreeBSD stuff.  And it needs more testing.

I can only test a compile on FreeBSD on sourceforge, but cannot test
it under FreeBSD since I do not have root access. Anyway, when the
patch is ready we could release a beta version on freshmeat (there are
other changes done since 2.5 that justify a release), and then sit
back and wait for the bug reports.

> can we extend the "alerts" by "reasons".  A "restart" alert is nice
> but I would like to know if it has happened because it got a zombie or
> because of resources or user interaction....  This reason, e.g. a
> sting delivered to the alert engine, is somehow added to the body of
> the alert message.  I hope the idea is somehow clear?

I think I got it, and yeah sure this is doable.

-- 
Jan-Henrik Haukeland




reply via email to

[Prev in Thread] Current Thread [Next in Thread]