
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: 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. Some servers *can* crash and leave a zombie
      process, and appeare to run. Monit does also test for zombie
      processes and will raise an alert if a process has become a
      zombie.


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

   A: Just use the default port connection check. This check is in
      most cases, more than good enough. You simply use:

       port FOO's-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 or test for an
      ICMP error in case of udp). 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/xyz, you can call this script from monit by using the
      following in monitrc:

      check xyz with pidfile /tmp/xyz.pid
        start="/bin/xyz start"
        stop ="/bin/xyz 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/xyz.pid;
           exec 2>&1 java -cp ${CLASSPATH} org.something.with.main \
           1>/tmp/xyz.out 
           ;;
          stop)  
           kill `cat /tmp/xyz.pid` ;;
          *)  
           echo "usage: xyz {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: 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:

      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 monit
      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
      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.
