Mongrel users - May 2006 - mongrel_rails cluster::start problem with multiple runs?

mongrel_rails cluster::start doesn''t seem to pay attention to whether
or not
the processes exist or not.  If you run it twice, the first set of processes
are created, then then second run will overwrite the log/{pidfiles} files
with the new process numbers.  Problem is that the second group of processes
are gone, since the first ones had the port open.

I''d think that the right thing to do would be for cluster::start to see
if
the process identified in the pidfile still exists, and to fail if it''s
still there. 

 - James Moore

James Moore wrote:
> mongrel_rails cluster::start doesn''t seem to pay attention to
whether or not
> the processes exist or not.  If you run it twice, the first set of
processes
> are created, then then second run will overwrite the log/{pidfiles} files
> with the new process numbers.  Problem is that the second group of
processes
> are gone, since the first ones had the port open.
> 
> I''d think that the right thing to do would be for cluster::start
to see if
> the process identified in the pidfile still exists, and to fail if
it''s
> still there. 
The latest prerelease of mongrel fixes the pid stomping bug (4414).  I
haven''t tried this in combination with the latest mongrel_cluster
pre-release but its on my TODO list for the weekend.

Check Zed''s pre-release announcement:
http://rubyforge.org/pipermail/mongrel-users/2006-May/000263.html

Austin

On Fri, 2006-05-26 at 10:16 -0700, James Moore wrote:
> mongrel_rails cluster::start doesn''t seem to pay attention to
whether or not
> the processes exist or not.  If you run it twice, the first set of
processes
> are created, then then second run will overwrite the log/{pidfiles} files
> with the new process numbers.  Problem is that the second group of
processes
> are gone, since the first ones had the port open.
> 
> I''d think that the right thing to do would be for cluster::start
to see if
> the process identified in the pidfile still exists, and to fail if
it''s
> still there. 
Hey James, can you say which version of Mongrel and which version of
mongrel_cluster you''re using?  The latest pre-release of both fixes a
lot of this.


-- 
Zed A. Shaw
http://www.zedshaw.com/
http://mongrel.rubyforge.org/

> Hey James, can you say which version of Mongrel and which version of
> mongrel_cluster you''re using?  The latest pre-release of both
fixes a
> lot of this.
Just installed 0.3.13 on FC4.  The behaviour of start doesn''t match
what I''d
expect; it doesn''t complain about starting twice:

[james at server1 rv]$ /usr/local/bin/ruby /usr/local/bin/mongrel_rails start
-d -e production -p 3000 -a 127.0.0.1 -P log/mongrel.3000.pid
** Starting Mongrel in production mode at 127.0.0.1:3000
** Daemonizing, any open files are closed.  Look at log/mongrel.3000.pid and
log/mongrel.log for info.
[james at server1 rv]$ /usr/local/bin/ruby /usr/local/bin/mongrel_rails start
-d -e production -p 3000 -a 127.0.0.1 -P log/mongrel.3000.pid
** Starting Mongrel in production mode at 127.0.0.1:3000
** Daemonizing, any open files are closed.  Look at log/mongrel.3000.pid and
log/mongrel.log for info.
[james at server1 rv]$

My expectation would be behavior something like apachectl, where you get:

[root at server1 httpd-2.2.2]# /usr/local/apache2/bin/apachectl start
httpd (pid 16490) already running

It may be that I need to adjust my expectations and this isn''t a bug,
though.

My preference would be to have start fail if the pid file exists, and tell
you the process exists.  Restart would warn about a pidfile that exists but
no matching process, but would continue on to start a server.  Basically,
match apachectl.

(I was going to say that ''start'' would fail if the pidfile was
there but the
process was gone, just like apachectl. I checked that behavior before
mailing, and that''s not what happens.  apachectl will happily stomp on
a
pidfile with a bogus pid in it, which isn''t how I thought it worked.)

A ''cluster::status'' command (outputing maybe something easy to
parse, like
YAML?) of some sort would be great, too.

- James