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.