On Wed, Mar 5, 2008 at 2:16 PM, Simon S. [email protected]
wrote:
there is a patch here:
textsnippets.com
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 B.
http://blog.johnjosephbachir.org
http://lyceum.ibiblio.org
http://jjb.cc
On Thu, Mar 6, 2008 at 6:39 PM, Jos B. [email protected] 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 V.
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]
On Thu, Mar 06, 2008 at 11:51:35AM -0800, Jeremy K. 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).
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 B. wrote:
I think it would be right for mongrel to clean up it’s stale pid files. Every
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 R.
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
On Thu, Mar 06, 2008 at 11:42:04PM -0700, Alexey V. wrote:
On Thu, Mar 6, 2008 at 6:39 PM, Jos B. [email protected] 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.
On Fri, Mar 7, 2008 at 11:51 AM, Jos B. [email protected] 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