# Monit trumps mongrel\_cluster? **URL:** \ **Category:** Deployment\ **Created:** [March 6, 2008, 1:55am UTC](https://www.ruby-forum.com/t/monit-trumps-mongrel-cluster/131105 "2008-03-06T01:55:00Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [March 6, 2008, 1:55am UTC](https://www.ruby-forum.com/t/monit-trumps-mongrel-cluster/131105/1 "2008-03-06T01:55:00Z")
I’ve been reading through the book “Deploying Rails Applications,” studing a setup done by someone els, and creating my own new setup. In the end it appears that mongrel\_cluster (deemed “required” by these setups) actually has no purpose in my final setup. Looking for validation or a counter opinion. In each case the deployment ends up with the OS launching monit at startup (launchd on OS X Server in my case), and monit with a repetitive config block that launches one instance of mongrel/rails. In the book, they use mongrel\_cluster, but each “cluster” is just one mongrel. In the live example I have to look at, they just stuck with mongrel\_rails to launch each one. Now, the book goes through these stages of showing how to launch one mongrel, then mongrel\_cluster, then mongrel\_cluster\_ctl, and finally monit – which just takes us right back to essentially launching one mongrel at a time again. I’ve been creating my own new setup, and I went with mongrel\_rails per monit config block like this: start program = “/usr/bin/mongrel\_rails start -d -e production -p 8100 -a system.local -t 30 -P /MY/RAILS/ROOT/log/mongrel.8100.pid -c /MY/RAILS/ROOT” After having done all that, I’m left wondering what the whole point of mongrel\_cluster is. I now have a mongrel\_cluster and mongrel\_cluster\_ctl config setup that appears to be useless now that I have monit controlling them. So, is the book just showing various techniques as exercises (doesn’t read that way)? Perhaps one would choose not to use monit? but then how control these leaky beggers? Seems to me there was no need to even install mongrel\_cluster, and at this point I may as well rip it out and eliminate the extra work of installing and configuring it. Which in my case means a clean install of OS X Server has everything I need right out of the box except for monit (which a quick compile solved that). Am I missing something? – gw ---
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [March 6, 2008, 2:49am UTC](https://www.ruby-forum.com/t/monit-trumps-mongrel-cluster/131105/2 "2008-03-06T02:49:15Z")
Greg- On Mar 5, 2008, at 4:55 PM, Greg W. wrote: > startup (launchd on OS X Server in my case), and monit with a > mongrel at a time again. > > – gw > What you are missing is the fact that mongrel\_cluster has the --clean > option while mongrel itself does not. So if your mongrels crash and > don’t clean up their pid file then they will not restart when monit > tries to restart them. So mongrel\_cluster in this case is only used for the --clean option. We will be adding a --clean option to momngrel itself for the next release so this is not needed anymore. Cheers- - Ezra Z. – Founder & Software Architect – removed\_email\_address@domain.invalid – [EngineYard.com](http://EngineYard.com) ---
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [March 6, 2008, 3:02am UTC](https://www.ruby-forum.com/t/monit-trumps-mongrel-cluster/131105/3 "2008-03-06T03:02:36Z")
> What you are missing is the fact that mongrel\_cluster has the --clean > option while mongrel itself does not. So if your mongrels crash and > don’t clean up their pid file then they will not restart when monit > tries to restart them. > > So mongrel\_cluster in this case is only used for the --clean option. > We will be adding a --clean option to momngrel itself for the next > release so this is not needed anymore. Ah, yup. Back to the config files it is… thx – gw ---
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [March 6, 2008, 3:13am UTC](https://www.ruby-forum.com/t/monit-trumps-mongrel-cluster/131105/4 "2008-03-06T03:13:52Z")
I followed Ezra’s book, ending up wth the monit setup and it works awesome. Restarts are finally truly graceful and I don’t have to babysit the mongrel intances anymore. It finally feels like a real web server. Thanks Ezra! My environment: - dell servers - centos 4.6 - nginx - mongrel - mongrel\_cluster - monit Raul ----- Original Message ----- From: “Ezra Z.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Sent: Wednesday, March 05, 2008 5:48 PM Subject: [Rails-deploy] Re: Monit trumps mongrel\_cluster ? ---
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [March 7, 2008, 3:30pm UTC](https://www.ruby-forum.com/t/monit-trumps-mongrel-cluster/131105/5 "2008-03-07T15:30:06Z")
Gregg, ``` Due to Rails not being thread safe, you will end having at least a ``` couple of Mongrel processes to handle a bunch on simultaneous incoming requests. Even if you can start with just one Mongrel instance, having the cluster setup is a good policy. ``` You could also take a look a Thin (I supports clusters out of the ``` box), or Ebb (look damn fast)as replacements for Mongrel (I have tried Thin and it is doing great) also you could try God instead of Monit, it provides a behavior to clean stale pid files, so you could go back to single Mongrel instance without the cluster support if you decide so. ``` http://code.macournoyer.com/thin/ http://ebb.rubyforge.org/ http://god.rubyforge.org/ You are lucky to have Ezra's book, before that, there were only ``` his blog posts to show some light in the darkness of Rails deployment 😉 – Aníbal Rojas > **[Home - Has Many Developers](https://hasmanydevelopers.com/)** > > We are the best choice for your building design and development > **[RUBYCORNER.COM](https://www.rubycorner.com/)** > > RUBYCORNER.COM - Contact us for any business inquiries [http://anibal.rojas.com](http://anibal.rojas.com) On Mar 6, 7:55 pm, Greg W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [March 7, 2008, 5:23pm UTC](https://www.ruby-forum.com/t/monit-trumps-mongrel-cluster/131105/6 "2008-03-07T17:23:07Z")
I added a function to my mongrel init script to clean stale pids (there were a lot of cases where I ran into stale pids no matter what I used). PID\_DIR=/var/run/mongrel RUBYBIN=/usr/bin/ruby clean\_stale\_pid () { for PIDFILE in ls $PID\_DIR/\*.pid; do if [-e $PIDFILE]; then PIDDIR=/proc/$(cat $PIDFILE) if ! [ -d ${PIDDIR} -a “$(readlink -f ${PIDDIR}/exe)” = $RUBYBIN ]; then #echo “removing stale pid: $PIDFILE” rm -f $PIDFILE fi fi done } I call the function from monit and other functions in my mongrel init script. I keep mongrel\_cluster around though as I often like to shut off monit to debug certain things and still maintain control of the entire cluster. You can totally replace mongrel\_cluster with monit/ god and a reworked mongrel init file (or control script).