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

[Christian Hopp]

On 13 Aug 2002, Jan-Henrik Haukeland wrote:

> Christian Hopp <address@hidden> writes:
>
> > The new syntax is:
> >
> > <resource> <maxvalue> [<maxcycles>] [ACTION <action>]
>
> For the sake of symmetry, maybe we should add a "less" and "equal" as
> operators as well? BWT, like in Perl etcetera, a short version should
> be, gt, eq and lt.

Good idea, indeed. The maxvalue is transformed in limit and the
resource list gets an "operator" entry.  Shouldn't be a problem.

> Another thing, it doesn't make sense to have a
> resource statement without an action does it? And if you require an
> action you should also get out of the shift/reduce problem (and of
> course, you where right about that %left operates on tokens)

I think it makes sense to have a default action to make config files
less full.  But of course we can discuss about the default monit
should use.

> > [zombie processes]
>
> Hmm yes, on second thought this is actually a trickie one. Lets say
> this is apache httpd (won't happen but for the sake of the argument).
> The parent httpd process which monit monitors dies and become a zombie
> for some reasons, but it's children is still running and accepting
> connections should monit restart the httpd? after all it is working
> through it's children. Initially I would say, restart it, but maybe an
> alert is the best thing to do after all.

The thing to remember... most probably we won't be even able to restart!

> Are there others on this list that has any thoughts on this problem?

...

> > My idea... let's do the last bugfixings (if there are any) for the 2.5
> > series.  And we release 2.5.2 without the process feature.
>
> 2.5.1 isn't released yet, so we could use this one.

I thought so... haven't been there any fixes, by now?

> > It's gonna declared the last stable before 3.0.  And then we start
> > 2.9.x (alpha stage) to get the 3.0 features inside.
>
> A good idea, I have to remove the new udp check code then. But this
> code isn't exactely what I want anyway.

Maybe we should rest a bit about it and look in other implementations
(like netsaint they do dns testing et al.).

> > > > 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.
> >
> > It's gonna take a bit of changes in the code where restarts, stops,
> > starts happen (nearly everywhere).  Then we need witted "reasons" at
> > every place.
>
> We could do something along the lines:
>
>  smtp_alert_timeout(Process_T p, char *reason, ...);
>  smtp_alert_checksum(Process_T p, char *reason, ...);
>  smtp_alert_restart(Process_T p, char *reason, ...);
>
> Where reason may be the NULL string (for no reason) or a printf style
> format. Does this sound okay?

Yep.

C.Hopp

-- 
Christian Hopp                                email: address@hidden
Institut für Elektrische Informationstechnik             fon: +49-5323-72-2113
Technische Universität Clausthal                         fax: +49-5323-72-3197
  pgpkey: https://www.iei.tu-clausthal.de/pgp-keys/chopp.key.asc  (2001-11-22)