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