Absolutely if it is god deleting the pid rather than what it appears
like, mongrel never writing the pid, then it's not mongrel's problem.
I haven't gotten around to replacing the mongrel cluster with thin or
passenger yet, so I'll try the suggestion of mongrel_cluster's --
clean.

Thanks!
Sean

On Jan 9, 11:55 am, woahdae <[email protected]> wrote:
> seems like this came up again in this thread:
>
> http://groups.google.com/group/god-rb/browse_thread/thread/0219271ab8...
>
> the solution mentioned above is to use mongrel_cluster for its --clean
> option (more details in the other post).
>
> And as for blaming mongrel, I wouldn't be so sure. This only happens
> for me when I use Gods clean option. I think God is the one that
> deletes the pid rather than mongrel not writing one. Though I don't
> have anything to back this up except a history of never experiencing
> this with mongrel otherwise...
>
> On Dec 29 2008, 4:37 am, "[email protected]"
>
> <[email protected]> wrote:
> > Aníbal,
>
> > Of course you are right... it is Mongrel's problem, not god's
> > specifically. I was wondering how to configure god to accommodate the
> > problem. I like both of your suggestions. I'll look into thin and if I
> > don't want to go to thin I'll write a pkill guard. Thanks for the
> > ideas.
>
> > Sean
>
> > On Dec 27, 10:24 am, "Aníbal Rojas" <[email protected]> wrote:
>
> > > Sean,
>
> > >     Actually your real problem is this weird mongrel behaviour. Not
> > > sure what your application is, but in my case I have switched all my
> > > production boxes to Thin without problem for a long time.
>
> > >     If you want to stick to Mongrel, I think you can modify start,
> > > stop or restart commands, depending how you have built them, to use a
> > > pkill "guard" to assure the misbehaving process is always killed.
>
> > >     Best regards, and Happy New Year
>
> > > ---------------------------------------- ----------------
> > > Aníbal Rojashttp://hasmanydevelopers.com(work)http://rubycorner.com       
> > >        (community)http://anibal.rojas.com.ve        (personal)
>
> > > On Sun, Dec 28, 2008 at 9:22 AM, [email protected]
>
> > > <[email protected]> wrote:
>
> > > > Hi fellows,
>
> > > > I have an issue that's happened quit a few times and I'm wondering
> > > > what might be a better configuration to avoid this issue.
>
> > > > The problem is if one of the mongrels in a cluster starts up and has
> > > > no pid file (I know this sounds odd, but it has happened quite a few
> > > > times, I don't know why). So all of the mongrels in the cluster start
> > > > up fine, but 1 ends up w/o a pid file. god comes along, finds no pid
> > > > so tries to start the mongrel instance, it fails because the port is
> > > > used and so no pid is written out, this happens over and over as god
> > > > discovers the missing pid each time. The end result is that nothing is
> > > > ever down, but I get emailed over and over by god saying it's trying
> > > > to start one of the mongrels. Here is the relevant extract of my
> > > > config:
>
> > > > w.start = "mongrel_rails start -c #{RAILS_ROOT} -p #{port} \
> > > >      -P #{RAILS_ROOT}/tmp/pids/mongrel.#{port}.pid -e production -d"
>
> > > >    # Conditions to start a mongrel
> > > >    w.start_if do |start|
> > > >      # If it's not running, start it
> > > >      start.condition(:process_running) do |c|
> > > >        c.running = false
> > > >        c.notify = {:contacts => ['developers'], :priority =>
> > > > 2, :category => 'god starting mongrel'}
> > > >      end
> > > >    end
>
> > > > What's a better way to configure mongrel start to avoid this problem?
>
> > > > Thanks!
> > > > Sean
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"god.rb" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/god-rb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to