
Short FAQ:
----------


1. Q: Monit watches services by a pid file, so if a program crashes
   without removing its pid file, then monit won't recognize it,
   right?

   A: Wrong. Monit will always check that a pid in a pid file belongs
   to a *running* process. If a program crashes and dies in a "normal"
   manner, then the process ID (pid) will not exist and monit will
   know that the program is not running (and restart it) even if a pid
   file exist. However, some badly implemented servers *can* crash and
   leave a zombie process, and appeare to run. In such cases the port
   check is handy, a zombie process will not pass this test and the
   program will be restarted by monit, see also the next answer.


2. Q: I want to watch the XYZ server, unfortunately monit does not
   support the XYZ protocol. And an XYZ server won't send you a welcome
   message which can easily be checked.

   A: That is not a problem, if monit does not support the XYZ
   protocol just use the default port connection check. This check is
   in most cases, more than good enough. You simply use:

    port XYZ-portnumber

   in the monitrc file, monit will open a connection to this port (TCP
   or UDP) and check that it is possible to send and recieve data from
   the port (via the select system call). If the connection fails or
   if the port connection does not respond, monit will restart the
   program.


3. Q: I have a program that does not create its own pid file. Since
   monit requires all programs to have a pid file, what do I do?

   A: Create a wrapper script and have the script create a pid file
   before it starts the program. Below you will find an example script
   for starting an imaginary program (a Java program in this case).
   Assuming that the script is saved in a file called /bin/program,
   you can call this script from monit by using the following in
   monitrc:

   check program with pidfile /tmp/program.pid
    start="/bin/program start"
    stop ="/bin/program stop"


   --8<--- (cut here)

   #!/bin/bash
   export JAVA_HOME=/usr/local/java/
   export DISPLAY=localhost:0.0
   CLASSPATH=ajarfile.jar:.

   case $1 in

   start)
          echo $$ > /tmp/program.pid;
          exec 2>&1 java -cp ${CLASSPATH} com.someClassWithMain \
          1>/tmp/program.out 
          ;;
   stop)  kill `cat /tmp/program.pid` ;;
      *)  echo "usage: program {start|stop}";;

   esac
   
   --8<---- (cut here)


4. Q: Tomcat (The Jakarta Servlet Container) does not create a pid
      file and will put the server in the background.

   A: Edit The catalina.sh script and find and remove the '&'
   character which will put the Tomcat server in the background. Then
   call tomcats startup.sh and shutdown.sh scripts from a wrapper
   script like the one mentioned above.


5. Q: I have started monit with HTTP support but when I telnet into
      the monit http port the connection closes.

   A: If you use the host allow statement, monit will promptly close
   all connections from hosts it does not find in the host allow
   list. So make sure that you use the official name for your host
   or its IP address. If you have a firewall running also make sure
   that it does not block connections on the monit port.


6. Q: I'm having trouble getting monit to execute any "start" or
      "stop" program commands.  The log file says that they're being
      executed, and I can't find anything wrong when I run monit in
      verbose mode.

   A: There are two possibilities.

      1) Monit will fork off a new process before it execute a
         program.  Monit version 2.4 had a bug that will cause the
         child process to die under certain circumstances before it was
         able to start the program. Upgrade to a later version of
         monit or downgrade to version 2.3

      2) Monit did start the program but for some reason the program
         dies later. Before we go on and introduce you to the fine art
         of system debugging, it's worth to note that:

         a) For security reasons monit purges the environment and only
            set a spartan PATH variable that contains /bin, /usr/bin,
            /sbin and /usr/sbin. If your program or script dies, the
            reason could be that it expects certain variables or to
            find certain programs via the PATH. In this case there are
            two solutions, either set the environment variables you
            need, directly in the start/stop script, or change the
            method, set_sandbox() in the source file env.c, to contain
            the PATH and other variables your program will need.


7. Q: How can I run monit from init so it can be respawned in case it
      dies unexpectedly?

   A: Use either the 'set init' statement in monits configuration file
      or use the -I option from the command line. Here's a sample
      /etc/inittab entry for monit:

       # Run monit in standard runlevels
       mo:2345:respawn:/usr/local/sbin/monit -Ic /etc/monitrc

      After you have modified inits configuration file, you can run
      the following command to re-examine the runlevel and start
      monit:

       telinit q


HOW-TO debug: 

   a) Start monit

   b) Stop the program you want monit to monitor. Let's say sshd.

   c) Run: strace -f -p $(cat ~/.monit.pid) 2>&1|tee trace.out

   d) Wait for monit to wake up and try to start sshd. (Or wake up
      the monit daemon in another console by calling monit again)

   e) If you can see a line like this in the trace console with the
      very significant `= 0' at the end, it means that monit did in
      fact start sshd

   execve("/etc/init.d/sshd", ["/etc/init.d/sshd", "start"], [/* 1 var */]) = 0

   After this statement, monit is (probably) guiltless and you must
   search for the fault further down in the trace output.  Search for
   system calls that return -1, error codes like ENOENT or for the
   Segmentation fault signal, SIGSEGV).

   Here's a `grep' trick you can use to search in the output file from
   trace.
	  
     egrep "= -[0-9]*| E[A-Z]*|SIGSEGV" trace.out

   If you have problems understanding and reading the trace file; join
   the monit mailing list and send us the output from the trace with a
   description of the bug, the Unix system you are using, the monit
   version and your monitrc control file.
