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 12:34:01 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service)

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. 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)

> [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. 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.

> 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.

> > > 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?

-- 
Jan-Henrik Haukeland




reply via email to

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