monit-dev
[Top][All Lists]
Advanced

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

CHECK PROCESS [was Re: Some ideas...]


From: Christian Hopp
Subject: CHECK PROCESS [was Re: Some ideas...]
Date: Wed, 24 Nov 2004 16:36:46 +0100 (CET)

On Wed, 24 Nov 2004, Jan-Henrik Haukeland wrote:

> > * This one might sound a bit esoteric but it might be useful.  The
> >   syntax for "check process" only supports pidfiles right now.  Mostly
> >   it is enough but some braindead daemon dont write pid files and some
> >   rc scripts are not writing them in some distros.  Well one could
> >   modify the rc script but it is being overwritten or changed when you
> >   install a new version of that package.  Well now the esoteric part.
> >   What about extending the "check process" syntax as followed:
> >
> >     CHECK PROCESS name [PIDFILE file|PGREP options regex]
>
> It looks like an interesting idea but it also has a certain hacking
> flavor and gives me flashback to my first monit script 20 years ago :-)
> i.e. "if [`ps -aux|egrep $name |wc -l` -gt 1 ] ; then .. else ..; fi"
> But since we can use our C code to scan /proc or  similar on BSD, it's
> not too bad. However my ideal solution for an alternative to pidfiles,
> which I also have mentioned before, is that monit actually start the
> process it should monitor and use e.g. signals to watch child processes
> status and restart them as needed. Much like init(8) does today. This
> solution is probably much harder to implement but IMHO has a cleaner
> design. Just my $0.002.  If I should vote for your suggestion I think
> it would be [-]0. I can absolutely see how it may be useful and I don't
> have any good arguments against it other than my stomach feeling which
> anyway often is proved to be wrong :-)

I know it's against what we fight for... a good daemon has a pid file
and that's what we monitor on!  The pro side is, you can use it to find
double stated daemons (who knows where it might come from).  You know
monit acts at bad times not when everything is alright. (:  It is ment
for flexibility... and just for those situtations where nothing else
works.

I know Reading /proc has always the risk of race conditions to get e.g.
the whole tree.  And for kmem it's not any better.  And it could be used
other way arround... to prevent certain pgreped tasks to run (killing of
setiathomes (: ).

Christian

-- 
Christian Hopp                                email: address@hidden
Institut für Elektrische Informationstechnik             fon: +49-5323-72-2113
TU Clausthal, Leibnizstr. 28, 38678 Clausthal-Zellerf.   fax: +49-5323-72-3197
                             pgpkey: https://www.iei.tu-clausthal.de/pgp-keys/





reply via email to

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