I need a program that (I think) is called heartbeat daemon. On its
initialization it should read a configuration file that will describe
programs to run; periodically it will check if the programs are
running; if a program is not running - it will do something as
configured: invoke the program, send an alert/email etc.
If your deployment environment is Windows XP (and 2K3 and probably 2K
and even NT), you can run executables as "services" which can be
configured to auto-restart on exit, produce alerts (at least in the
event logs), or whatever.
If your deployment environment is almost anything else it's a full
POSIX system and you can probably do it with a shell script that
sleeps, then runs "ps" and greps its output in a loop, branching on
finding the desired process name back to the loop start, otherwise to
a line that reruns the process (in the background!), sends mail, or
similarly. In the latter case the script should background-run the
process before entering the loop, so you (re)start everything simply
by running the script. When it fails it should do its notification job
and exit. If it reruns the process, again the script itself can be
used to start the process as well as its monitoring. The script should
launch the process as a background task and then sleep before jumping
back to the start of the loop in the branch where the process is not
found to be running.
If you want a fancy GUI configurator or a cross-platform, Windows
included, tool that works similarly across all supported platforms,
and you want to use (obtopic) Java, you'll have to see if there's a
Java API for doing the equivalent of Unix/Linux "ps". If there is,
everything else is a piece of cake using additionally mainly familiar,
frequently-used Java APIs (plus System.exec() or similar).
On the other hand you probably want such a configurator not to run all
the time gobbling up memory, and particularly not at startup (Java
apps running at startup = bletch!), so you will need some kind of
lightweight back end (a script or C, most likely) with a .rc or .ini
file specifying details, and a graphical front-end to monitor the
processes, futz with the .rc file, catch notifications from the back
end, and the like. The script would run all the time, but the
configurator only when necessary. Obviously one thing the script could
do on failure is launch the configurator on the admin console, with a
command line parameter that means "sound the alarm!".
