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).
On Mar 7, 9:29 am, Aníbal Rojas <[EMAIL PROTECTED]> wrote:
> 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
> Rojashttp://hasmanydevelopers.comhttp://rubycorner.comhttp://anibal.rojas.com
>
> On Mar 6, 7:55 pm, Greg Willits <[EMAIL PROTECTED]>
> wrote:
>
> > 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
> > --
> > Posted viahttp://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Deploying Rails" group.
To post to this group, send email to rubyonrails-deployment@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-deployment?hl=en
-~----------~----~----~----~------~----~------~--~---
