From gethemant at gmail.com  Sat Mar  1 21:17:43 2008
From: gethemant at gmail.com (hemant)
Date: Sun, 2 Mar 2008 07:47:43 +0530
Subject: [Mongrel] Offloading Background Tasks
In-Reply-To: <2d8ffda38541bfdc3425ca8511bfcd00@ruby-forum.com>
References: <2d8ffda38541bfdc3425ca8511bfcd00@ruby-forum.com>
Message-ID: <fb283d5e0803011817t764d1b12w7fdafda64ea7ebc5@mail.gmail.com>

On Sat, Mar 1, 2008 at 7:10 AM, Nathan Esquenazi <lists at ruby-forum.com> wrote:
> Hello everyone,
>
>  I am very interested in off-loading tasks from the request/response
>  cycle in order to speed up my application. My application is heavily
>  connected to using web services both external and from other servers we
>  host.
>
>  My application does the following long-running tasks:
>
>  - accesses / pushes to the twitter api's (with possible need for status
>  responses)
>  - accesses / pushes the facebook api's  (with need for status responses)
>  - requesting data from another server we run (rails needs access data)
>  - pushes information to aim using ruburple
>
>  I am just curious and grateful for any help people can give for what
>  would suit me best. I am familar with backgroundrb and bj along with
>  starling, etc. I don't know which one will suit me best based on the
>  tasks I need to queue.
>
>  My main concern is how to properly request data and then show it to the
>  user. For instance, when the user logs into the rails application, I
>  need to show them certain information about them which comes from
>  complex analyzing of data done by another server we run.
>
>  When a user logs in, I need to show them the current results of this
>  analysis. To do this, I need to perform a GET request to another server
>  and get the results and then show them to the user. What is the "best
>  practice" way to achieve this in which I can offload this task to a
>  background worker and then get the results and display them to the user.
>
>  For instance, say the user logs in and then the background worker kicks
>  off to retrieve their current analyzed data from the server. How do I
>  then wait for the data to be retrieved by the worker and when it's ready
>  display it to the user?
>
>  I feel like I am missing something because I don't see how the worker
>  can "tell" the main rails application that it now has the data and then
>  somehow show it when its "ready". Do I need to constantly poll the
>  server or how is this usually done.
>
>  Also, I need to allow the user to make certain changes to data fields
>  and then I need to push those changes to twitter and facebook via a
>  background process.
>
>  What solution is best suited based on what I described and could someone
>  please help me understand the pattern for how to do this. I will be
>  eternally grateful.
>  --

For what you are describing, I think BackgrounDRb will be best fit.
Since, its the only solution ( that I know of ) provides interfacing
with rails so as you can actually fetch results retrieved by a worker
in rails.

Bj is a worker queue to offload tasks. AFAIK, you can't really
interact seamlessly from rails. I don't know much about startling. But
this is coming from guy who maintains bdrb to take it with a grain of
salt.

From public at misuse.org  Sat Mar  1 21:51:35 2008
From: public at misuse.org (Steve Midgley)
Date: Sat, 01 Mar 2008 18:51:35 -0800
Subject: [Mongrel] Offloading Background Tasks
In-Reply-To: <mailman.311.1204424265.7196.mongrel-users@rubyforge.org>
References: <mailman.311.1204424265.7196.mongrel-users@rubyforge.org>
Message-ID: <20080302025200.5B44F1858660@rubyforge.org>

At 06:17 PM 3/1/2008, mongrel-users-request at rubyforge.org wrote:
>Date: Sun, 2 Mar 2008 07:47:43 +0530
>From: hemant <gethemant at gmail.com>
>Subject: Re: [Mongrel] Offloading Background Tasks
>To: mongrel-users at rubyforge.org
>Message-ID: 
><fb283d5e0803011817t764d1b12w7fdafda64ea7ebc5 at mail.gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On Sat, Mar 1, 2008 at 7:10 AM, Nathan Esquenazi 
><lists at ruby-forum.com> wrote:
> > Hello everyone,
> >
> >  I am very interested in off-loading tasks from the 
> request/response
> >  cycle in order to speed up my application. My application is 
> heavily
> >  connected to using web services both external and from other 
> servers we
> >  host.
>[snip]
> >
> >  I feel like I am missing something because I don't see how the 
> worker
> >  can "tell" the main rails application that it now has the data and 
> then
> >  somehow show it when its "ready". Do I need to constantly poll the
> >  server or how is this usually done.
> >
> >  Also, I need to allow the user to make certain changes to data 
> fields
> >  and then I need to push those changes to twitter and facebook via 
> a
> >  background process.
> >
> >  What solution is best suited based on what I described and could 
> someone
> >  please help me understand the pattern for how to do this. I will 
> be
> >  eternally grateful.
> >  --
>
>For what you are describing, I think BackgrounDRb will be best fit.
>Since, its the only solution ( that I know of ) provides interfacing
>with rails so as you can actually fetch results retrieved by a worker
>in rails.
>
>Bj is a worker queue to offload tasks. AFAIK, you can't really
>interact seamlessly from rails. I don't know much about startling. But
>this is coming from guy who maintains bdrb to take it with a grain of
>salt.

Hi,

Firstly - apologies to Hemant for misinformation from me a while ago 
about the current status of BackgrounDrb. It's clear now of course to 
me that this an active and healthy project.

I have been messing around with Ara Howards BackgroundJob (bj) and it's 
got a way to spin out a bunch of jobs and then wait until they all 
return, which is similar to the way threads work:

>       jobs = Bj.submit list_of_jobs, :tag => 'important'
>       ...
>
>       jobs.each do |job|
>         if job.finished?
>           p job.exit_status
>           p job.stdout
>           p job.stderr
>         end
>       end

You can see that if by the time you get down to the "if jobs.finished?" 
section, you could choose to ignore whatever jobs haven't returned yet 
(or possibly even TERM them if that's appropriate).

I wonder also if you've considered adding some architecture to your 
system so that you can collect whatever you can from your external 
services from within Rails but then whatever is left over you could 
pull down via Ajax after the page had mostly loaded (so some parts of 
the page might be left with placeholders and then get filled in with 
the correct info later as the Ajax calls retrieve it from Rails..

That'd be my thought on this: build something (with BackgrounDRb, Bj or 
whatever) that lets you spawn a bunch of a async queries. Give those 
queries some kind of unique handle. When you're done building the whole 
page, have your view fill in data from whichever queries have returned. 
Then send the incomplete page to the browser and have ajax queries pull 
down the remaining query results (using a webservice interface passing 
in those unique handles you set up above to ID which job you want).

Hope this helps!

Steve


From mail at flydown.org  Sun Mar  2 05:10:54 2008
From: mail at flydown.org (Michele)
Date: Sun, 2 Mar 2008 11:10:54 +0100
Subject: [Mongrel] Append Mongrel port after HTML
Message-ID: <6D1EA332-9FD4-4ADA-953B-50D056916AB1@flydown.org>

Hi,

I'm trying to debug an issue I'm having with an app where certain  
requests fail but work after a refresh which led me to think it might  
be a problem with only one Mongrel instance out of the bunch.

So I was wondering if there's an easy way (i.e. without having to  
manually patch Mongrel) to append a comment at the end of the pages'  
HTML with something like the PID or port so I can track which instance  
served the request.

Thanks for your help!

- Michele

From mike.engelhart at gmail.com  Tue Mar  4 09:36:33 2008
From: mike.engelhart at gmail.com (Michael Engelhart)
Date: Tue, 4 Mar 2008 09:36:33 -0500
Subject: [Mongrel] Offloading Background Tasks
In-Reply-To: <20080302025200.5B44F1858660@rubyforge.org>
References: <mailman.311.1204424265.7196.mongrel-users@rubyforge.org>
	<20080302025200.5B44F1858660@rubyforge.org>
Message-ID: <42642c790803040636x5830a20x5f20ce43aa058784@mail.gmail.com>

We've been testing using Spawn.    Has anyone had any success in a
production environment with the spawn plugin?   It's very simple but
seems to work well although there doesn't seem to be any recent
activity around it.

Eventually I'd like to use Amazons SQS for our application but we
still have other architecture issues to sort out before going that
route.

Mike

On Sat, Mar 1, 2008 at 9:51 PM, Steve Midgley <public at misuse.org> wrote:
> At 06:17 PM 3/1/2008, mongrel-users-request at rubyforge.org wrote:
>  >Date: Sun, 2 Mar 2008 07:47:43 +0530
>  >From: hemant <gethemant at gmail.com>
>  >Subject: Re: [Mongrel] Offloading Background Tasks
>  >To: mongrel-users at rubyforge.org
>  >Message-ID:
>  ><fb283d5e0803011817t764d1b12w7fdafda64ea7ebc5 at mail.gmail.com>
>  >Content-Type: text/plain; charset=ISO-8859-1
>
> >
>  >On Sat, Mar 1, 2008 at 7:10 AM, Nathan Esquenazi
>  ><lists at ruby-forum.com> wrote:
>  > > Hello everyone,
>  > >
>  > >  I am very interested in off-loading tasks from the
>  > request/response
>  > >  cycle in order to speed up my application. My application is
>  > heavily
>  > >  connected to using web services both external and from other
>  > servers we
>  > >  host.
>  >[snip]
>
> > >
>  > >  I feel like I am missing something because I don't see how the
>  > worker
>  > >  can "tell" the main rails application that it now has the data and
>  > then
>  > >  somehow show it when its "ready". Do I need to constantly poll the
>  > >  server or how is this usually done.
>  > >
>  > >  Also, I need to allow the user to make certain changes to data
>  > fields
>  > >  and then I need to push those changes to twitter and facebook via
>  > a
>  > >  background process.
>  > >
>  > >  What solution is best suited based on what I described and could
>  > someone
>  > >  please help me understand the pattern for how to do this. I will
>  > be
>  > >  eternally grateful.
>  > >  --
>  >
>  >For what you are describing, I think BackgrounDRb will be best fit.
>  >Since, its the only solution ( that I know of ) provides interfacing
>  >with rails so as you can actually fetch results retrieved by a worker
>  >in rails.
>  >
>  >Bj is a worker queue to offload tasks. AFAIK, you can't really
>  >interact seamlessly from rails. I don't know much about startling. But
>  >this is coming from guy who maintains bdrb to take it with a grain of
>  >salt.
>
>  Hi,
>
>  Firstly - apologies to Hemant for misinformation from me a while ago
>  about the current status of BackgrounDrb. It's clear now of course to
>  me that this an active and healthy project.
>
>  I have been messing around with Ara Howards BackgroundJob (bj) and it's
>  got a way to spin out a bunch of jobs and then wait until they all
>  return, which is similar to the way threads work:
>
>  >       jobs = Bj.submit list_of_jobs, :tag => 'important'
>  >       ...
>  >
>  >       jobs.each do |job|
>  >         if job.finished?
>  >           p job.exit_status
>  >           p job.stdout
>  >           p job.stderr
>  >         end
>  >       end
>
>  You can see that if by the time you get down to the "if jobs.finished?"
>  section, you could choose to ignore whatever jobs haven't returned yet
>  (or possibly even TERM them if that's appropriate).
>
>  I wonder also if you've considered adding some architecture to your
>  system so that you can collect whatever you can from your external
>  services from within Rails but then whatever is left over you could
>  pull down via Ajax after the page had mostly loaded (so some parts of
>  the page might be left with placeholders and then get filled in with
>  the correct info later as the Ajax calls retrieve it from Rails..
>
>  That'd be my thought on this: build something (with BackgrounDRb, Bj or
>  whatever) that lets you spawn a bunch of a async queries. Give those
>  queries some kind of unique handle. When you're done building the whole
>  page, have your view fill in data from whichever queries have returned.
>  Then send the incomplete page to the browser and have ajax queries pull
>  down the remaining query results (using a webservice interface passing
>  in those unique handles you set up above to ID which job you want).
>
>  Hope this helps!
>
>  Steve
>
>
>
>  _______________________________________________
>  Mongrel-users mailing list
>  Mongrel-users at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/mongrel-users
>

From elw at brandorr.com  Tue Mar  4 21:37:35 2008
From: elw at brandorr.com (Elijah Wright)
Date: Tue, 4 Mar 2008 21:37:35 -0500
Subject: [Mongrel] best practices for monitoring mongrels with monit?
Message-ID: <57babe2b0803041837y4058975apb04de9d94ae5c42d@mail.gmail.com>

Hello,

We're interested in hearing from folks who have worked out a set of "best
practices" for monitoring mongrels with monit.

My local setup is remarkably similar to the one currently found in the "
Practical Programmers Deploying Rails Apps Beta" PDF, as well as several
other examples that we've seen floating around on the web.

Has someone gone to the trouble to do a pro/con analysis of a couple of
different approaches, so that we can get a better idea of what folks have
tried?

[We'd be sort of miserable if we didn't have monit... it allows us to build
some beautiful things!]

thanks very much in advance,

--elijah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080304/877ff197/attachment.html 

From rochkind at jhu.edu  Wed Mar  5 11:59:49 2008
From: rochkind at jhu.edu (Jonathan Rochkind)
Date: Wed, 05 Mar 2008 11:59:49 -0500
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
Message-ID: <47CED185.3030101@jhu.edu>

So I am using the instructions here to have mongrel_cluster start my 
various mongrel-deployed apps on server boot.
http://mongrel.rubyforge.org/wiki/MongrelCluster

There is a problem mentioned here:
http://www.ruby-forum.com/topic/105849

In summary---if the server (or the mongrel processes) die ungracefully 
leaving their pids behind, then on next boot, mongrel_cluster won't 
succesfully start them up, choking on the leftover pids.

What is the reccommended solution to this?  I'd like to have my mongrels 
automatically start on boot, in a way that forces them to start even if 
there are stale pids. Thanks for any advice!

[ PS: I just discovered this problem the hard way, when my server 
unexpetedly lost power, and my production apps failed to start up on the 
next boot!  Very unpleasant. ]

Jonathan


-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu


From eden at mojiti.com  Wed Mar  5 12:29:37 2008
From: eden at mojiti.com (Eden Li)
Date: Wed, 5 Mar 2008 09:29:37 -0800
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <47CED185.3030101@jhu.edu>
References: <47CED185.3030101@jhu.edu>
Message-ID: <A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>

Newer versions of mongrel_cluster have a --clean option which will  
remove stale pids if it finds them.  Provide that option to  
mongrel_rails cluster::* in your scripts.

On Mar 5, 2008, at 8:59 AM, Jonathan Rochkind wrote:

> So I am using the instructions here to have mongrel_cluster start my
> various mongrel-deployed apps on server boot.
> http://mongrel.rubyforge.org/wiki/MongrelCluster
>
> There is a problem mentioned here:
> http://www.ruby-forum.com/topic/105849
>
> In summary---if the server (or the mongrel processes) die ungracefully
> leaving their pids behind, then on next boot, mongrel_cluster won't
> succesfully start them up, choking on the leftover pids.
>
> What is the reccommended solution to this?  I'd like to have my  
> mongrels
> automatically start on boot, in a way that forces them to start even  
> if
> there are stale pids. Thanks for any advice!
>
> [ PS: I just discovered this problem the hard way, when my server
> unexpetedly lost power, and my production apps failed to start up on  
> the
> next boot!  Very unpleasant. ]
>
> Jonathan
>
>
> -- 
> Jonathan Rochkind
> Digital Services Software Engineer
> The Sheridan Libraries
> Johns Hopkins University
> 410.516.8886
> rochkind (at) jhu.edu
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From rochkind at jhu.edu  Wed Mar  5 12:40:26 2008
From: rochkind at jhu.edu (Jonathan Rochkind)
Date: Wed, 05 Mar 2008 12:40:26 -0500
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
Message-ID: <47CEDB0A.6070406@jhu.edu>

Thanks that's helpful, I'm investigating that.

Using the instructions at:

http://mongrel.rubyforge.org/wiki/MongrelCluster#OnBootInitializationSetup

I had a little bash script at /etc/init.d/mongrel_cluster that was copied from
/path/to/mongrel_cluster_gem/resources/mongrel_cluster

That bash script calls mongrel_cluster_ctl with various options. I have added a "--clean" option to the "start" condition.  Would it make sense to suggest this be added to resources/mongrel_cluster in the actual gem, to not require this change?  

However, now I'm trying to set up an intentionally created stale pid, to test this feature. I am invoking mongrel_cluster_ctl manually (but in the manner of the resources/mongrel_cluster script) with the --clean option. I get this:

****
/usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:83:in `unlink': No such file or directory - tmp/pids/mongrel.3000.pid (Errno::ENOENT)
        from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:83:in `start'
        from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:79:in `each'
        from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:79:in `start'
        from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:232:in `run'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel/command.rb:212:in `run'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/mongrel_rails:281
        from /usr/bin/mongrel_rails:18:in `load'
        from /usr/bin/mongrel_rails:18
mongrel_rails cluster::start returned an error.
*****

That was using a mongrel_config.yml file that did have 'cwd' set.  There certainly is a tmp/pids/mongrel.3000.pid off of the 'cwd' location.  But perhaps the 'unlink' isn't being executed off the 'cwd' location as it ought to be?

Is this a bug in mongrel_cluster_ctl --clean, or perhaps just a bug in my attempt to duplicate the problem condition and make sure I've solved it? 

Thanks for any help. 

Jonathan



Eden Li wrote:
> Newer versions of mongrel_cluster have a --clean option which will  
> remove stale pids if it finds them.  Provide that option to  
> mongrel_rails cluster::* in your scripts.
>
> On Mar 5, 2008, at 8:59 AM, Jonathan Rochkind wrote:
>
>   
>> So I am using the instructions here to have mongrel_cluster start my
>> various mongrel-deployed apps on server boot.
>> http://mongrel.rubyforge.org/wiki/MongrelCluster
>>
>> There is a problem mentioned here:
>> http://www.ruby-forum.com/topic/105849
>>
>> In summary---if the server (or the mongrel processes) die ungracefully
>> leaving their pids behind, then on next boot, mongrel_cluster won't
>> succesfully start them up, choking on the leftover pids.
>>
>> What is the reccommended solution to this?  I'd like to have my  
>> mongrels
>> automatically start on boot, in a way that forces them to start even  
>> if
>> there are stale pids. Thanks for any advice!
>>
>> [ PS: I just discovered this problem the hard way, when my server
>> unexpetedly lost power, and my production apps failed to start up on  
>> the
>> next boot!  Very unpleasant. ]
>>
>> Jonathan
>>
>>
>> -- 
>> Jonathan Rochkind
>> Digital Services Software Engineer
>> The Sheridan Libraries
>> Johns Hopkins University
>> 410.516.8886
>> rochkind (at) jhu.edu
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>     
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu


From rochkind at jhu.edu  Wed Mar  5 12:45:51 2008
From: rochkind at jhu.edu (Jonathan Rochkind)
Date: Wed, 05 Mar 2008 12:45:51 -0500
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <47CEDB0A.6070406@jhu.edu>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu>
Message-ID: <47CEDC4F.5020202@jhu.edu>

Actually, I have investigated further, and am pretty sure I am 
duplicating the problem condition properly.

mongrel_cluster_ctl start --clean doesn't seem to work properly, it's 
throwing that error. Hmm.

I am guessing that the script I find in the mongrel_cluster gem at 
resources/mongrel_cluster, which is reccommended on that wiki page... is 
not actually what you all are using.  And perhaps shouldn't be included 
in the distro anymore?   What are others using to ensure mongrel 
clusters start at boot?

Jonathan

Jonathan Rochkind wrote:
> Thanks that's helpful, I'm investigating that.
>
> Using the instructions at:
>
> http://mongrel.rubyforge.org/wiki/MongrelCluster#OnBootInitializationSetup
>
> I had a little bash script at /etc/init.d/mongrel_cluster that was copied from
> /path/to/mongrel_cluster_gem/resources/mongrel_cluster
>
> That bash script calls mongrel_cluster_ctl with various options. I have added a "--clean" option to the "start" condition.  Would it make sense to suggest this be added to resources/mongrel_cluster in the actual gem, to not require this change?  
>
> However, now I'm trying to set up an intentionally created stale pid, to test this feature. I am invoking mongrel_cluster_ctl manually (but in the manner of the resources/mongrel_cluster script) with the --clean option. I get this:
>
> ****
> /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:83:in `unlink': No such file or directory - tmp/pids/mongrel.3000.pid (Errno::ENOENT)
>         from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:83:in `start'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:79:in `each'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:79:in `start'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:232:in `run'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel/command.rb:212:in `run'
>         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/mongrel_rails:281
>         from /usr/bin/mongrel_rails:18:in `load'
>         from /usr/bin/mongrel_rails:18
> mongrel_rails cluster::start returned an error.
> *****
>
> That was using a mongrel_config.yml file that did have 'cwd' set.  There certainly is a tmp/pids/mongrel.3000.pid off of the 'cwd' location.  But perhaps the 'unlink' isn't being executed off the 'cwd' location as it ought to be?
>
> Is this a bug in mongrel_cluster_ctl --clean, or perhaps just a bug in my attempt to duplicate the problem condition and make sure I've solved it? 
>
> Thanks for any help. 
>
> Jonathan
>
>
>
> Eden Li wrote:
>   
>> Newer versions of mongrel_cluster have a --clean option which will  
>> remove stale pids if it finds them.  Provide that option to  
>> mongrel_rails cluster::* in your scripts.
>>
>> On Mar 5, 2008, at 8:59 AM, Jonathan Rochkind wrote:
>>
>>   
>>     
>>> So I am using the instructions here to have mongrel_cluster start my
>>> various mongrel-deployed apps on server boot.
>>> http://mongrel.rubyforge.org/wiki/MongrelCluster
>>>
>>> There is a problem mentioned here:
>>> http://www.ruby-forum.com/topic/105849
>>>
>>> In summary---if the server (or the mongrel processes) die ungracefully
>>> leaving their pids behind, then on next boot, mongrel_cluster won't
>>> succesfully start them up, choking on the leftover pids.
>>>
>>> What is the reccommended solution to this?  I'd like to have my  
>>> mongrels
>>> automatically start on boot, in a way that forces them to start even  
>>> if
>>> there are stale pids. Thanks for any advice!
>>>
>>> [ PS: I just discovered this problem the hard way, when my server
>>> unexpetedly lost power, and my production apps failed to start up on  
>>> the
>>> next boot!  Very unpleasant. ]
>>>
>>> Jonathan
>>>
>>>
>>> -- 
>>> Jonathan Rochkind
>>> Digital Services Software Engineer
>>> The Sheridan Libraries
>>> Johns Hopkins University
>>> 410.516.8886
>>> rochkind (at) jhu.edu
>>>
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>     
>>>       
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>   
>>     
>
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu


From njvack at wisc.edu  Wed Mar  5 12:57:44 2008
From: njvack at wisc.edu (Nate Vack)
Date: Wed, 5 Mar 2008 11:57:44 -0600
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <47CEDC4F.5020202@jhu.edu>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu> <47CEDC4F.5020202@jhu.edu>
Message-ID: <8be813400803050957xa51710cxf7c67e567694db64@mail.gmail.com>

I'm doing everything (everything!) via either monit (on linux) or SMF
(on Solaris).

Using a process manager is a good idea... and having only one
'production' way to start mongrel is generally a good thing, too :)

-n

On Wed, Mar 5, 2008 at 11:45 AM, Jonathan Rochkind <rochkind at jhu.edu> wrote:
> Actually, I have investigated further, and am pretty sure I am
>  duplicating the problem condition properly.
>
>  mongrel_cluster_ctl start --clean doesn't seem to work properly, it's
>  throwing that error. Hmm.
>
>  I am guessing that the script I find in the mongrel_cluster gem at
>  resources/mongrel_cluster, which is reccommended on that wiki page... is
>  not actually what you all are using.  And perhaps shouldn't be included
>  in the distro anymore?   What are others using to ensure mongrel
>  clusters start at boot?
>
>  Jonathan
>
>
>
>  Jonathan Rochkind wrote:
>  > Thanks that's helpful, I'm investigating that.
>  >
>  > Using the instructions at:
>  >
>  > http://mongrel.rubyforge.org/wiki/MongrelCluster#OnBootInitializationSetup
>  >
>  > I had a little bash script at /etc/init.d/mongrel_cluster that was copied from
>  > /path/to/mongrel_cluster_gem/resources/mongrel_cluster
>  >
>  > That bash script calls mongrel_cluster_ctl with various options. I have added a "--clean" option to the "start" condition.  Would it make sense to suggest this be added to resources/mongrel_cluster in the actual gem, to not require this change?
>  >
>  > However, now I'm trying to set up an intentionally created stale pid, to test this feature. I am invoking mongrel_cluster_ctl manually (but in the manner of the resources/mongrel_cluster script) with the --clean option. I get this:
>  >
>  > ****
>  > /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:83:in `unlink': No such file or directory - tmp/pids/mongrel.3000.pid (Errno::ENOENT)
>  >         from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:83:in `start'
>  >         from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:79:in `each'
>  >         from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:79:in `start'
>  >         from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb:232:in `run'
>  >         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/../lib/mongrel/command.rb:212:in `run'
>  >         from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/mongrel_rails:281
>  >         from /usr/bin/mongrel_rails:18:in `load'
>  >         from /usr/bin/mongrel_rails:18
>  > mongrel_rails cluster::start returned an error.
>  > *****
>  >
>  > That was using a mongrel_config.yml file that did have 'cwd' set.  There certainly is a tmp/pids/mongrel.3000.pid off of the 'cwd' location.  But perhaps the 'unlink' isn't being executed off the 'cwd' location as it ought to be?
>  >
>  > Is this a bug in mongrel_cluster_ctl --clean, or perhaps just a bug in my attempt to duplicate the problem condition and make sure I've solved it?
>  >
>  > Thanks for any help.
>  >
>  > Jonathan
>  >
>  >
>  >
>  > Eden Li wrote:
>  >
>  >> Newer versions of mongrel_cluster have a --clean option which will
>  >> remove stale pids if it finds them.  Provide that option to
>  >> mongrel_rails cluster::* in your scripts.
>  >>
>  >> On Mar 5, 2008, at 8:59 AM, Jonathan Rochkind wrote:
>  >>
>  >>
>  >>
>  >>> So I am using the instructions here to have mongrel_cluster start my
>  >>> various mongrel-deployed apps on server boot.
>  >>> http://mongrel.rubyforge.org/wiki/MongrelCluster
>  >>>
>  >>> There is a problem mentioned here:
>  >>> http://www.ruby-forum.com/topic/105849
>  >>>
>  >>> In summary---if the server (or the mongrel processes) die ungracefully
>  >>> leaving their pids behind, then on next boot, mongrel_cluster won't
>  >>> succesfully start them up, choking on the leftover pids.
>  >>>
>  >>> What is the reccommended solution to this?  I'd like to have my
>  >>> mongrels
>  >>> automatically start on boot, in a way that forces them to start even
>  >>> if
>  >>> there are stale pids. Thanks for any advice!
>  >>>
>  >>> [ PS: I just discovered this problem the hard way, when my server
>  >>> unexpetedly lost power, and my production apps failed to start up on
>  >>> the
>  >>> next boot!  Very unpleasant. ]
>  >>>
>  >>> Jonathan
>  >>>
>  >>>
>  >>> --
>  >>> Jonathan Rochkind
>  >>> Digital Services Software Engineer
>  >>> The Sheridan Libraries
>  >>> Johns Hopkins University
>  >>> 410.516.8886
>  >>> rochkind (at) jhu.edu
>  >>>
>  >>> _______________________________________________
>  >>> Mongrel-users mailing list
>  >>> Mongrel-users at rubyforge.org
>  >>> http://rubyforge.org/mailman/listinfo/mongrel-users
>  >>>
>  >>>
>  >> _______________________________________________
>  >> Mongrel-users mailing list
>  >> Mongrel-users at rubyforge.org
>  >> http://rubyforge.org/mailman/listinfo/mongrel-users
>  >>
>  >>
>  >
>  >
>
>  --
>  Jonathan Rochkind
>  Digital Services Software Engineer
>  The Sheridan Libraries
>  Johns Hopkins University
>  410.516.8886
>  rochkind (at) jhu.edu
>
>  _______________________________________________
>  Mongrel-users mailing list
>  Mongrel-users at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/mongrel-users
>

From eden at mojiti.com  Wed Mar  5 13:07:55 2008
From: eden at mojiti.com (Eden Li)
Date: Wed, 5 Mar 2008 10:07:55 -0800
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <47CEDC4F.5020202@jhu.edu>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu> <47CEDC4F.5020202@jhu.edu>
Message-ID: <AD93986E-974E-40CB-BA90-89902130303B@mojiti.com>

I use mongrel_rails cluster::* instead of mongrel_cluster_ctl, however  
it looks like you're using an older version of mongrel_cluster.  You  
might try upgrading to 1.0.5.

On Mar 5, 2008, at 9:45 AM, Jonathan Rochkind wrote:

> Actually, I have investigated further, and am pretty sure I am
> duplicating the problem condition properly.
>
> mongrel_cluster_ctl start --clean doesn't seem to work properly, it's
> throwing that error. Hmm.
>
> I am guessing that the script I find in the mongrel_cluster gem at
> resources/mongrel_cluster, which is reccommended on that wiki  
> page... is
> not actually what you all are using.  And perhaps shouldn't be  
> included
> in the distro anymore?   What are others using to ensure mongrel
> clusters start at boot?
>
> Jonathan
>
> Jonathan Rochkind wrote:
>> Thanks that's helpful, I'm investigating that.
>>
>> Using the instructions at:
>>
>> http://mongrel.rubyforge.org/wiki/MongrelCluster#OnBootInitializationSetup
>>
>> I had a little bash script at /etc/init.d/mongrel_cluster that was  
>> copied from
>> /path/to/mongrel_cluster_gem/resources/mongrel_cluster
>>
>> That bash script calls mongrel_cluster_ctl with various options. I  
>> have added a "--clean" option to the "start" condition.  Would it  
>> make sense to suggest this be added to resources/mongrel_cluster in  
>> the actual gem, to not require this change?
>>
>> However, now I'm trying to set up an intentionally created stale  
>> pid, to test this feature. I am invoking mongrel_cluster_ctl  
>> manually (but in the manner of the resources/mongrel_cluster  
>> script) with the --clean option. I get this:
>>
>> ****
>> /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/ 
>> mongrel_cluster/init.rb:83:in `unlink': No such file or directory -  
>> tmp/pids/mongrel.3000.pid (Errno::ENOENT)
>>        from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/ 
>> mongrel_cluster/init.rb:83:in `start'
>>        from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/ 
>> mongrel_cluster/init.rb:79:in `each'
>>        from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/ 
>> mongrel_cluster/init.rb:79:in `start'
>>        from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/ 
>> mongrel_cluster/init.rb:232:in `run'
>>        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/../lib/ 
>> mongrel/command.rb:212:in `run'
>>        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/ 
>> mongrel_rails:281
>>        from /usr/bin/mongrel_rails:18:in `load'
>>        from /usr/bin/mongrel_rails:18
>> mongrel_rails cluster::start returned an error.
>> *****
>>
>> That was using a mongrel_config.yml file that did have 'cwd' set.   
>> There certainly is a tmp/pids/mongrel.3000.pid off of the 'cwd'  
>> location.  But perhaps the 'unlink' isn't being executed off the  
>> 'cwd' location as it ought to be?
>>
>> Is this a bug in mongrel_cluster_ctl --clean, or perhaps just a bug  
>> in my attempt to duplicate the problem condition and make sure I've  
>> solved it?
>>
>> Thanks for any help.
>>
>> Jonathan
>>
>>
>>
>> Eden Li wrote:
>>
>>> Newer versions of mongrel_cluster have a --clean option which will
>>> remove stale pids if it finds them.  Provide that option to
>>> mongrel_rails cluster::* in your scripts.
>>>
>>> On Mar 5, 2008, at 8:59 AM, Jonathan Rochkind wrote:
>>>
>>>
>>>
>>>> So I am using the instructions here to have mongrel_cluster start  
>>>> my
>>>> various mongrel-deployed apps on server boot.
>>>> http://mongrel.rubyforge.org/wiki/MongrelCluster
>>>>
>>>> There is a problem mentioned here:
>>>> http://www.ruby-forum.com/topic/105849
>>>>
>>>> In summary---if the server (or the mongrel processes) die  
>>>> ungracefully
>>>> leaving their pids behind, then on next boot, mongrel_cluster won't
>>>> succesfully start them up, choking on the leftover pids.
>>>>
>>>> What is the reccommended solution to this?  I'd like to have my
>>>> mongrels
>>>> automatically start on boot, in a way that forces them to start  
>>>> even
>>>> if
>>>> there are stale pids. Thanks for any advice!
>>>>
>>>> [ PS: I just discovered this problem the hard way, when my server
>>>> unexpetedly lost power, and my production apps failed to start up  
>>>> on
>>>> the
>>>> next boot!  Very unpleasant. ]
>>>>
>>>> Jonathan
>>>>
>>>>
>>>> -- 
>>>> Jonathan Rochkind
>>>> Digital Services Software Engineer
>>>> The Sheridan Libraries
>>>> Johns Hopkins University
>>>> 410.516.8886
>>>> rochkind (at) jhu.edu
>>>>
>>>> _______________________________________________
>>>> Mongrel-users mailing list
>>>> Mongrel-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>>
>>>>
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>
>>>
>>
>>
>
> -- 
> Jonathan Rochkind
> Digital Services Software Engineer
> The Sheridan Libraries
> Johns Hopkins University
> 410.516.8886
> rochkind (at) jhu.edu
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From rochkind at jhu.edu  Wed Mar  5 13:15:57 2008
From: rochkind at jhu.edu (Jonathan Rochkind)
Date: Wed, 05 Mar 2008 13:15:57 -0500
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <AD93986E-974E-40CB-BA90-89902130303B@mojiti.com>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu> <47CEDC4F.5020202@jhu.edu>
	<AD93986E-974E-40CB-BA90-89902130303B@mojiti.com>
Message-ID: <47CEE35D.5030809@jhu.edu>

Believe it or not, I have indeed upgraded to 1.0.5 of mongrel_cluster 
and 1.1.4 of mongrel.  At least I think I have. I have installed the 
newer versions of the gems, and I believe it's what my scripts are using.

What makes you think it looks like I am not?  Because maybe I'm not even 
though I intend to be.

I wonder again, if the sample script distributed with the gem at 
resources/mongrel_cluster doesn't work/isn't supported... should someone 
with commit privs remove it? Or add a comment to it warning it might not 
work?

Jonathan

Eden Li wrote:
> I use mongrel_rails cluster::* instead of mongrel_cluster_ctl, however  
> it looks like you're using an older version of mongrel_cluster.  You  
> might try upgrading to 1.0.5.
>
> On Mar 5, 2008, at 9:45 AM, Jonathan Rochkind wrote:
>
>   
>> Actually, I have investigated further, and am pretty sure I am
>> duplicating the problem condition properly.
>>
>> mongrel_cluster_ctl start --clean doesn't seem to work properly, it's
>> throwing that error. Hmm.
>>
>> I am guessing that the script I find in the mongrel_cluster gem at
>> resources/mongrel_cluster, which is reccommended on that wiki  
>> page... is
>> not actually what you all are using.  And perhaps shouldn't be  
>> included
>> in the distro anymore?   What are others using to ensure mongrel
>> clusters start at boot?
>>
>> Jonathan
>>
>> Jonathan Rochkind wrote:
>>     
>>> Thanks that's helpful, I'm investigating that.
>>>
>>> Using the instructions at:
>>>
>>> http://mongrel.rubyforge.org/wiki/MongrelCluster#OnBootInitializationSetup
>>>
>>> I had a little bash script at /etc/init.d/mongrel_cluster that was  
>>> copied from
>>> /path/to/mongrel_cluster_gem/resources/mongrel_cluster
>>>
>>> That bash script calls mongrel_cluster_ctl with various options. I  
>>> have added a "--clean" option to the "start" condition.  Would it  
>>> make sense to suggest this be added to resources/mongrel_cluster in  
>>> the actual gem, to not require this change?
>>>
>>> However, now I'm trying to set up an intentionally created stale  
>>> pid, to test this feature. I am invoking mongrel_cluster_ctl  
>>> manually (but in the manner of the resources/mongrel_cluster  
>>> script) with the --clean option. I get this:
>>>
>>> ****
>>> /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/ 
>>> mongrel_cluster/init.rb:83:in `unlink': No such file or directory -  
>>> tmp/pids/mongrel.3000.pid (Errno::ENOENT)
>>>        from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/ 
>>> mongrel_cluster/init.rb:83:in `start'
>>>        from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/ 
>>> mongrel_cluster/init.rb:79:in `each'
>>>        from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/ 
>>> mongrel_cluster/init.rb:79:in `start'
>>>        from /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/ 
>>> mongrel_cluster/init.rb:232:in `run'
>>>        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/../lib/ 
>>> mongrel/command.rb:212:in `run'
>>>        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/ 
>>> mongrel_rails:281
>>>        from /usr/bin/mongrel_rails:18:in `load'
>>>        from /usr/bin/mongrel_rails:18
>>> mongrel_rails cluster::start returned an error.
>>> *****
>>>
>>> That was using a mongrel_config.yml file that did have 'cwd' set.   
>>> There certainly is a tmp/pids/mongrel.3000.pid off of the 'cwd'  
>>> location.  But perhaps the 'unlink' isn't being executed off the  
>>> 'cwd' location as it ought to be?
>>>
>>> Is this a bug in mongrel_cluster_ctl --clean, or perhaps just a bug  
>>> in my attempt to duplicate the problem condition and make sure I've  
>>> solved it?
>>>
>>> Thanks for any help.
>>>
>>> Jonathan
>>>
>>>
>>>
>>> Eden Li wrote:
>>>
>>>       
>>>> Newer versions of mongrel_cluster have a --clean option which will
>>>> remove stale pids if it finds them.  Provide that option to
>>>> mongrel_rails cluster::* in your scripts.
>>>>
>>>> On Mar 5, 2008, at 8:59 AM, Jonathan Rochkind wrote:
>>>>
>>>>
>>>>
>>>>         
>>>>> So I am using the instructions here to have mongrel_cluster start  
>>>>> my
>>>>> various mongrel-deployed apps on server boot.
>>>>> http://mongrel.rubyforge.org/wiki/MongrelCluster
>>>>>
>>>>> There is a problem mentioned here:
>>>>> http://www.ruby-forum.com/topic/105849
>>>>>
>>>>> In summary---if the server (or the mongrel processes) die  
>>>>> ungracefully
>>>>> leaving their pids behind, then on next boot, mongrel_cluster won't
>>>>> succesfully start them up, choking on the leftover pids.
>>>>>
>>>>> What is the reccommended solution to this?  I'd like to have my
>>>>> mongrels
>>>>> automatically start on boot, in a way that forces them to start  
>>>>> even
>>>>> if
>>>>> there are stale pids. Thanks for any advice!
>>>>>
>>>>> [ PS: I just discovered this problem the hard way, when my server
>>>>> unexpetedly lost power, and my production apps failed to start up  
>>>>> on
>>>>> the
>>>>> next boot!  Very unpleasant. ]
>>>>>
>>>>> Jonathan
>>>>>
>>>>>
>>>>> -- 
>>>>> Jonathan Rochkind
>>>>> Digital Services Software Engineer
>>>>> The Sheridan Libraries
>>>>> Johns Hopkins University
>>>>> 410.516.8886
>>>>> rochkind (at) jhu.edu
>>>>>
>>>>> _______________________________________________
>>>>> Mongrel-users mailing list
>>>>> Mongrel-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>>>
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> Mongrel-users mailing list
>>>> Mongrel-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>>
>>>>
>>>>         
>>>       
>> -- 
>> Jonathan Rochkind
>> Digital Services Software Engineer
>> The Sheridan Libraries
>> Johns Hopkins University
>> 410.516.8886
>> rochkind (at) jhu.edu
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>     
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu


From simon.santoro at gmail.com  Wed Mar  5 14:16:22 2008
From: simon.santoro at gmail.com (Simon Santoro)
Date: Wed, 5 Mar 2008 20:16:22 +0100
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <47CED185.3030101@jhu.edu>
References: <47CED185.3030101@jhu.edu>
Message-ID: <200803052016.22601.simon.santoro@gmail.com>

On Wednesday 05 March 2008 17:59:49 Jonathan Rochkind wrote:
> What is the reccommended solution to this?

I don't know, put there is a patch here:
http://textsnippets.com/posts/show/931
and a ticket got submitted here:
http://rubyforge.org/tracker/index.php?func=detail&aid=11098&group_id=1306&atid=5147

but it was not committed because "mongrel_rails now supports a --clean".
my mongrel_rails does not support it, but I may have an old version.

I think it would be right for mongrel to clean up it's stale pid files. Every 
program I know of does that, and I patched my mongrel.


From eden at mojiti.com  Wed Mar  5 14:35:00 2008
From: eden at mojiti.com (Eden Li)
Date: Wed, 5 Mar 2008 11:35:00 -0800
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <47CEE35D.5030809@jhu.edu>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu> <47CEDC4F.5020202@jhu.edu>
	<AD93986E-974E-40CB-BA90-89902130303B@mojiti.com>
	<47CEE35D.5030809@jhu.edu>
Message-ID: <CC913341-6AA5-4B5A-9F8E-00E196A92E1C@mojiti.com>

Your backtrace:

>>> /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/
>>> mongrel_cluster/init.rb

You might try removing stale gems by running `sudo gem uninstall  
mongrel_cluster` and removing anything that's not mongrel_cluster  
1.0.5.  Also make sure your /usr/bin/mongrel_* are pointing to the  
right version.

On Mar 5, 2008, at 10:15 AM, Jonathan Rochkind wrote:

> What makes you think it looks like I am not?  Because maybe I'm not  
> even
> though I intend to be.


From rochkind at jhu.edu  Wed Mar  5 14:41:31 2008
From: rochkind at jhu.edu (Jonathan Rochkind)
Date: Wed, 05 Mar 2008 14:41:31 -0500
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <200803052016.22601.simon.santoro@gmail.com>
References: <47CED185.3030101@jhu.edu>
	<200803052016.22601.simon.santoro@gmail.com>
Message-ID: <47CEF76B.2000003@jhu.edu>

Yeah, I think that closing of that ticket is right. As far as 
mongrel_rails is concerned, it makes sense to use the --clean option, 
rather than put it in there to happen by default. (although actually, 
I'd have --clean be default).

My problem is that I'm using mongrel_cluster_ctl instead of 
mongrel_rails. The nice feature of mongrel_cluster_ctl here is that you 
can give it a -c argument which is a directory containing mongrel 
cluster yml files. And it will do the invoked operation to ALL of those 
config files. I like this. I want to use it.

And mongrel_cluster_ctl's --clean option appears to be broken to me. I 
guess I should figure out how to fix it and submit a patch?

The other problem is that the sample script at 
resources/mongrel_cluster, which invokes mongrel_cluster_ctl, doesn't 
invoke the --clean option (which wouldn't work right even if it did, but 
once it does). So I guess I should fix that and submit a patch too? 

I'm new to submitting patches for this kind of stuff. Can anyone 
reccommend patch etiquette/procedure to do this properly? And/or confirm 
that I'm approaching this sanely?

Thanks for the help, all.

Jonathan

Simon Santoro wrote:
> On Wednesday 05 March 2008 17:59:49 Jonathan Rochkind wrote:
>   
>> What is the reccommended solution to this?
>>     
>
> I don't know, put there is a patch here:
> http://textsnippets.com/posts/show/931
> and a ticket got submitted here:
> http://rubyforge.org/tracker/index.php?func=detail&aid=11098&group_id=1306&atid=5147
>
> but it was not committed because "mongrel_rails now supports a --clean".
> my mongrel_rails does not support it, but I may have an old version.
>
> I think it would be right for mongrel to clean up it's stale pid files. Every 
> program I know of does that, and I patched my mongrel.
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu


From leccine at gmail.com  Wed Mar  5 14:38:02 2008
From: leccine at gmail.com (Istvan Szukacs)
Date: Wed, 05 Mar 2008 20:38:02 +0100
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <47CED185.3030101@jhu.edu>
References: <47CED185.3030101@jhu.edu>
Message-ID: <47CEF69A.9040303@gmail.com>


to write a script which checks the running pids and pid files and if 
there is staled pid just remove it?
(and after let the normal starting process run)

mongrel_rails and mongrel_cluster_ctl are written in ruby,
you will not hurt the original library with this modification

if the --clean is not working well...

istvan,
http://weho.st

Jonathan Rochkind wrote:
> So I am using the instructions here to have mongrel_cluster start my 
> various mongrel-deployed apps on server boot.
> http://mongrel.rubyforge.org/wiki/MongrelCluster
>
> There is a problem mentioned here:
> http://www.ruby-forum.com/topic/105849
>
> In summary---if the server (or the mongrel processes) die ungracefully 
> leaving their pids behind, then on next boot, mongrel_cluster won't 
> succesfully start them up, choking on the leftover pids.
>
> What is the reccommended solution to this?  I'd like to have my mongrels 
> automatically start on boot, in a way that forces them to start even if 
> there are stale pids. Thanks for any advice!
>
> [ PS: I just discovered this problem the hard way, when my server 
> unexpetedly lost power, and my production apps failed to start up on the 
> next boot!  Very unpleasant. ]
>
> Jonathan
>
>
>   


From rochkind at jhu.edu  Wed Mar  5 14:52:08 2008
From: rochkind at jhu.edu (Jonathan Rochkind)
Date: Wed, 05 Mar 2008 14:52:08 -0500
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <CC913341-6AA5-4B5A-9F8E-00E196A92E1C@mojiti.com>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu> <47CEDC4F.5020202@jhu.edu>
	<AD93986E-974E-40CB-BA90-89902130303B@mojiti.com>
	<47CEE35D.5030809@jhu.edu>
	<CC913341-6AA5-4B5A-9F8E-00E196A92E1C@mojiti.com>
Message-ID: <47CEF9E8.80108@jhu.edu>

Aha. Thanks. This is curious. I would actually like to have both 
versions of mongrel_cluster installed at the moment, so I can easily 
switch back if needed. gem is supposed to be capable of this of course.

I'm confused as to why my scirpt in /usr/bin/mongrel_cluster_ctl is 
calling the 1.0.2 version, when I have 1.0.5 installed. When I look at 
the very brief code in /usr/bin/mongrel_cluster_ctl, it looks like it 
should use the latest mongrel_cluster stuff installed. Here's what's in 
/usr/bin/mongrel_cluster, anyone know why this would be using 1.0.2 even 
though I have 1.0.5 installed?

#!/usr/bin/env ruby
#
# This file was generated by RubyGems.
#
# The application 'mongrel_cluster' is installed as part of a gem, and
# this file is here to facilitate running it.
#

require 'rubygems'
version = "> 0"
if ARGV.size > 0 && ARGV[0][0]==95 && ARGV[0][-1]==95
  if Gem::Version.correct?(ARGV[0][1..-2])
    version = ARGV[0][1..-2]
    ARGV.shift
  end
end
require_gem 'mongrel_cluster', version
load 'mongrel_cluster_ctl'


Eden Li wrote:
> Your backtrace:
>
>   
>>>> /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/
>>>> mongrel_cluster/init.rb
>>>>         
>
> You might try removing stale gems by running `sudo gem uninstall  
> mongrel_cluster` and removing anything that's not mongrel_cluster  
> 1.0.5.  Also make sure your /usr/bin/mongrel_* are pointing to the  
> right version.
>
> On Mar 5, 2008, at 10:15 AM, Jonathan Rochkind wrote:
>
>   
>> What makes you think it looks like I am not?  Because maybe I'm not  
>> even
>> though I intend to be.
>>     
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu


From rochkind at jhu.edu  Wed Mar  5 15:02:05 2008
From: rochkind at jhu.edu (Jonathan Rochkind)
Date: Wed, 05 Mar 2008 15:02:05 -0500
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <47CEF76B.2000003@jhu.edu>
References: <47CED185.3030101@jhu.edu>
	<200803052016.22601.simon.santoro@gmail.com>
	<47CEF76B.2000003@jhu.edu>
Message-ID: <47CEFC3D.4050604@jhu.edu>

Okay, I figured out more. Sorry for spamming the list. This is 
frustrating me.

I deleted mongrel_cluster 1.0.2 entirely. But check out this stack 
trace. Why the heck is mongrel-1.1.4/bin/mongrel_rails requiring 
mongrel_rails 1.0.2 and refusing to use mongrel_rails 1.0.5?

/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
`gem_original_require': no such file to load -- 
/usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/mongrel_cluster/init.rb 
(LoadError)
        from 
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
        from 
/usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:134:in `load'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:142:in 
`each'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:142:in 
`each'
        from 
/usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:112:in `load'
        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/mongrel_rails:278
        from /usr/bin/mongrel_rails:18:in `load'
        from /usr/bin/mongrel_rails:18


Jonathan Rochkind wrote:
> Yeah, I think that closing of that ticket is right. As far as 
> mongrel_rails is concerned, it makes sense to use the --clean option, 
> rather than put it in there to happen by default. (although actually, 
> I'd have --clean be default).
>
> My problem is that I'm using mongrel_cluster_ctl instead of 
> mongrel_rails. The nice feature of mongrel_cluster_ctl here is that you 
> can give it a -c argument which is a directory containing mongrel 
> cluster yml files. And it will do the invoked operation to ALL of those 
> config files. I like this. I want to use it.
>
> And mongrel_cluster_ctl's --clean option appears to be broken to me. I 
> guess I should figure out how to fix it and submit a patch?
>
> The other problem is that the sample script at 
> resources/mongrel_cluster, which invokes mongrel_cluster_ctl, doesn't 
> invoke the --clean option (which wouldn't work right even if it did, but 
> once it does). So I guess I should fix that and submit a patch too? 
>
> I'm new to submitting patches for this kind of stuff. Can anyone 
> reccommend patch etiquette/procedure to do this properly? And/or confirm 
> that I'm approaching this sanely?
>
> Thanks for the help, all.
>
> Jonathan
>
> Simon Santoro wrote:
>   
>> On Wednesday 05 March 2008 17:59:49 Jonathan Rochkind wrote:
>>   
>>     
>>> What is the reccommended solution to this?
>>>     
>>>       
>> I don't know, put there is a patch here:
>> http://textsnippets.com/posts/show/931
>> and a ticket got submitted here:
>> http://rubyforge.org/tracker/index.php?func=detail&aid=11098&group_id=1306&atid=5147
>>
>> but it was not committed because "mongrel_rails now supports a --clean".
>> my mongrel_rails does not support it, but I may have an old version.
>>
>> I think it would be right for mongrel to clean up it's stale pid files. Every 
>> program I know of does that, and I patched my mongrel.
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>   
>>     
>
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu


From eden at mojiti.com  Wed Mar  5 15:20:53 2008
From: eden at mojiti.com (Eden Li)
Date: Wed, 5 Mar 2008 12:20:53 -0800
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <47CEFC3D.4050604@jhu.edu>
References: <47CED185.3030101@jhu.edu>
	<200803052016.22601.simon.santoro@gmail.com>
	<47CEF76B.2000003@jhu.edu> <47CEFC3D.4050604@jhu.edu>
Message-ID: <0FABB3FD-3713-4455-9C09-1073808AC4C9@mojiti.com>

try

sudo rm /usr/lib/ruby/gems/1.8/specifications/ 
mongrel_cluster-1.0.2.gemspec

i think your specs are stale

On Mar 5, 2008, at 12:02 PM, Jonathan Rochkind wrote:

> Okay, I figured out more. Sorry for spamming the list. This is
> frustrating me.
>
> I deleted mongrel_cluster 1.0.2 entirely. But check out this stack
> trace. Why the heck is mongrel-1.1.4/bin/mongrel_rails requiring
> mongrel_rails 1.0.2 and refusing to use mongrel_rails 1.0.5?
>
> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `gem_original_require': no such file to load --
> /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/ 
> mongrel_cluster/init.rb
> (LoadError)
>        from
> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
>        from
> /usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb: 
> 134:in `load'
>        from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb: 
> 142:in
> `each'
>        from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb: 
> 142:in
> `each'
>        from
> /usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb: 
> 112:in `load'
>        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/ 
> mongrel_rails:278
>        from /usr/bin/mongrel_rails:18:in `load'
>        from /usr/bin/mongrel_rails:18
>
>
> Jonathan Rochkind wrote:
>> Yeah, I think that closing of that ticket is right. As far as
>> mongrel_rails is concerned, it makes sense to use the --clean option,
>> rather than put it in there to happen by default. (although actually,
>> I'd have --clean be default).
>>
>> My problem is that I'm using mongrel_cluster_ctl instead of
>> mongrel_rails. The nice feature of mongrel_cluster_ctl here is that  
>> you
>> can give it a -c argument which is a directory containing mongrel
>> cluster yml files. And it will do the invoked operation to ALL of  
>> those
>> config files. I like this. I want to use it.
>>
>> And mongrel_cluster_ctl's --clean option appears to be broken to  
>> me. I
>> guess I should figure out how to fix it and submit a patch?
>>
>> The other problem is that the sample script at
>> resources/mongrel_cluster, which invokes mongrel_cluster_ctl, doesn't
>> invoke the --clean option (which wouldn't work right even if it  
>> did, but
>> once it does). So I guess I should fix that and submit a patch too?
>>
>> I'm new to submitting patches for this kind of stuff. Can anyone
>> reccommend patch etiquette/procedure to do this properly? And/or  
>> confirm
>> that I'm approaching this sanely?
>>
>> Thanks for the help, all.
>>
>> Jonathan
>>
>> Simon Santoro wrote:
>>
>>> On Wednesday 05 March 2008 17:59:49 Jonathan Rochkind wrote:
>>>
>>>
>>>> What is the reccommended solution to this?
>>>>
>>>>
>>> I don't know, put there is a patch here:
>>> http://textsnippets.com/posts/show/931
>>> and a ticket got submitted here:
>>> http://rubyforge.org/tracker/index.php?func=detail&aid=11098&group_id=1306&atid=5147
>>>
>>> but it was not committed because "mongrel_rails now supports a -- 
>>> clean".
>>> my mongrel_rails does not support it, but I may have an old version.
>>>
>>> I think it would be right for mongrel to clean up it's stale pid  
>>> files. Every
>>> program I know of does that, and I patched my mongrel.
>>>
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>
>>>
>>
>>
>
> -- 
> Jonathan Rochkind
> Digital Services Software Engineer
> The Sheridan Libraries
> Johns Hopkins University
> 410.516.8886
> rochkind (at) jhu.edu
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From rochkind at jhu.edu  Wed Mar  5 15:29:23 2008
From: rochkind at jhu.edu (Jonathan Rochkind)
Date: Wed, 05 Mar 2008 15:29:23 -0500
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <0FABB3FD-3713-4455-9C09-1073808AC4C9@mojiti.com>
References: <47CED185.3030101@jhu.edu>
	<200803052016.22601.simon.santoro@gmail.com>
	<47CEF76B.2000003@jhu.edu> <47CEFC3D.4050604@jhu.edu>
	<0FABB3FD-3713-4455-9C09-1073808AC4C9@mojiti.com>
Message-ID: <47CF02A3.6020805@jhu.edu>

Okay, you're right. That did work, I didn't do a good job of removing 
mongrel_cluster-1.0.2 before. The question still remains, why the heck 
do I need to actually REMOVE 1.0.2 to get mongrel 1.1.4 to use it, when 
there's a newer mongrel_cluster 1.0.5 installed? This shouldn't actually 
be, should it?  Aren't you supposed to be able to have both installed in 
gems at once?   Anyone have any explanation for why mongrel was 
preferring the older one when both were installed? [It's this kind of 
thing that drives me nuts with ruby/rails, especially with deployment 
issues].

Now that I've gotten it to use mongrel_cluster 1.0.5, 
mongrel_cluster_ctl is indeed properly dealing with the --clean 
argument, that bug is gone.

Very frustrating. Thanks for the help all. Still plan to submit a patch 
for the resources/mongrel_cluster script to use --clean. Does this make 
sense?  That resource/mongrel_cluster script is mentioned in the 
mongrel_cluster README still, so it does seem like it's supposed to be 
still a non-deprecated thing?

Jonathan

Eden Li wrote:
> try
>
> sudo rm /usr/lib/ruby/gems/1.8/specifications/ 
> mongrel_cluster-1.0.2.gemspec
>
> i think your specs are stale
>
> On Mar 5, 2008, at 12:02 PM, Jonathan Rochkind wrote:
>
>   
>> Okay, I figured out more. Sorry for spamming the list. This is
>> frustrating me.
>>
>> I deleted mongrel_cluster 1.0.2 entirely. But check out this stack
>> trace. Why the heck is mongrel-1.1.4/bin/mongrel_rails requiring
>> mongrel_rails 1.0.2 and refusing to use mongrel_rails 1.0.5?
>>
>> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
>> `gem_original_require': no such file to load --
>> /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.2/lib/ 
>> mongrel_cluster/init.rb
>> (LoadError)
>>        from
>> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
>>        from
>> /usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb: 
>> 134:in `load'
>>        from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb: 
>> 142:in
>> `each'
>>        from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb: 
>> 142:in
>> `each'
>>        from
>> /usr/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb: 
>> 112:in `load'
>>        from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/bin/ 
>> mongrel_rails:278
>>        from /usr/bin/mongrel_rails:18:in `load'
>>        from /usr/bin/mongrel_rails:18
>>
>>
>> Jonathan Rochkind wrote:
>>     
>>> Yeah, I think that closing of that ticket is right. As far as
>>> mongrel_rails is concerned, it makes sense to use the --clean option,
>>> rather than put it in there to happen by default. (although actually,
>>> I'd have --clean be default).
>>>
>>> My problem is that I'm using mongrel_cluster_ctl instead of
>>> mongrel_rails. The nice feature of mongrel_cluster_ctl here is that  
>>> you
>>> can give it a -c argument which is a directory containing mongrel
>>> cluster yml files. And it will do the invoked operation to ALL of  
>>> those
>>> config files. I like this. I want to use it.
>>>
>>> And mongrel_cluster_ctl's --clean option appears to be broken to  
>>> me. I
>>> guess I should figure out how to fix it and submit a patch?
>>>
>>> The other problem is that the sample script at
>>> resources/mongrel_cluster, which invokes mongrel_cluster_ctl, doesn't
>>> invoke the --clean option (which wouldn't work right even if it  
>>> did, but
>>> once it does). So I guess I should fix that and submit a patch too?
>>>
>>> I'm new to submitting patches for this kind of stuff. Can anyone
>>> reccommend patch etiquette/procedure to do this properly? And/or  
>>> confirm
>>> that I'm approaching this sanely?
>>>
>>> Thanks for the help, all.
>>>
>>> Jonathan
>>>
>>> Simon Santoro wrote:
>>>
>>>       
>>>> On Wednesday 05 March 2008 17:59:49 Jonathan Rochkind wrote:
>>>>
>>>>
>>>>         
>>>>> What is the reccommended solution to this?
>>>>>
>>>>>
>>>>>           
>>>> I don't know, put there is a patch here:
>>>> http://textsnippets.com/posts/show/931
>>>> and a ticket got submitted here:
>>>> http://rubyforge.org/tracker/index.php?func=detail&aid=11098&group_id=1306&atid=5147
>>>>
>>>> but it was not committed because "mongrel_rails now supports a -- 
>>>> clean".
>>>> my mongrel_rails does not support it, but I may have an old version.
>>>>
>>>> I think it would be right for mongrel to clean up it's stale pid  
>>>> files. Every
>>>> program I know of does that, and I patched my mongrel.
>>>>
>>>> _______________________________________________
>>>> Mongrel-users mailing list
>>>> Mongrel-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>>
>>>>
>>>>         
>>>       
>> -- 
>> Jonathan Rochkind
>> Digital Services Software Engineer
>> The Sheridan Libraries
>> Johns Hopkins University
>> 410.516.8886
>> rochkind (at) jhu.edu
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>     
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu


From eden at mojiti.com  Wed Mar  5 17:02:51 2008
From: eden at mojiti.com (Eden Li)
Date: Wed, 5 Mar 2008 14:02:51 -0800
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <47CF02A3.6020805@jhu.edu>
References: <47CED185.3030101@jhu.edu>
	<200803052016.22601.simon.santoro@gmail.com>
	<47CEF76B.2000003@jhu.edu> <47CEFC3D.4050604@jhu.edu>
	<0FABB3FD-3713-4455-9C09-1073808AC4C9@mojiti.com>
	<47CF02A3.6020805@jhu.edu>
Message-ID: <67617D18-01BC-485C-ABA1-C1A3937FE3BD@mojiti.com>

I'm not sure why it prefers the oldest version, but the  
mongrel_cluster_ctl script effectively runs:

require_gem "mongrel_cluster", "> 0"

which seems like it would prefer the oldest.  reading the script a tad  
more, it looks like you can specify which version to run by passing in  
_VERSION_ (e.g. _1.0.5_) as the first argument to mongrel_cluster_ctl

On Mar 5, 2008, at 12:29 PM, Jonathan Rochkind wrote:

> Okay, you're right. That did work, I didn't do a good job of removing
> mongrel_cluster-1.0.2 before. The question still remains, why the heck
> do I need to actually REMOVE 1.0.2 to get mongrel 1.1.4 to use it,  
> when
> there's a newer mongrel_cluster 1.0.5 installed? This shouldn't  
> actually
> be, should it?  Aren't you supposed to be able to have both  
> installed in
> gems at once?   Anyone have any explanation for why mongrel was
> preferring the older one when both were installed? [It's this kind of
> thing that drives me nuts with ruby/rails, especially with deployment
> issues].
>
> Now that I've gotten it to use mongrel_cluster 1.0.5,
> mongrel_cluster_ctl is indeed properly dealing with the --clean
> argument, that bug is gone.
>
> Very frustrating. Thanks for the help all. Still plan to submit a  
> patch
> for the resources/mongrel_cluster script to use --clean. Does this  
> make
> sense?  That resource/mongrel_cluster script is mentioned in the
> mongrel_cluster README still, so it does seem like it's supposed to be
> still a non-deprecated thing?


From mohammed.a at aol.in  Wed Mar  5 17:04:21 2008
From: mohammed.a at aol.in (mohammed.a at aol.in)
Date: Wed, 05 Mar 2008 17:04:21 -0500
Subject: [Mongrel] problems with Mongrel + Pound
In-Reply-To: <325148f70802270020g55b091fay5f0ef84bc415eccc@mail.gmail.com>
References: <8CA466852327A10-D0C-3759@web-cen-v02.sim.aol.com>	<24E69670-2EB4-43B1-9897-46314FD06857@cheney.net>	<8CA467BA54ED6F0-D0C-3859@web-cen-v02.sim.aol.com>	<CBC7DB32-2A25-4D0C-BF00-2D22068D4F90@gmail.com>	<E49881E1-19D5-45E6-B2BA-C78A89326F65@airbladesoftware.com>	<8CA472B61107470-D0C-3E7E@web-cen-v02.sim.aol.com>	<00B61B4A-1D5E-4EEA-88F8-613DB9A02EFB@cheney.net>
	<325148f70802270020g55b091fay5f0ef84bc415eccc@mail.gmail.com>
Message-ID: <8CA4D23FFA9B560-7A8-2CB2@web-cen-v06.sim.aol.com>


 Switching to NGINX indeed fixed much of the problems. But mysql gem continues to evade no matter what kind of config I use. 
But SQL has been tuned up, major bugs have been tuned.

Much better now. Will post later with detailed analysis of the problem and solutions

regards

Mohammed. A


 


 

-----Original Message-----
From: Piyush Ranjan <piyush.pr at gmail.com>
To: mongrel-users at rubyforge.org
Sent: Wed, 27 Feb 2008 1:50 pm
Subject: Re: [Mongrel] problems with Mongrel + Pound









To install mysql gem you need to specify the mysql_config path(if it is not installed then into mysql dev or devel package)
To install sudo gem install mysql -- --with-mysql-config=<path-to-mysql_config like on my ubuntu it is /usr/bin/mysql_config>



And your problems are similar(not same) I used to encounter. I had these problems with my mongrel handler when it used to? write to database in asynchronous queries by the users. Log file used to scream connection lost to mysql. After spending a few days trying to boost up my mysql server I did the gem install and since then it has handled 100K + queries (the mongrel handler part of the app)each day without any problem whatsoever. 


Also switch to apache/ngnix if you can. Pound could also be the trouble maker though I am not very sure about this comment.
 

On Wed, Feb 27, 2008 at 1:29 PM, Dave Cheney <dave at cheney.net> wrote:



I hacked our vendor tree to explode on startup if the mysql gem could not be found. IMHO this should be the default?behavior,?the built in mysql adapter is crap and its silent use is a ticking time bomb




Cheers




Dave







On 27/02/2008, at 6:42 PM, mohammed.a at aol.in wrote:



Thank you for the replies.


Here's what I found - mysql gem was not installed and that maybe a core source of problems as suggested by Zed. We've had? too many problems when we tried to install this, and found that none of the solutions that are mentioned really work. We will try to install this gem again.?







_______________________________________________

Mongrel-users mailing list

Mongrel-users at rubyforge.org

http://rubyforge.org/mailman/listinfo/mongrel-users






 





_______________________________________________
Mongrel-users mailing list
Mongrel-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users



 


________________________________________________________________________
You are invited to Get a Free AOL Email ID. - http://webmail.aol.in
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080305/b37322c5/attachment-0001.html 

From rochkind at jhu.edu  Wed Mar  5 17:31:51 2008
From: rochkind at jhu.edu (Jonathan Rochkind)
Date: Wed, 05 Mar 2008 17:31:51 -0500
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <67617D18-01BC-485C-ABA1-C1A3937FE3BD@mojiti.com>
References: <47CED185.3030101@jhu.edu>
	<200803052016.22601.simon.santoro@gmail.com>
	<47CEF76B.2000003@jhu.edu> <47CEFC3D.4050604@jhu.edu>
	<0FABB3FD-3713-4455-9C09-1073808AC4C9@mojiti.com>
	<47CF02A3.6020805@jhu.edu>
	<67617D18-01BC-485C-ABA1-C1A3937FE3BD@mojiti.com>
Message-ID: <47CF1F57.5040702@jhu.edu>

Should I try to patch this to prefer the newest version instead?

If anyone's actually been following along, I filed a patch to fix 
resources/mongrel_cluster to pass --clean in.

http://rubyforge.org/tracker/index.php?func=detail&aid=18627&group_id=1306&atid=5147

Jonathan

Eden Li wrote:
> I'm not sure why it prefers the oldest version, but the  
> mongrel_cluster_ctl script effectively runs:
>
> require_gem "mongrel_cluster", "> 0"
>
> which seems like it would prefer the oldest.  reading the script a tad  
> more, it looks like you can specify which version to run by passing in  
> _VERSION_ (e.g. _1.0.5_) as the first argument to mongrel_cluster_ctl
>
> On Mar 5, 2008, at 12:29 PM, Jonathan Rochkind wrote:
>
>   
>> Okay, you're right. That did work, I didn't do a good job of removing
>> mongrel_cluster-1.0.2 before. The question still remains, why the heck
>> do I need to actually REMOVE 1.0.2 to get mongrel 1.1.4 to use it,  
>> when
>> there's a newer mongrel_cluster 1.0.5 installed? This shouldn't  
>> actually
>> be, should it?  Aren't you supposed to be able to have both  
>> installed in
>> gems at once?   Anyone have any explanation for why mongrel was
>> preferring the older one when both were installed? [It's this kind of
>> thing that drives me nuts with ruby/rails, especially with deployment
>> issues].
>>
>> Now that I've gotten it to use mongrel_cluster 1.0.5,
>> mongrel_cluster_ctl is indeed properly dealing with the --clean
>> argument, that bug is gone.
>>
>> Very frustrating. Thanks for the help all. Still plan to submit a  
>> patch
>> for the resources/mongrel_cluster script to use --clean. Does this  
>> make
>> sense?  That resource/mongrel_cluster script is mentioned in the
>> mongrel_cluster README still, so it does seem like it's supposed to be
>> still a non-deprecated thing?
>>     
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu


From jos at catnook.com  Thu Mar  6 12:29:37 2008
From: jos at catnook.com (Jos Backus)
Date: Thu, 6 Mar 2008 09:29:37 -0800
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <8be813400803050957xa51710cxf7c67e567694db64@mail.gmail.com>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu> <47CEDC4F.5020202@jhu.edu>
	<8be813400803050957xa51710cxf7c67e567694db64@mail.gmail.com>
Message-ID: <20080306172937.GA24906@lizzy.catnook.local>

On Wed, Mar 05, 2008 at 11:57:44AM -0600, Nate Vack wrote:
> I'm doing everything (everything!) via either monit (on linux) or SMF
> (on Solaris).
> 
> Using a process manager is a good idea... and having only one
> 'production' way to start mongrel is generally a good thing, too :)

If only Mongrel/mongrel_cluster would work with daemontools/runit. Pid files
are evil.

(Maybe Thin will grow support for this;
http://thin.lighthouseapp.com/projects/7212/tickets/40-support-running-thin-under-daemontools-runit)

-- 
Jos Backus
jos at catnook.com

From alexey.verkhovsky at gmail.com  Thu Mar  6 14:41:11 2008
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Thu, 6 Mar 2008 12:41:11 -0700
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <20080306172937.GA24906@lizzy.catnook.local>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu> <47CEDC4F.5020202@jhu.edu>
	<8be813400803050957xa51710cxf7c67e567694db64@mail.gmail.com>
	<20080306172937.GA24906@lizzy.catnook.local>
Message-ID: <3945c4270803061141s5b2c66d2pbf23c8affb9bd4f9@mail.gmail.com>

On Thu, Mar 6, 2008 at 10:29 AM, Jos Backus <jos at catnook.com> wrote:
>  If only Mongrel/mongrel_cluster would work with daemontools/runit. Pid files
>  are evil.

Mongrel runs perfectly well with runit.

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

From jeremy at bitsweat.net  Thu Mar  6 14:51:35 2008
From: jeremy at bitsweat.net (Jeremy Kemper)
Date: Thu, 6 Mar 2008 11:51:35 -0800
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <20080306172937.GA24906@lizzy.catnook.local>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu> <47CEDC4F.5020202@jhu.edu>
	<8be813400803050957xa51710cxf7c67e567694db64@mail.gmail.com>
	<20080306172937.GA24906@lizzy.catnook.local>
Message-ID: <69a2885c0803061151v312aaa79h58b584bd0b4de10f@mail.gmail.com>

On Thu, Mar 6, 2008 at 9:29 AM, Jos Backus <jos at catnook.com> wrote:
> On Wed, Mar 05, 2008 at 11:57:44AM -0600, Nate Vack wrote:
>  > I'm doing everything (everything!) via either monit (on linux) or SMF
>  > (on Solaris).
>  >
>  > Using a process manager is a good idea... and having only one
>  > 'production' way to start mongrel is generally a good thing, too :)
>
>  If only Mongrel/mongrel_cluster would work with daemontools/runit. Pid files
>  are evil.
>
>  (Maybe Thin will grow support for this;
>  http://thin.lighthouseapp.com/projects/7212/tickets/40-support-running-thin-under-daemontools-runit)

Mongrel works great with process supervision. We use runit
extensively; it has eliminated all the pidfile & deployment headaches
discussed here.

jeremy

From drbuettner at gmail.com  Thu Mar  6 15:15:15 2008
From: drbuettner at gmail.com (Dan Buettner)
Date: Thu, 6 Mar 2008 20:15:15 +0000
Subject: [Mongrel] mongrel and uploaded files (temp location)
Message-ID: <c97ba7a80803061215g2ef7e854s59d478aa2a478e20@mail.gmail.com>

Asked this about a month ago but no response - would appreciate any thoughts
anyone might have.

I'd like to change where mongrel stores files uploaded via web form from the
local tmp dir to a place on the same filesystem where they will eventually
reside, due to speed considerations (copying from tmp to NFS mount takes a
little time while the user wait for the web form to return)

Is there a way to do this do you think?

Thanks for any info,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080306/6134391c/attachment.html 

From wyhaines at gmail.com  Thu Mar  6 15:26:23 2008
From: wyhaines at gmail.com (Kirk Haines)
Date: Thu, 6 Mar 2008 13:26:23 -0700
Subject: [Mongrel] mongrel and uploaded files (temp location)
In-Reply-To: <c97ba7a80803061215g2ef7e854s59d478aa2a478e20@mail.gmail.com>
References: <c97ba7a80803061215g2ef7e854s59d478aa2a478e20@mail.gmail.com>
Message-ID: <f4cd26df0803061226q3b345e37j81b60e38e28e653e@mail.gmail.com>

On Thu, Mar 6, 2008 at 1:15 PM, Dan Buettner <drbuettner at gmail.com> wrote:

> I'd like to change where mongrel stores files uploaded via web form from the
> local tmp dir to a place on the same filesystem where they will eventually
> reside, due to speed considerations (copying from tmp to NFS mount takes a
> little time while the user wait for the web form to return)
>
> Is there a way to do this do you think?

There's a way to do most anything.

Mongrel just uses Tempfile.  Tempfile just uses Dir::tmpdir, provided
by tmpdir.rb, to determine the temporary directory.

Dir::tmpdir defaults to /tmp, but it checks some environment variables first.

ENV['TMPDIR']
ENV['TMP']
ENV['TEMP']
ENV['USERPROFILE']

Just set one of those to the directory that you want it to use.



Kirk Haines

From johnjosephbachir at gmail.com  Thu Mar  6 18:31:56 2008
From: johnjosephbachir at gmail.com (John Joseph Bachir)
Date: Thu, 6 Mar 2008 18:31:56 -0500
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <200803052016.22601.simon.santoro@gmail.com>
References: <47CED185.3030101@jhu.edu>
	<200803052016.22601.simon.santoro@gmail.com>
Message-ID: <4a3752180803061531v3f001dceycdd2d1aeeb6e1d53@mail.gmail.com>

On Wed, Mar 5, 2008 at 2:16 PM, Simon Santoro <simon.santoro at gmail.com> wrote:
>  there is a patch here:
>  http://textsnippets.com/posts/show/931
>  and a ticket got submitted here:
>  http://rubyforge.org/tracker/index.php?func=detail&aid=11098&group_id=1306&atid=5147
>
>  but it was not committed because "mongrel_rails now supports a --clean".
>  my mongrel_rails does not support it, but I may have an old version.
>
>  I think it would be right for mongrel to clean up it's stale pid files. Every
>  program I know of does that, and I patched my mongrel.


Furthermore, the behavior of the --clean feature isn't very
elaborately documented (at least not in the output of mongrel_rails
cluster::start -h). I left this comment on the ticket (no way to
reopen it I guess):

----
The patch mentioned checks if the pid files refer to running processes.

Does the --clean feature do this? Or does it just blindly remove the pid files?

An additionally nice and easy feature would be to check if the running
process contains the string "mongrel".


John

-- 
John Joseph Bachir
http://blog.johnjosephbachir.org
http://lyceum.ibiblio.org
http://dissent.cc
http://jjb.cc

From jos at catnook.com  Thu Mar  6 20:39:19 2008
From: jos at catnook.com (Jos Backus)
Date: Thu, 6 Mar 2008 17:39:19 -0800
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <69a2885c0803061151v312aaa79h58b584bd0b4de10f@mail.gmail.com>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu> <47CEDC4F.5020202@jhu.edu>
	<8be813400803050957xa51710cxf7c67e567694db64@mail.gmail.com>
	<20080306172937.GA24906@lizzy.catnook.local>
	<69a2885c0803061151v312aaa79h58b584bd0b4de10f@mail.gmail.com>
Message-ID: <20080307013919.GA11168@lizzy.catnook.local>

On Thu, Mar 06, 2008 at 11:51:35AM -0800, Jeremy Kemper wrote:
> Mongrel works great with process supervision. We use runit
> extensively; it has eliminated all the pidfile & deployment headaches
> discussed here.
 
So how does this work? What watches the multiple mongrels running in the
foreground? Running each mongrel process as a separate service is ugly imo, it
would be much nicer to have a supervised multi_mongrel controller (that's the
idea described in the Thin feature request).

-- 
Jos Backus
jos at catnook.com

From alexey.verkhovsky at gmail.com  Fri Mar  7 01:42:04 2008
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Thu, 6 Mar 2008 23:42:04 -0700
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <20080307013919.GA11168@lizzy.catnook.local>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu> <47CEDC4F.5020202@jhu.edu>
	<8be813400803050957xa51710cxf7c67e567694db64@mail.gmail.com>
	<20080306172937.GA24906@lizzy.catnook.local>
	<69a2885c0803061151v312aaa79h58b584bd0b4de10f@mail.gmail.com>
	<20080307013919.GA11168@lizzy.catnook.local>
Message-ID: <3945c4270803062242l534fcb9dteaa31c2f8cedf641@mail.gmail.com>

On Thu, Mar 6, 2008 at 6:39 PM, Jos Backus <jos at catnook.com> wrote:
>  So how does this work? What watches the multiple mongrels running in the
>  foreground? Running each mongrel process as a separate service is ugly imo, it
>  would be much nicer to have a supervised multi_mongrel controller (that's the
>  idea described in the Thin feature request).

Here is one example of how this can be done:
http://rubyworks.rubyforge.org/manual/runit.html

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

From rochkind at jhu.edu  Fri Mar  7 09:56:45 2008
From: rochkind at jhu.edu (Jonathan Rochkind)
Date: Fri, 07 Mar 2008 09:56:45 -0500
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <4a3752180803061531v3f001dceycdd2d1aeeb6e1d53@mail.gmail.com>
References: <47CED185.3030101@jhu.edu>
	<200803052016.22601.simon.santoro@gmail.com>
	<4a3752180803061531v3f001dceycdd2d1aeeb6e1d53@mail.gmail.com>
Message-ID: <47D157AD.6010604@jhu.edu>

The --clean feature, in my testing, seems to indeed checks to make sure 
that pid files really -are- stale (ie, the pid listed in there does not 
correspond to any running process) before deleting them. 

I still don't understand why --clean isn't the default behavior though, 
but I guess the developer didn't like that for some reason. Seems to me 
documentation should recommend everyone always use --clean----especially 
in any automated scripts that will be run unattended!

Jonathan

John Joseph Bachir wrote:
> On Wed, Mar 5, 2008 at 2:16 PM, Simon Santoro <simon.santoro at gmail.com> wrote:
>   
>>  there is a patch here:
>>  http://textsnippets.com/posts/show/931
>>  and a ticket got submitted here:
>>  http://rubyforge.org/tracker/index.php?func=detail&aid=11098&group_id=1306&atid=5147
>>
>>  but it was not committed because "mongrel_rails now supports a --clean".
>>  my mongrel_rails does not support it, but I may have an old version.
>>
>>  I think it would be right for mongrel to clean up it's stale pid files. Every
>>  program I know of does that, and I patched my mongrel.
>>     
>
>
> Furthermore, the behavior of the --clean feature isn't very
> elaborately documented (at least not in the output of mongrel_rails
> cluster::start -h). I left this comment on the ticket (no way to
> reopen it I guess):
>
> ----
> The patch mentioned checks if the pid files refer to running processes.
>
> Does the --clean feature do this? Or does it just blindly remove the pid files?
>
> An additionally nice and easy feature would be to check if the running
> process contains the string "mongrel".
>
>
> John
>
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu


From jos at catnook.com  Fri Mar  7 12:51:18 2008
From: jos at catnook.com (Jos Backus)
Date: Fri, 7 Mar 2008 09:51:18 -0800
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <3945c4270803062242l534fcb9dteaa31c2f8cedf641@mail.gmail.com>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu> <47CEDC4F.5020202@jhu.edu>
	<8be813400803050957xa51710cxf7c67e567694db64@mail.gmail.com>
	<20080306172937.GA24906@lizzy.catnook.local>
	<69a2885c0803061151v312aaa79h58b584bd0b4de10f@mail.gmail.com>
	<20080307013919.GA11168@lizzy.catnook.local>
	<3945c4270803062242l534fcb9dteaa31c2f8cedf641@mail.gmail.com>
Message-ID: <20080307175118.GA72219@lizzy.catnook.local>

On Thu, Mar 06, 2008 at 11:42:04PM -0700, Alexey Verkhovsky wrote:
> On Thu, Mar 6, 2008 at 6:39 PM, Jos Backus <jos at catnook.com> wrote:
> >  So how does this work? What watches the multiple mongrels running in the
> >  foreground? Running each mongrel process as a separate service is ugly imo, it
> >  would be much nicer to have a supervised multi_mongrel controller (that's the
> >  idea described in the Thin feature request).
> 
> Here is one example of how this can be done:
> http://rubyworks.rubyforge.org/manual/runit.html

Looks like a separate service is used for each Mongrel. Of course that can be
done easily. The solution I'm looking for manages multiple Mongrels under a
single service, just like Apache manages its own worker children.

Thanks for the link, Alexey.

-- 
Jos Backus
jos at catnook.com

From njvack at wisc.edu  Fri Mar  7 13:10:23 2008
From: njvack at wisc.edu (Nate Vack)
Date: Fri, 7 Mar 2008 12:10:23 -0600
Subject: [Mongrel] mongrel_cluster, start on boot, stale pids
In-Reply-To: <20080307175118.GA72219@lizzy.catnook.local>
References: <47CED185.3030101@jhu.edu>
	<A26294D7-D427-416D-9F40-E1E9D2409598@mojiti.com>
	<47CEDB0A.6070406@jhu.edu> <47CEDC4F.5020202@jhu.edu>
	<8be813400803050957xa51710cxf7c67e567694db64@mail.gmail.com>
	<20080306172937.GA24906@lizzy.catnook.local>
	<69a2885c0803061151v312aaa79h58b584bd0b4de10f@mail.gmail.com>
	<20080307013919.GA11168@lizzy.catnook.local>
	<3945c4270803062242l534fcb9dteaa31c2f8cedf641@mail.gmail.com>
	<20080307175118.GA72219@lizzy.catnook.local>
Message-ID: <8be813400803071010i4f365bcav69ec6ce1771eb7cb@mail.gmail.com>

On Fri, Mar 7, 2008 at 11:51 AM, Jos Backus <jos at catnook.com> wrote:

>  Looks like a separate service is used for each Mongrel. Of course that can be
>  done easily. The solution I'm looking for manages multiple Mongrels under a
>  single service, just like Apache manages its own worker children.

As far as I know, Mongrel doesn't do that -- there's no parent process
managing worker children at all; every mongrel is, in effect, an
independent peer. I'm not sure of the technical reason for this --
perhaps spawning workers is too expensive (or workers are generally
too large) for this to be effective in practice?

I was also a bit confused by this at first, having come from the
Apache world -- but yeah, I've never seen any solution that didn't
involve treating every mongrel as a separate service.

Cheers,
-Nate

From lists at ruby-forum.com  Fri Mar  7 14:39:06 2008
From: lists at ruby-forum.com (Eduardo Silva)
Date: Fri, 7 Mar 2008 20:39:06 +0100
Subject: [Mongrel] Piping logs to rotatelog
Message-ID: <95f6942716c1728c5ef8cd54d41116ad@ruby-forum.com>

Mongrel clusters lets yuo pick a path to your logs with the "-l "
switch. I tried giving a pathc that contains the rotatelogs like

-l
|/usr/sbin/rotatelogs /var/log/mongrel.log 3600"

And it just gave me error. So I rolledup my sleeves and dig into:

1)
/usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.5/lib/mongrel_cluster/init.rb

2) /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.4/lib/mongrel/configurator.rb

I tried to re-built the log file name so on "1)" if passes and ARGV
like:

       ##exec_cmd +=" -l  #{port_log_file(port)}"
       exec_cmd +=" -l |/home/admin/rotatelogs #{port_log_file(port)}
30"

but I get this:
starting port 3001
mongrel_rails start -d -e production -p 3001 -P log/silvex.3001.pid -l
|/home/admin/rotatelogs /var/log/my_mongrel3300.3001.log 30
ERROR RUNNING 'mongrel::start': missing argument: -l
Use help command to get help

Silvex ...
starting port 3002
mongrel_rails start -d -e production -p 3002 -P log/silvex.3002.pid -l
|/home/admin/rotatelogs /var/log/my_mongrel3300.3002.log 30
ERROR RUNNING 'mongrel::start': missing argument: -l
Use help command to get help

I tried a similar stunt on "2)" with

      logfile = ops[:log_file]
        ##if logfile[0].chr != "/"
         #logfile = File.join(ops[:cwd],logfile)
         #if not File.exist?(File.dirname(logfile))
         #   log "!!! Log file directory not found at full path
#{File.dirname(logfile)}.  Update your configuration to use a full
path."
         #   exit 1
         # end
        #end

        lati_logfile = "|/home/admin/rotatelogs " + logfile + " 15"
        rotate_log = File.popen(lati_logfile,"w")

        #Daemonize.daemonize(logfile)
        Daemonize.daemonize(rotate_log)

Is this EVEN feasiable ?
-- 
Posted via http://www.ruby-forum.com/.

From lists at ruby-forum.com  Sat Mar  8 10:41:27 2008
From: lists at ruby-forum.com (Ben Blakley)
Date: Sat, 8 Mar 2008 16:41:27 +0100
Subject: [Mongrel] restarting cluster without killing in progress file
	uploads
Message-ID: <a2ad5e205059dee2ef56362c1d845723@ruby-forum.com>

Hello,

I have a cluster of three Mongrels running behind Pound. All is running
well except when I restart the cluster (mongrel_rails cluster::restart)
any in progress file uploads (handled through mongrel_upload_progress)
stop uploading. That is, if I'm uploading a file (via a web app being
served by the mongrel cluster) during a restart, my browser will
indefinitely pause as if it is still uploading the file but I can see
from my computer's bandwidth usage that the file has indeed stopped
uploading. I tried the rolling restart technique discussed in the
following post but the result is the same:

http://www.ruby-forum.com/topic/130285

Anyone have any ideas how this can be solved? Or please let me know if
you need more information. Thanks!
-- 
Posted via http://www.ruby-forum.com/.

From lists at ruby-forum.com  Sat Mar  8 21:48:29 2008
From: lists at ruby-forum.com (Eduardo Silva)
Date: Sun, 9 Mar 2008 03:48:29 +0100
Subject: [Mongrel] Timestamping in log file?
In-Reply-To: <ef3e5d50711211529l73f0479cn134803005bd943ba@mail.gmail.com>
References: <20071120192112.23C9C18585D2@rubyforge.org>
	<ef3e5d50711201848s3c399fcbsf24f53c763c24cb7@mail.gmail.com>
	<ef3e5d50711201947q63b382feub5a0288d10f2c8ca@mail.gmail.com>
	<327FCCA3-9BEA-4C11-B381-F4DC2E7EC209@ncsu.edu>
	<ef3e5d50711211529l73f0479cn134803005bd943ba@mail.gmail.com>
Message-ID: <a0e27e7fb829835aefa0325d79f90292@ruby-forum.com>

Wayne E. Seguin wrote:
> On Nov 21, 2007 3:08 PM, Jason Young <jason.young at ncsu.edu> wrote:
>> HOORAY!  HOORAY!  HOORAY!
>>
>> Jason
> 
> :)
> 
> Please let me know if you find any issues.
> 
> Thanks,
> 
>   ~Wayne

Any changes of being able to  "pipe" log(s) to "crono/rotatelogs" like a 
apache does ?
-- 
Posted via http://www.ruby-forum.com/.

From lists at ruby-forum.com  Sat Mar  8 23:58:36 2008
From: lists at ruby-forum.com (Nathan Esquenazi)
Date: Sun, 9 Mar 2008 05:58:36 +0100
Subject: [Mongrel] Offloading Background Tasks
In-Reply-To: <42642c790803040636x5830a20x5f20ce43aa058784@mail.gmail.com>
References: <2d8ffda38541bfdc3425ca8511bfcd00@ruby-forum.com>
	<20080302025200.5B44F1858660@rubyforge.org>
	<42642c790803040636x5830a20x5f20ce43aa058784@mail.gmail.com>
Message-ID: <e3eb064df5c4f11ea7736265cf8053b5@ruby-forum.com>

Thanks for your responses. Just wanted to reply back that I installed 
backgroundrb (the new version) and I definitely appreciate how useful it 
is and how it is fairly easy to use.

Thanks for all your hard work Hermant.
-- 
Posted via http://www.ruby-forum.com/.

From lists at ruby-forum.com  Sun Mar  9 00:31:44 2008
From: lists at ruby-forum.com (Nathan Esquenazi)
Date: Sun, 9 Mar 2008 06:31:44 +0100
Subject: [Mongrel] best practices for monitoring mongrels with monit?
In-Reply-To: <57babe2b0803041837y4058975apb04de9d94ae5c42d@mail.gmail.com>
References: <57babe2b0803041837y4058975apb04de9d94ae5c42d@mail.gmail.com>
Message-ID: <46c0e1e6bfacaacbe3ed5c6bf3699f19@ruby-forum.com>

Here is a good recipe for a mongrel process, as provided on some site I 
found:

(I believe the forum post was by Ezra)

check process mongrel_cluster_8000
   with pidfile /var/apps/twocb/shared/pids/mongrel.8000.pid
   start program = "/usr/bin/mongrel_rails cluster::start -C 
/var/apps/twocb/current/config/mongrel_cluster.yml --clean --only 8000"
   stop program = "/usr/bin/mongrel_rails cluster::stop -C 
/var/apps/twocb/current/config/mongrel_cluster.yml --clean --only 8000"
   if totalmem is greater than 110.0 MB for 4 cycles then  restart
# eating up memory?
   if cpu is greater than 50% for 2 cycles then  alert
 # send an email to admin
   if cpu is greater than 80% for 3 cycles then  restart
# hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  restart
# bad, bad, bad
   if 20 restarts within 20 cycles then timeout
# something is wrong, call the sys-admin
   group mongrel_cluster
-- 
Posted via http://www.ruby-forum.com/.

From dave at cheney.net  Sun Mar  9 01:16:07 2008
From: dave at cheney.net (Dave Cheney)
Date: Sun, 9 Mar 2008 17:16:07 +1100
Subject: [Mongrel] restarting cluster without killing in progress file
	uploads
In-Reply-To: <a2ad5e205059dee2ef56362c1d845723@ruby-forum.com>
References: <a2ad5e205059dee2ef56362c1d845723@ruby-forum.com>
Message-ID: <0AA04937-7852-43D5-8EA7-73BE0F3C2897@cheney.net>

I can't think of a solution to the problem if you need to use  
mongrel_upload_progress as the mongrel that is handling the upload is  
the one you are restarting.

If you can avoid using an upload monitor then i suggest letting nginx  
handle your uploads, it can be configured to try every backend mongrel  
in sequence and only drop the upload if all of them are out of service.

Cheers

Dave

On 09/03/2008, at 2:41 AM, Ben Blakley wrote:

> Hello,
>
> I have a cluster of three Mongrels running behind Pound. All is  
> running
> well except when I restart the cluster (mongrel_rails  
> cluster::restart)
> any in progress file uploads (handled through mongrel_upload_progress)
> stop uploading. That is, if I'm uploading a file (via a web app being
> served by the mongrel cluster) during a restart, my browser will
> indefinitely pause as if it is still uploading the file but I can see
> from my computer's bandwidth usage that the file has indeed stopped
> uploading. I tried the rolling restart technique discussed in the
> following post but the result is the same:
>
> http://www.ruby-forum.com/topic/130285
>
> Anyone have any ideas how this can be solved? Or please let me know if
> you need more information. Thanks!
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From gethemant at gmail.com  Sun Mar  9 03:16:41 2008
From: gethemant at gmail.com (hemant kumar)
Date: Sun, 09 Mar 2008 12:46:41 +0530
Subject: [Mongrel] Offloading Background Tasks
In-Reply-To: <e3eb064df5c4f11ea7736265cf8053b5@ruby-forum.com>
References: <2d8ffda38541bfdc3425ca8511bfcd00@ruby-forum.com>
	<20080302025200.5B44F1858660@rubyforge.org>
	<42642c790803040636x5830a20x5f20ce43aa058784@mail.gmail.com>
	<e3eb064df5c4f11ea7736265cf8053b5@ruby-forum.com>
Message-ID: <1205047001.16817.3.camel@shire>


On Sun, 2008-03-09 at 05:58 +0100, Nathan Esquenazi wrote:
> Thanks for your responses. Just wanted to reply back that I installed 
> backgroundrb (the new version) and I definitely appreciate how useful it 
> is and how it is fairly easy to use.
> 
> Thanks for all your hard work Hermant.

No problems!

If you are having any problems feel free to shoot your questions on
BackgrounDRb mailing list.






From lists at ruby-forum.com  Mon Mar 10 11:50:27 2008
From: lists at ruby-forum.com (Ben Blakley)
Date: Mon, 10 Mar 2008 16:50:27 +0100
Subject: [Mongrel] restarting cluster without killing in progress file
	uplo
In-Reply-To: <0AA04937-7852-43D5-8EA7-73BE0F3C2897@cheney.net>
References: <a2ad5e205059dee2ef56362c1d845723@ruby-forum.com>
	<0AA04937-7852-43D5-8EA7-73BE0F3C2897@cheney.net>
Message-ID: <ee202a1b6bafcedd6fb94074643046c0@ruby-forum.com>

Thanks Dave. I switched from Pound and mongrel_upload_progress to Nginx 
and its upload progress module as described at the following address:

http://nginx.fehot.com/NginxHttpUploadProgressModule

It's working really well. Thanks again.

Ben
-- 
Posted via http://www.ruby-forum.com/.

From john at oxyliquit.de  Tue Mar 11 12:21:19 2008
From: john at oxyliquit.de (Jonathan Buch)
Date: Tue, 11 Mar 2008 17:21:19 +0100
Subject: [Mongrel] Mongrel 1.1.4, possible bug http_response
Message-ID: <op.t7u01tmbxegpx6@jo.local>

Hi,

I found this while digging inside mongrel to provide IO streaming
for mongrel (and thus for Rack and Ramaze):

* In socket_error a local variable done is set, which has no effect.
* done=() always sets to true, where it (for completeness sake) should
   honor the passed value.


--- a/http_response.rb	2008-03-11 16:59:24.000000000 +0100
+++ b/http_response.rb	2008-03-11 17:02:20.000000000 +0100
@@ -129,7 +129,7 @@
      def socket_error(details)
        # ignore these since it means the client closed off early
        @socket.close rescue nil
-      done = true
+      self.done = true
        raise details
      end

@@ -150,9 +150,9 @@
      # Used during error conditions to mark the response as "done" so  
there isn't any more processing
      # sent to the client.
      def done=(val)
-      @status_sent = true
-      @header_sent = true
-      @body_sent = true
+      @status_sent = val
+      @header_sent = val
+      @body_sent = val
      end

      def done

* If done=() is never reverted, it might be more beneficial to replace
   done=(val) just by a done!() and call that in socket_error() instead.

Regards,

Jo

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From evan at cloudbur.st  Tue Mar 11 15:20:02 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Tue, 11 Mar 2008 15:20:02 -0400
Subject: [Mongrel] Mongrel 1.1.4, possible bug http_response
In-Reply-To: <op.t7u01tmbxegpx6@jo.local>
References: <op.t7u01tmbxegpx6@jo.local>
Message-ID: <b6f68fc60803111220j22fb1c42j5a8985eb36b0edb5@mail.gmail.com>

Thanks. File a ticket please if you think it's definitely bug:

http://mongrel.rubyforge.org/report/1

Evan

On Tue, Mar 11, 2008 at 12:21 PM, Jonathan Buch <john at oxyliquit.de> wrote:
> Hi,
>
>  I found this while digging inside mongrel to provide IO streaming
>  for mongrel (and thus for Rack and Ramaze):
>
>  * In socket_error a local variable done is set, which has no effect.
>  * done=() always sets to true, where it (for completeness sake) should
>    honor the passed value.
>
>
>  --- a/http_response.rb  2008-03-11 16:59:24.000000000 +0100
>  +++ b/http_response.rb  2008-03-11 17:02:20.000000000 +0100
>  @@ -129,7 +129,7 @@
>       def socket_error(details)
>         # ignore these since it means the client closed off early
>         @socket.close rescue nil
>  -      done = true
>  +      self.done = true
>         raise details
>       end
>
>  @@ -150,9 +150,9 @@
>       # Used during error conditions to mark the response as "done" so
>  there isn't any more processing
>       # sent to the client.
>       def done=(val)
>  -      @status_sent = true
>  -      @header_sent = true
>  -      @body_sent = true
>  +      @status_sent = val
>  +      @header_sent = val
>  +      @body_sent = val
>       end
>
>       def done
>
>  * If done=() is never reverted, it might be more beneficial to replace
>    done=(val) just by a done!() and call that in socket_error() instead.
>
>  Regards,
>
>  Jo
>
>  --
>  Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>  _______________________________________________
>  Mongrel-users mailing list
>  Mongrel-users at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Evan Weaver
Cloudburst, LLC

From petite.abeille at gmail.com  Tue Mar 11 15:34:31 2008
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 11 Mar 2008 20:34:31 +0100
Subject: [Mongrel] [OT] HTTP headers status diagram
Message-ID: <AF49391F-5CA2-4801-9370-43D525C0AC29@gmail>

To paraphrase Woody Allen:

"Everything you always wanted to know about HTTP headers status, but  
were afraid to ask"

Alternatively:

"An activity diagram to describe the resolution of HTTP response  
status codes, given various headers."

http://thoughtpad.net/alan-dean/http-headers-status.html

http://thoughtpad.net/alan-dean/http-headers-status.gif

Cheers,

--
PA
http://alt.textdrive.com/nanoki/

From john at oxyliquit.de  Tue Mar 11 15:48:25 2008
From: john at oxyliquit.de (Jonathan Buch)
Date: Tue, 11 Mar 2008 20:48:25 +0100
Subject: [Mongrel] Mongrel 1.1.4, possible bug http_response
In-Reply-To: <b6f68fc60803111220j22fb1c42j5a8985eb36b0edb5@mail.gmail.com>
References: <op.t7u01tmbxegpx6@jo.local>
	<b6f68fc60803111220j22fb1c42j5a8985eb36b0edb5@mail.gmail.com>
Message-ID: <op.t7vamzmhxegpx6@jo.local>

Hi,

> Thanks. File a ticket please if you think it's definitely bug:
>
> http://mongrel.rubyforge.org/report/1

sorry to be a bother, but:

I can't decide if it is really a bug, as my knowledge regarding mongrel
innards is next to non-existant.
The implications of 'done' being set or not set in certain corner cases
is not something which I can easily be sure of.

>>  I found this while digging inside mongrel to provide IO streaming
>>  for mongrel (and thus for Rack and Ramaze):
>>
>>  * In socket_error a local variable done is set, which has no effect.
>>  * done=() always sets to true, where it (for completeness sake) should
>>    honor the passed value.
>>  * If done=() is never reverted, it might be more beneficial to replace
>>    done=(val) just by a done!() and call that in socket_error() instead.

As I see it, done=() is never called at the moment (I might be wrong), and
Mongrel still works.  Making done=() work correctly might have other
implications.  Right now it might process additional handlers (mongrel.rb:
160) which it might not do after the fix.

Jo

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From public at misuse.org  Tue Mar 11 16:17:47 2008
From: public at misuse.org (Steve Midgley)
Date: Tue, 11 Mar 2008 13:17:47 -0700
Subject: [Mongrel] [OT] HTTP headers status diagram
In-Reply-To: <mailman.239.1205264081.26975.mongrel-users@rubyforge.org>
References: <mailman.239.1205264081.26975.mongrel-users@rubyforge.org>
Message-ID: <20080311201802.CCFA418585FA@rubyforge.org>

At 12:34 PM 3/11/2008, mongrel-users-request at rubyforge.org wrote:
>Date: Tue, 11 Mar 2008 20:34:31 +0100
>From: Petite Abeille <petite.abeille at gmail.com>
>Subject: [Mongrel] [OT] HTTP headers status diagram
>To: mongrel-users at rubyforge.org
>Message-ID: <AF49391F-5CA2-4801-9370-43D525C0AC29 at gmail>
>
>[snip]
>"An activity diagram to describe the resolution of HTTP response
>status codes, given various headers."
>
>http://thoughtpad.net/alan-dean/http-headers-status.html
>
>http://thoughtpad.net/alan-dean/http-headers-status.gif

Wow - a state diagram for HTTP response codes. I'm impressed you've put 
this together - it ought to help people building new app servers for 
sure (and it seems there's a new one every week). You should send this 
up to W3 too - I've never seen anything like it on their site (but 
haven't looked specifically either).

Nice one,

Steve


From petite.abeille at gmail.com  Tue Mar 11 16:24:24 2008
From: petite.abeille at gmail.com (Petite Abeille)
Date: Tue, 11 Mar 2008 21:24:24 +0100
Subject: [Mongrel] [OT] HTTP headers status diagram
In-Reply-To: <47d6e8fa.1de0220a.41fe.7df1SMTPIN_ADDED@mx.google.com>
References: <mailman.239.1205264081.26975.mongrel-users@rubyforge.org>
	<47d6e8fa.1de0220a.41fe.7df1SMTPIN_ADDED@mx.google.com>
Message-ID: <866EF2EA-A46D-4047-8965-15F8AB91C168@gmail>


On Mar 11, 2008, at 9:17 PM, Steve Midgley wrote:

> Wow - a state diagram for HTTP response codes. I'm impressed you've  
> put this together

Full credit to Alan Dean for this gem.

http://thoughtpad.net/alan-dean/http-headers-status.html

> - it ought to help people building new app servers for sure (and it  
> seems there's a new one every week).

Indeed :)

Here is one in Lua:

http://svr225.stepx.com:3388/nanoki

> You should send this up to W3 too - I've never seen anything like it  
> on their site (but haven't looked specifically either).


Cheers,

PA.


From www at saepia.net  Wed Mar 12 04:32:59 2008
From: www at saepia.net (Marcin Lewandowski)
Date: Wed, 12 Mar 2008 09:32:59 +0100
Subject: [Mongrel] Mongrel has crashed
Message-ID: <47D7953B.4020600@saepia.net>

Hi,

my mongrel has crashed with following errors in the logfile:

** Starting Rails with development environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no 
restart).
** Rails signals registered.  HUP => reload (without restart).  It might 
not work well.
** Mongrel 1.1.3 available at 0.0.0.0:3000
** Writing PID file to ./script/../config/../tmp/pids/mongrel.pid
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/core_ext/module/inclusion.rb:4: 
[BUG] gc_sweep(): unknown data type 0x0(0xa8b2241c)
ruby 1.8.6 (2008-03-03) [i686-linux]


Rails 1.2.6

What's wrong?

My system is too important to hang up in so stupid way and it's too late 
to choose something different than rails..

m.

From wyhaines at gmail.com  Wed Mar 12 12:33:58 2008
From: wyhaines at gmail.com (Kirk Haines)
Date: Wed, 12 Mar 2008 10:33:58 -0600
Subject: [Mongrel] Mongrel has crashed
In-Reply-To: <47D7953B.4020600@saepia.net>
References: <47D7953B.4020600@saepia.net>
Message-ID: <f4cd26df0803120933w663787ddyd1228dace2191122@mail.gmail.com>

On Wed, Mar 12, 2008 at 2:32 AM, Marcin Lewandowski <www at saepia.net> wrote:

> /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/core_ext/module/inclusion.rb:4:
> [BUG] gc_sweep(): unknown data type 0x0(0xa8b2241c)
> ruby 1.8.6 (2008-03-03) [i686-linux]
>
>
> Rails 1.2.6
>
> What's wrong?

That's a fatal Ruby exception.  Something triggered an error that the
Ruby interpreter thinks is a bug in the interpreter.

Did this happen just once, or are you getting it often?  Do you have
anything monitoring the mongrel processes so that if they do go away,
they can be restarted?


Kirk Haines

From njvack at wisc.edu  Wed Mar 12 12:52:13 2008
From: njvack at wisc.edu (Nate Vack)
Date: Wed, 12 Mar 2008 11:52:13 -0500
Subject: [Mongrel] Mongrel has crashed
In-Reply-To: <f4cd26df0803120933w663787ddyd1228dace2191122@mail.gmail.com>
References: <47D7953B.4020600@saepia.net>
	<f4cd26df0803120933w663787ddyd1228dace2191122@mail.gmail.com>
Message-ID: <8be813400803120952w7f96d6c4u951c732d173970d4@mail.gmail.com>

On Wed, Mar 12, 2008 at 11:33 AM, Kirk Haines <wyhaines at gmail.com> wrote:
> On Wed, Mar 12, 2008 at 2:32 AM, Marcin Lewandowski <www at saepia.net> wrote:
>
>  > /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/core_ext/module/inclusion.rb:4:
>  > [BUG] gc_sweep(): unknown data type 0x0(0xa8b2241c)
>  > ruby 1.8.6 (2008-03-03) [i686-linux]
>  >
>  >
>  > Rails 1.2.6
>  >
>  > What's wrong?

My off-the-cuff guesses, in order of where I'd look

* A funny gem or plugin is in use with your Rails app, and that's
causing problems

* Bad hardware

* A bad build of ruby

What third-party code (other than Rails) are you using?

Cheers,
-Nate

From www at saepia.net  Wed Mar 12 15:15:51 2008
From: www at saepia.net (Marcin Lewandowski)
Date: Wed, 12 Mar 2008 20:15:51 +0100
Subject: [Mongrel] Mongrel has crashed
In-Reply-To: <8be813400803120952w7f96d6c4u951c732d173970d4@mail.gmail.com>
References: <47D7953B.4020600@saepia.net>	<f4cd26df0803120933w663787ddyd1228dace2191122@mail.gmail.com>
	<8be813400803120952w7f96d6c4u951c732d173970d4@mail.gmail.com>
Message-ID: <47D82BE7.8050803@saepia.net>

Nate Vack pisze:
> On Wed, Mar 12, 2008 at 11:33 AM, Kirk Haines <wyhaines at gmail.com> wrote:
>> On Wed, Mar 12, 2008 at 2:32 AM, Marcin Lewandowski <www at saepia.net> wrote:
>>
>>  > /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/core_ext/module/inclusion.rb:4:
>>  > [BUG] gc_sweep(): unknown data type 0x0(0xa8b2241c)
>>  > ruby 1.8.6 (2008-03-03) [i686-linux]
>>  >
>>  >
>>  > Rails 1.2.6
>>  >
>>  > What's wrong?
> 
> My off-the-cuff guesses, in order of where I'd look
> 
> * A funny gem or plugin is in use with your Rails app, and that's
> causing problems

I realized that there's a new version, so I'll try to upgrade to 1.1.4. 
Maybe also there's new ruby.

It happened from time to time, e.g. once for 3-4 weeks with my previous 
mongrel version (1.0.x). So I've made an upgrade to 1.1.3, but it worked 
only for 2 weeks.

I don't use any plugins in my rails app.

I'll come back if it remained with 1.1.4

Thanks,

-- 
m.

From wyhaines at gmail.com  Wed Mar 12 15:48:24 2008
From: wyhaines at gmail.com (Kirk Haines)
Date: Wed, 12 Mar 2008 13:48:24 -0600
Subject: [Mongrel] Mongrel has crashed
In-Reply-To: <47D82BE7.8050803@saepia.net>
References: <47D7953B.4020600@saepia.net>
	<f4cd26df0803120933w663787ddyd1228dace2191122@mail.gmail.com>
	<8be813400803120952w7f96d6c4u951c732d173970d4@mail.gmail.com>
	<47D82BE7.8050803@saepia.net>
Message-ID: <f4cd26df0803121248h30e3a30dm6a9837a6843a57b6@mail.gmail.com>

On Wed, Mar 12, 2008 at 1:15 PM, Marcin Lewandowski <www at saepia.net> wrote:

> I realized that there's a new version, so I'll try to upgrade to 1.1.4.
> Maybe also there's new ruby.

> It happened from time to time, e.g. once for 3-4 weeks with my previous
> mongrel version (1.0.x). So I've made an upgrade to 1.1.3, but it worked
> only for 2 weeks.
>
> I don't use any plugins in my rails app.
>
> I'll come back if it remained with 1.1.4

It's unlikely to be an issue with Mongrel, or we would have heard
about it before, especially since you say that you have seen the error
while running under two different versions of Mongrel, both of which
have been out for a long time, and that you have seen this error
multiple times.

/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/core_ext/module/inclusion.rb:4:
[BUG] gc_sweep(): unknown data type 0x0(0xa8b2241c)
ruby 1.8.6 (2008-03-03) [i686-linux]

If you look at the Ruby source code, that error is called during
obj_free() (defined in gc.c) when the object being freed doesn't have
a known node type.

My suspicion is that something that you are using has an extension in
it that is doing something which interacts poorly with Ruby's GC code.

Which version of Ruby 1.8.6 is it that you are running?  Make sure you
are using the latest patch level of 1.8.6.  This is very important.


Kirk Haines

From www at saepia.net  Wed Mar 12 16:03:04 2008
From: www at saepia.net (Marcin Lewandowski)
Date: Wed, 12 Mar 2008 21:03:04 +0100
Subject: [Mongrel] Mongrel has crashed
In-Reply-To: <f4cd26df0803121248h30e3a30dm6a9837a6843a57b6@mail.gmail.com>
References: <47D7953B.4020600@saepia.net>	<f4cd26df0803120933w663787ddyd1228dace2191122@mail.gmail.com>	<8be813400803120952w7f96d6c4u951c732d173970d4@mail.gmail.com>	<47D82BE7.8050803@saepia.net>
	<f4cd26df0803121248h30e3a30dm6a9837a6843a57b6@mail.gmail.com>
Message-ID: <47D836F8.6070809@saepia.net>

> It's unlikely to be an issue with Mongrel, or we would have heard
> about it before, especially since you say that you have seen the error
> while running under two different versions of Mongrel, both of which
> have been out for a long time, and that you have seen this error
> multiple times.

The error message was a bit different with previous version of mongrel 
but I assume that it was similar.

> My suspicion is that something that you are using has an extension in
> it that is doing something which interacts poorly with Ruby's GC code.
> 
> Which version of Ruby 1.8.6 is it that you are running?  Make sure you
> are using the latest patch level of 1.8.6.  This is very important.

I use latest available in gentoo's portage: patchlevel 1.8.6 p114 and 
AFAIK it's latest stable version.

My gems:

*** LOCAL GEMS ***

actionmailer (1.3.6)
     Service layer for easy email delivery and testing.

actionpack (1.13.6)
     Web-flow and rendering framework putting the VC in MVC.

actionwebservice (1.2.6)
     Web service support for Action Pack.

activerecord (1.15.6)
     Implements the ActiveRecord pattern for ORM.

activesupport (1.4.4)
     Support and utility classes used by the Rails framework.

cgi_multipart_eof_fix (2.5.0)
     Fix an exploitable bug in CGI multipart parsing.

daemons (1.0.5)
     A toolkit to create and control daemons in different ways

fastthread (1.0.1)
     Optimized replacement for thread.rb primitives

gem_plugin (0.2.3)
     A plugin system based on rubygems that uses dependencies only

gettext (1.9.0)
     Ruby-GetText-Package is a libary and tools to localize messages.

mongrel (1.1.3)
     A small fast HTTP library and server that runs Rails, Camping, Nitro
     and Iowa apps.

mongrel_upload_progress (0.2.2)
     The mongrel_upload_progress gemplugin

rails (1.2.6)
     Web-application framework with template engine, control-flow layer,
     and ORM.

rake (0.7.3)
     Ruby based make-like utility.

sources (0.0.1)
     This package provides download sources for remote gem installation


I'll try to upgrade them later.

Thanks!

m.

From mohammed.a at aol.in  Thu Mar 13 16:22:47 2008
From: mohammed.a at aol.in (mohammed.a at aol.in)
Date: Thu, 13 Mar 2008 16:22:47 -0400
Subject: [Mongrel] mongrel throwing error 500
Message-ID: <8CA535F22EFB860-A00-542@web-cen-v10.sim.aol.com>

Dear Users,

Often at times when the code encounters an exception, mongrel starts throwing error 500 (after which most other cluster instances are affected).

My queries are

- why does an exception in one thread have to affect others?
- how can I stop mongrel throwing 500 and start showing me the actual error on the browser (this will make things so much more easier)
- Can anyone direct me to some detailed documents on mongrel configuration?

regards

Mohammed. A

________________________________________________________________________
You are invited to Get a Free AOL Email ID. - http://webmail.aol.in
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080313/b620498a/attachment.html 

From lists at ruby-forum.com  Fri Mar 14 01:16:39 2008
From: lists at ruby-forum.com (Dan Lamet)
Date: Fri, 14 Mar 2008 06:16:39 +0100
Subject: [Mongrel] SSL doesn't activate in Mongrel
Message-ID: <456271b6c29699fac405e13c930d7e55@ruby-forum.com>

I have an app I've been working on for a while.  I just tried to
activate SSL for it.  I followed the instructions found at
<http://wiki.rubyonrails.com/rails/pages/HowToEnableSSL>.  Everything
seemed to install/configure OK, no errors.  But I now find that nothing
is listening on port 443.  "Connection refused"

So what might be the problem?
-- 
Posted via http://www.ruby-forum.com/.

From nathen at visualcv.com  Fri Mar 14 06:03:32 2008
From: nathen at visualcv.com (Nathen Harvey)
Date: Fri, 14 Mar 2008 06:03:32 -0400
Subject: [Mongrel] SSL doesn't activate in Mongrel
Message-ID: <47DA4D74.3080401@visualcv.com>

Have you set the X-Forwarded-Proto request header?  Here's a snip from 
the apache config:

    # Set header to indentify https requests for Mongrel
    RequestHeader set X-Forwarded-Proto "https"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080314/d622b01c/attachment.html 

From lists at ruby-forum.com  Fri Mar 14 13:12:23 2008
From: lists at ruby-forum.com (Dan Lamet)
Date: Fri, 14 Mar 2008 18:12:23 +0100
Subject: [Mongrel] SSL doesn't activate in Mongrel
In-Reply-To: <47DA4D74.3080401@visualcv.com>
References: <47DA4D74.3080401@visualcv.com>
Message-ID: <78a0e730cd98432bbddc6c0babeac4ef@ruby-forum.com>

I haven't actually set up Apache.  Is it possible to enable SSL with 
Mongrel by itself?
-- 
Posted via http://www.ruby-forum.com/.

From technoweenie at gmail.com  Fri Mar 14 13:23:38 2008
From: technoweenie at gmail.com (Rick Olson)
Date: Fri, 14 Mar 2008 10:23:38 -0700
Subject: [Mongrel] SSL doesn't activate in Mongrel
In-Reply-To: <78a0e730cd98432bbddc6c0babeac4ef@ruby-forum.com>
References: <47DA4D74.3080401@visualcv.com>
	<78a0e730cd98432bbddc6c0babeac4ef@ruby-forum.com>
Message-ID: <48fe25b0803141023t2c5cb64ctff2999535aad908d@mail.gmail.com>

On Fri, Mar 14, 2008 at 10:12 AM, Dan Lamet <lists at ruby-forum.com> wrote:
> I haven't actually set up Apache.  Is it possible to enable SSL with
>  Mongrel by itself?

Nope.

http://blog.innerewut.de/2006/06/21/mongrel-and-rails-behind-apache-2-2-and-ssl

-- 
Rick Olson
http://lighthouseapp.com
http://weblog.techno-weenie.net
http://mephistoblog.com

From lists at ruby-forum.com  Tue Mar 18 07:47:45 2008
From: lists at ruby-forum.com (James George)
Date: Tue, 18 Mar 2008 12:47:45 +0100
Subject: [Mongrel] Mongrel Crashes in Production
Message-ID: <8b1b96220823aa131e1d804604795907@ruby-forum.com>

I have been getting this error on the production server after rails was
updated to 2.0.2 and moreover this worked perfectly in the development
mode. This crash occurs when no one is using the app for an hour or so.
This is the error that I get in the logs. (nohup.out file). The
production log doesnt show anything unusual. Please help me out guys.
 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/rails.rb:98:in
`reload!': undefined method `reset_application!' for
ActionController::Dispatcher:Class (NoMethodError)
       from
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/rails.rb:95:in
`synchronize'
       from
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/rails.rb:95:in
`reload!'
       from
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/rails.rb:165:in
`reload!'
       from
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/rails.rb:178:in
`setup_rails_signals'
       from
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/configurator.rb:303:in
`call'
       from
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/configurator.rb:303:in
`join'
       from
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel


Thanks in advance.
-- 
Posted via http://www.ruby-forum.com/.

From luislavena at gmail.com  Tue Mar 18 10:45:25 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 18 Mar 2008 11:45:25 -0300
Subject: [Mongrel] Mongrel Crashes in Production
In-Reply-To: <8b1b96220823aa131e1d804604795907@ruby-forum.com>
References: <8b1b96220823aa131e1d804604795907@ruby-forum.com>
Message-ID: <71166b3b0803180745r2a10fe0ax1c00904c772327de@mail.gmail.com>

On Tue, Mar 18, 2008 at 8:47 AM, James George <lists at ruby-forum.com> wrote:
> I have been getting this error on the production server after rails was
>  updated to 2.0.2 and moreover this worked perfectly in the development
>  mode. This crash occurs when no one is using the app for an hour or so.
>  This is the error that I get in the logs. (nohup.out file). The
>  production log doesnt show anything unusual. Please help me out guys.
>   /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/rails.rb:98:in
>  `reload!': undefined method `reset_application!' for
>  ActionController::Dispatcher:Class (NoMethodError)
>        from

It seems you're getting a restart/reload signal to the mongrel
process, and it is trying to reload the Rails environment calling the
reset_application! method of ActionController::Dispatcher

There is no ActionController::Dispatcher, but there is a Dispatcher in
the global namespace (::Dispatcher)?

I cannot test it since Windows don't generate the HUP signal required
for this, but I think I'm in the good path.

HTH,
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From yves.dastous at intertrade.com  Tue Mar 18 17:10:02 2008
From: yves.dastous at intertrade.com (Yves D'Astous)
Date: Tue, 18 Mar 2008 17:10:02 -0400
Subject: [Mongrel] Running multiple mongrel to "serve" the same rail
 application with active scaffold
Message-ID: <47E02FAA.30304@intertrade.com>

Hi,

I want to run more then one mongrel for the same rail application on the
same machine, using the same rails files.
This application use "active scaffold"  when I start one mongrel some
files are writes in the  public/plugin_assets/  folder.

If I start more then one mongrel it is possible these files become
scrambles ?, there is also some files in tmp/{cache,pids,sessions
,sockets, webfile}
who can i make sure the 2 mongrels will not interfere each other ?, Do i
really need to use a separated copy of the same rail application for
each mongrel ?

Yves




From david at vrensk.com  Wed Mar 19 19:25:52 2008
From: david at vrensk.com (David Vrensk)
Date: Thu, 20 Mar 2008 00:25:52 +0100
Subject: [Mongrel] mongrel throwing error 500
In-Reply-To: <8CA535F22EFB860-A00-542@web-cen-v10.sim.aol.com>
References: <8CA535F22EFB860-A00-542@web-cen-v10.sim.aol.com>
Message-ID: <81b453920803191625q2995701k9785863693fadbbc@mail.gmail.com>

On 3/13/08, mohammed.a at aol.in <mohammed.a at aol.in> wrote:
>
> Dear Users,
>
> Often at times when the code encounters an exception, mongrel starts
> throwing error 500 (after which most other cluster instances are affected).
>
> My queries are
>
> - why does an exception in one thread have to affect others?


I think you need to give us a bit more detail.  Like, are you talking about
actual threads within one process, or different processes, which the word
"cluster" above hints?  And are you using a framework like Rails or Merb, or
are you building your own registered handlers in Mongrel?

Best regards,

/David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080320/a4391a00/attachment.html 

From matte at ruckuswireless.com  Wed Mar 19 19:22:33 2008
From: matte at ruckuswireless.com (Matte Edens)
Date: Wed, 19 Mar 2008 16:22:33 -0700
Subject: [Mongrel] Process environment requires procfs(5)
Message-ID: <47E1A039.2010306@ruckuswireless.com>

I know this has been brought up before but I'm receiving the error ...

Process environment requires procfs(5)

... when trying to restart my cluster.  I've narrowed it down to 
'find_pid' method in init.rb.  I'm running a FreeBSD 6.2 server and 
mongrel_cluster version 1.0.5.  The command that gives me the error is ...

ps -ewwo pid,command

... but I've been able to narrow it even further to just the "e" flag.  
When I run a `ps e` I get the error as well.  Now, this is possibly a 
server setup issue.  I believe it's related to the fact that my ps 
output for each mongrel instance only says "[ruby18]" and not the much 
longer but expected output of ...

/usr/local/bin/ruby18 /usr/local/bin/mongrel_rails start -d -e 
production ...

I'm fully ready to call my hosting provider to find out if they can help 
but I'm wondering if anyone on the list has thoughts about this.  My 
restarts won't run successfully because the pidfile isn't being found 
due to the fact that the process isn't being fully listed.  Just the 
"[ruby18]" is showing up for my mongrel processes and cluster can't 
parse that for the pid filename

matte

From rgkaufman at gmail.com  Thu Mar 20 22:09:35 2008
From: rgkaufman at gmail.com (Rob Kaufman)
Date: Thu, 20 Mar 2008 19:09:35 -0700
Subject: [Mongrel] Running multiple mongrel to "serve" the same rail
	application with active scaffold
In-Reply-To: <47E02FAA.30304@intertrade.com>
References: <47E02FAA.30304@intertrade.com>
Message-ID: <17112e2f0803201909r677c2be3wcfe394edf2903889@mail.gmail.com>

Hi Yves,
  Those assets should only be writen the very first time your app loads, and
not on each load.  No matter what the various mongrels will not interfere
with each other if run from the same rails directory unless active scaffold
is doing something truly horrible with they're file writing.  This seems
pretty unlikely.

Rob

On Tue, Mar 18, 2008 at 2:10 PM, Yves D'Astous <yves.dastous at intertrade.com>
wrote:

> Hi,
>
> I want to run more then one mongrel for the same rail application on the
> same machine, using the same rails files.
> This application use "active scaffold"  when I start one mongrel some
> files are writes in the  public/plugin_assets/  folder.
>
> If I start more then one mongrel it is possible these files become
> scrambles ?, there is also some files in tmp/{cache,pids,sessions
> ,sockets, webfile}
> who can i make sure the 2 mongrels will not interfere each other ?, Do i
> really need to use a separated copy of the same rail application for
> each mongrel ?
>
> Yves
>
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080320/2b642b0c/attachment.html 

From www at saepia.net  Fri Mar 21 06:52:44 2008
From: www at saepia.net (Marcin Lewandowski)
Date: Fri, 21 Mar 2008 11:52:44 +0100
Subject: [Mongrel] Mongrel has crashed
In-Reply-To: <47D836F8.6070809@saepia.net>
References: <47D7953B.4020600@saepia.net>	<f4cd26df0803120933w663787ddyd1228dace2191122@mail.gmail.com>	<8be813400803120952w7f96d6c4u951c732d173970d4@mail.gmail.com>	<47D82BE7.8050803@saepia.net>	<f4cd26df0803121248h30e3a30dm6a9837a6843a57b6@mail.gmail.com>
	<47D836F8.6070809@saepia.net>
Message-ID: <47E3937C.7050902@saepia.net>

It still crashes... :(

/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/core_ext/module/inclusion.rb:4: 
[BUG] gc_sweep(): unknown data type 0x0(0xac53841c)
ruby 1.8.6 (2008-03-03) [i686-linux]


Once, there was a crash message related to gettext, but I've made an 
upgrade and it crashes like that.

How to trace or debug that?

m.

From wyhaines at gmail.com  Fri Mar 21 10:34:49 2008
From: wyhaines at gmail.com (Kirk Haines)
Date: Fri, 21 Mar 2008 08:34:49 -0600
Subject: [Mongrel] Mongrel has crashed
In-Reply-To: <47E3937C.7050902@saepia.net>
References: <47D7953B.4020600@saepia.net>
	<f4cd26df0803120933w663787ddyd1228dace2191122@mail.gmail.com>
	<8be813400803120952w7f96d6c4u951c732d173970d4@mail.gmail.com>
	<47D82BE7.8050803@saepia.net>
	<f4cd26df0803121248h30e3a30dm6a9837a6843a57b6@mail.gmail.com>
	<47D836F8.6070809@saepia.net> <47E3937C.7050902@saepia.net>
Message-ID: <f4cd26df0803210734m5c137b8p7ac8c8cf51794372@mail.gmail.com>

On Fri, Mar 21, 2008 at 4:52 AM, Marcin Lewandowski <www at saepia.net> wrote:
> It still crashes... :(
>
> /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/core_ext/module/inclusion.rb:4:
> [BUG] gc_sweep(): unknown data type 0x0(0xac53841c)
> ruby 1.8.6 (2008-03-03) [i686-linux]
>
>
> Once, there was a crash message related to gettext, but I've made an
> upgrade and it crashes like that.
>
> How to trace or debug that?

Look at the exception.  Since you've gotten the same identical
exception twice, start there.  It's in ActiveSupport, not Mongrel,
BTW.

Here's the line in question:

ObjectSpace.each_object(Class) { |k| classes << k if
k.included_modules.include?(self) }

This is an interesting place for that error to occur.  I don't have an
immediate hypothesis, but somehow something is getting into the Ruby
heap that isn't a recognized node type.


Kirk Haines

From evan at cloudbur.st  Fri Mar 21 12:50:18 2008
From: evan at cloudbur.st (Evan Weaver)
Date: Fri, 21 Mar 2008 12:50:18 -0400
Subject: [Mongrel] Mongrel has crashed
In-Reply-To: <f4cd26df0803210734m5c137b8p7ac8c8cf51794372@mail.gmail.com>
References: <47D7953B.4020600@saepia.net>
	<f4cd26df0803120933w663787ddyd1228dace2191122@mail.gmail.com>
	<8be813400803120952w7f96d6c4u951c732d173970d4@mail.gmail.