14 Mar 2008, 05:48
Generic-user-small

Frank (9 posts)

I recently picked up the beta version of Deploying Rails Applications and I’m trying to use the information in the book to setup monit to monitor and restart my cluster of mongrels.

I can get monit to monitor my mongrels but I haven’t been able to get monit to be able to stop or start my mongrels. The problem seems to be related to the spartan path that monit provides when starting or stopping programs. That path is PATH=/bin:/usr/bin:/sbin:/usr/sbin

And on my particular FreeBSD 6.3 system I cannot run the mongrel_rails command successfully unless /usr/local/bin is part of my path. If I run mongrel_rails without /usr/local/bin in my path I am rewarded with this error:

/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27: command not found:

Anyone else encounter this? Any ideas on how to solve it?

14 Mar 2008, 19:05
Generic-user-small

Frank (9 posts)

I’ve tried many different ways of specifying the start and stop commands in monit. For example, I just tried this:

start program = “/usr/bin/env PATH=/usr/local/bin:${PATH} mongrel_rails cluster::start -C /home/virtual/rails/myapp/current/config/mongrel_cluster.yml –clean –only 5050”

stop program = “/usr/bin/env PATH=/usr/local/bin:${PATH} mongrel_rails cluster::stop -C /home/virtual/rails/myapp/current/config/mongrel_cluster.yml –only 5050”

and still the monit log file reports:

[ Mar 14 11:43:07] info : ‘mongrel_myapp_5050’ stop: /usr/bin/env [ Mar 14 11:43:37] error : ‘mongrel_myapp_5050’ failed to stop

I am able to run those stop start commands manually from a shell in which I set the initial path to be the same one that monit sets (/bin:/usr/bin:/sbin:/usr/sbin) so I have no idea why it doesn’t work through monit.

Is there anyway to actually debug monit and see what its actually executing and see what error message it might encounter when trying to stop or start a program?

14 Mar 2008, 19:18
Generic-user-small

Frank (9 posts)

I’ve been able to come up with a solution to this problem. The solution is to add the following line to /usr/local/bin/mongrel_rails

ENV[‘PATH’] = “#{ENV[‘PATH’]}:/usr/local/bin”;

and then to have the stop/start commands in the monit config look as follows:

start program = ”/usr/local/bin/mongrel_rails cluster::start -C /home/virtual/rails/myapp/current/config/mongrel_cluster.yml—clean—only 5050”

stop program = “/usr/local/bin/mongrel_rails cluster::stop -C /home/virtual/rails/myapp/current/config/mongrel_cluster.yml –only 5050”

This isn’t really an ideal solution as my monit monitoring will break whenever I upgrade the mongrel_cluster gem.

07 Jun 2008, 05:41
Generic-user-small

Jay (3 posts)

Frank, I tried your solution by linking /usr/local/bin/mongrel_rails to /usr/local/lib/site_ruby/gems/bin/mongrel_rails which is how my Debian Etch config is set up. Still experiencing the same issues you described on the 14th. Here’s some more data:

I’ve included the mongrel.monitrc file I’m using. If you issue the start program and stop program commands shown in that file from the command line, they work fine, regardless of what directory you issue them from. Interestingly, calling “monit status” does show that the test3_8001 process is being monitored and shows the correct statistics for uptime, etc. However, when you run “monit restart test3_8001” there is a failure. “monit status” eventually shows “Execution failed” as a status for test3_8001, but does continue to show all the other correct stats as before. Checking the monit_errors.log shows only the following: 488 [PDT Jun 6 20:56:22] info : ‘mongrel_test3_8001’ trying to restart 489 [PDT Jun 6 20:56:22] info : ‘mongrel_test3_8001’ start: /usr/ bin/env 490 [PDT Jun 6 20:56:23] error : ‘mongrel_test3_8001’ failed to stop

Other notes: - Paths —> I tried just having the /usr/local/lib/site_ruby/gems/bin/ mongrel_rails cluster::start -C /home/jay/test/testing/config/ mongrel_cluster.yml –clean –only 8001” as a path —> I also tried adding the path to the ruby executable which is /usr/ local/bin/ruby on my machine prior to the above.

the mongrel.monitrc file:

check process test3_8001 with pidfile /home/jay/test/testing/tmp/pids/mongrel.8001.pid start program = “/usr/bin/env PATH=$PATH:/usr/local/lib/site_ruby/ gems/bin /usr/local/lib/site_ruby/gems/bin/mongrel_rails cluster::start -C /home/jay/test/testing/config/mongrel_cluster.yml – clean –only 8001” stop program = “//usr/bin/env PATH=$PATH:/usr/local/lib/site_ruby/ gems/bin /usr/local/lib/site_ruby/gems/bin/mongrel_rails cluster::stop -C /home/jay/test/testing/config/mongrel_cluster.yml –only 8001” # if cpu > 60% for 2 cycles then alert if cpu > 80% for 4 cycles then restart if totalmem > 110.0 MB for 4 cycles then restart # if children > 250 then restart # if loadavg(5min) greater than 10 for 8 cycles then stop # if failed host www.tildeslash.com port 80 protocol http # and request “/monit/doc/next.php” # then restart # if failed port 443 type tcpssl protocol http # with timeout 15 seconds # then restart if 20 restarts within 20 cycles then timeout # depends on apache_bin group test_mongrels

Thanks for any thoughts - I’m at a loss…

JBB

07 Jun 2008, 20:31
Generic-user-small

Jay (3 posts)

The answer for me at long last was to set GEM_HOME in the mongrel.monitrc file. So start program = “env GEM_HOME= /usr/local/bin/mongrel_rails cluster::start -C ...

07 Jul 2008, 19:53
Generic-user-small

Dave Rothlisberger (1 post)

If monit doesn’t seem to be starting your mongrels, check the mongrel log; from here I learned that the HOME path wasn’t set.

My start and stop monit commands both set the PATH and HOME environment variables, and monit now happily starts/stops my mongrels:

start = “/usr/bin/env PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin HOME=/home/rails mongrel_rails cluster::start -C /home/rails/app/current/config/mongrel_cluster.yml –clean –only 8000”

stop = “/usr/bin/env PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin HOME=/home/rails mongrel_rails cluster::stop -C /home/rails/app/current/config/mongrel_cluster.yml –clean –only 8000”

HTH

  You must be logged in to comment