Re: comments from freshmeat

[Rory Toma]

Perhaps, if you really want to start something and not monitor it, you
could edit the startup script to create a pid file with "1" in it, init
should always be running.

On Mon, 2003-11-03 at 09:43, Martin Pala wrote:
> Jan-Henrik Haukeland wrote:
> 
> >Martin Pala <address@hidden> writes:
> >
> >  
> >
> >>recently few comments appeared on freshmeat's monit page:
> >>    
> >>
> >
> >I saw it, but I didn't want to write a reply on freshmeat since
> >comments there are almost written in stone (it can take years before
> >they are removed) Instead here are some comments:
> >
> >  
> >
> >>*[?] **init-like process spawning and a bit more*
> >>by aldem <http://freshmeat.net/%7Ealdem/> - Oct 27th 2003 16:43:58
> >>
> >>It would be nice to have a possibility to spawn non-daemons as well -
> >>exactly like init does.
> >>
> >>Sometimes this is useful - and there is no need to specifically
> >>monitor pid files or something like this.
> >>
> >>Also, this would allow use of monit as a replacement for init (and
> >>daemontools as well).
> >>    
> >>
> >
> >It's possible of course, but will reduce the flexibility of monit
> >because then all programs monit should monitor *must* be started by
> >monit. This means that monit must be hooked tightly up to the sys.init
> >process, while now, monit *can* be used in conjunction with the init
> >process, but can also be used to monitor programs started by other
> >means. Besides monit is not just a process monitor any longer.
> >
> >That said, if we can keep the current flexibility but in addition add
> >configure options so monit (if so wanted) can "replace" the sys. init
> >system and the need for monit to know a process pid file, I'm for
> >it. But it's not something I feel is important since monit works fine
> >either way already (dosn't it?).
> >
> >  
> >
> >>The dependency on "cycles" is not always good thing, i.e. there is
> >>no clean way to define intervals in "if N restarts N..." statement -
> >>it would be nice to have something like "if N restart within T
> >>minutes/seconds/etc...".
> >>    
> >>
> >
> >This is a typical "nice to have" feature, but not important for normal
> >operation. I'm not sure either if it is a very useful feature. 
> >
> >But having some sort of a clock or a timer in monit that operates on
> >time and not only on cycles in a general context can be useful. I've
> >mentioned some ideas based on this a while ago, here (see the bottom
> >of the mail):
> >
> >http://mail.nongnu.org/archive/html/monit-general/2003-09/msg00026.html
> >
> >  
> >
> >>Optionally, would be nice to have custom actions for serveral levels
> >>of failures, i.e. - what to do on 1st failure, what to do on 2nd
> >>etc. failure (say, 1st time the service may be silently restarted,
> >>2nd-5th - restarted and warning will be sent, 6th failure - a
> >>warning is sent and the service is stopped.
> >>    
> >>
> >
> >Again a "nice to have feature" but not mandatory for normal operation.
> >If considered at all, I (at least) would put it at the very bottom of
> >the todo list.
> >
> >  
> >
> I agree.
> 
> Comments to the last point: it is partialy implemented - you can define:
> 
>  if cpu > 50% then alert
>  if cpu > 80% then restart
> 
> However it is not exactly the same thing that was asked by this user. In 
> the past we discussed model based on event per cycle ratio, like this:
> 
>  if X EVENT(S) within Y cycles then ACTION
> 
> where:
> 
>  X ... number of event occurences
>  EVENT ... type of event, like 'timestamp', ,size', 'checksum', 
> 'connection', etc.
>  Y ... cycles count
>  ACTION ... what to do, like 'restart', 'unmonitor', 'alert', etc.
> 
> Usage example:
> 
>  if cpu > 50% then alert # will send alert on first cpu related 
> 'resource' event occurence
>  if 5 resource within 5 cycles then exec "/do/something"  # do something 
> if the problem remains for 5 cycles
>  if 10 resource within 20 cycles then restart # restart the service if 
> the problem ratio exceeds 10 occurence within 20 cycles
> 
> This way it could be possible to stack actions based on error severity 
> (soft/hard/whatever).
> 
> Maybe in the future such feature could be implemented - what do you think?
> 
> Martin
> 
> 
> 
> _______________________________________________
> monit-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/monit-dev
-- 
Rory Toma               address@hidden
VP of Run Level 9       http://www.trs80.net
Digeo Digital           http://www.digeo.com

signature.asc
Description: This is a digitally signed message part