From pergesu at gmail.com  Fri May  4 05:22:23 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Fri, 4 May 2007 03:22:23 -0600
Subject: [Mongrel] Problems with mongrel_cluster 1.0.1.1 on FreeBSD
Message-ID: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>

I'm running FreeBSD 6.1 and installed the 1.0.1.1 mongrel_cluster
prerelease.  I had a problem with the mongrels not stopping, and it
turns out it's because ps is reporting my processes as just
[ruby18]

instead of someting more like "mongrel_rails start -d ......."

Not sure why it's doing that, but it is.  Any ideas?

For the time being I just changed line 165 of init.rb to read
pid = ps_output =~ /mongrel_rails|ruby18/ ? pid : nil

and that's working fine.

Pat

From pergesu at gmail.com  Fri May  4 05:38:28 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Fri, 4 May 2007 03:38:28 -0600
Subject: [Mongrel] Problems with mongrel_cluster 1.0.1.1 on FreeBSD
In-Reply-To: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>
References: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>
Message-ID: <810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>

On 5/4/07, Pat Maddox <pergesu at gmail.com> wrote:
> I'm running FreeBSD 6.1 and installed the 1.0.1.1 mongrel_cluster
> prerelease.  I had a problem with the mongrels not stopping, and it
> turns out it's because ps is reporting my processes as just
> [ruby18]
>
> instead of someting more like "mongrel_rails start -d ......."
>
> Not sure why it's doing that, but it is.  Any ideas?
>
> For the time being I just changed line 165 of init.rb to read
> pid = ps_output =~ /mongrel_rails|ruby18/ ? pid : nil
>
> and that's working fine.
>
> Pat
>

I've got two sets of mongrels running now, one running a staging
environment and the other production.

[twist at jack ~/twist/shared/log]$ ps ax | grep ruby
88908  ??  S      0:01.96 [ruby18]
88911  ??  S      0:02.15 [ruby18]
88914  ??  S      0:02.14 [ruby18]
89021  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
start -d -e production -c
89026  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
start -d -e production -c
89029  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
start -d -e production -c

The [ruby18] processes are all staging mongrels.  Any clue as to why
they wouldn't show the full command?

Pat

From miles at pixar.com  Fri May  4 11:05:04 2007
From: miles at pixar.com (Miles Egan)
Date: Fri, 4 May 2007 08:05:04 -0700
Subject: [Mongrel] possible fix for mongrel hangs
Message-ID: <30B09B51-382E-465A-A1A3-AA5380ADE416@pixar.com>

We've been experiencing the same kinds of hangs other people have  
described here lately.  For no obvious reason our mongrel processes  
just freeze up and nothing short of a kill -9 can retrieve them.   
This is in a standard linux apache 2.2/balancer setup.

Anyway, following some threads online I tried adding these directives:

     SetEnv force-proxy-request-1.0 1
     SetEnv proxy-nokeepalive 1

To the apache config and I haven't seen a hang all week.  Sorry I  
don't have a more scientific explanation for this or ideas for a  
deeper fix but these might be worth a try if you're stuck.

--
miles



From paul.mylchreest at mac.com  Fri May  4 12:01:23 2007
From: paul.mylchreest at mac.com (Paul Mylchreest)
Date: Fri, 04 May 2007 12:01:23 -0400
Subject: [Mongrel] possible fix for mongrel hangs
In-Reply-To: <30B09B51-382E-465A-A1A3-AA5380ADE416@pixar.com>
References: <30B09B51-382E-465A-A1A3-AA5380ADE416@pixar.com>
Message-ID: <6105A2D2-2532-4E3A-9AFE-DDB752C8AB1D@mac.com>

If you see this in the apache error log:

proxy: error reading status line from remote server ...

its probably Apache bug 39499.

I found the solution sometime ago here:

<http://blog.pomozov.info/posts/apache-mongrel-and-proxy-error.html>

   #Fix for Apache bug 39499
   SetEnv force-proxy-request-1.0 1
   SetEnv proxy-nokeepalive 1

On 4-May-07, at 11:05 , Miles Egan wrote:

> We've been experiencing the same kinds of hangs other people have
> described here lately.  For no obvious reason our mongrel processes
> just freeze up and nothing short of a kill -9 can retrieve them.
> This is in a standard linux apache 2.2/balancer setup.
>
> Anyway, following some threads online I tried adding these directives:
>
>      SetEnv force-proxy-request-1.0 1
>      SetEnv proxy-nokeepalive 1
>
> To the apache config and I haven't seen a hang all week.  Sorry I
> don't have a more scientific explanation for this or ideas for a
> deeper fix but these might be worth a try if you're stuck.
>
> --
> miles
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From miles at pixar.com  Fri May  4 12:13:47 2007
From: miles at pixar.com (Miles Egan)
Date: Fri, 4 May 2007 09:13:47 -0700
Subject: [Mongrel] possible fix for mongrel hangs
In-Reply-To: <6105A2D2-2532-4E3A-9AFE-DDB752C8AB1D@mac.com>
References: <30B09B51-382E-465A-A1A3-AA5380ADE416@pixar.com>
	<6105A2D2-2532-4E3A-9AFE-DDB752C8AB1D@mac.com>
Message-ID: <0CB9E9FC-4AAE-4DE1-A3D1-DEBB0BC14730@pixar.com>

On May 4, 2007, at 9:01 AM, Paul Mylchreest wrote:
> If you see this in the apache error log:
>
> proxy: error reading status line from remote server ...
>
> its probably Apache bug 39499.
>
> I found the solution sometime ago here:
>
> <http://blog.pomozov.info/posts/apache-mongrel-and-proxy-error.html>
>

I think that's where I found the solution too, actually.

--
miles

"If money played an instrument it would be the saxophone." - Achewood

From matte at ruckuswireless.com  Fri May  4 14:26:13 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Fri, 04 May 2007 11:26:13 -0700
Subject: [Mongrel] Problems with mongrel_cluster 1.0.1.1 on FreeBSD
In-Reply-To: <810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>
References: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>
	<810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>
Message-ID: <463B7AC5.5090000@ruckuswireless.com>

I too am running mongrel on 6.1 but I have a few on 4.x as well.  I 
experienced problems with stopping mongrels UNTIL I switched the pidfile 
location in the config file to point to

/var/tmp/[site].pid

If you are using a relative path to your pid files in the config file, 
as I was when I was having problems, it wouldn't properly stop.  I'm not 
sure of your exact circumstances but you might try switching the pidfile 
location.  This made ALL the difference.  I have NO problems with 
processes that won't stop.

Using the /var/tmp directory is regarded as "best practice".  This is, I 
believe, mentioned in the release announcement for the 1.0.1.1 
pre-release.  Search the archives and you should find it.

matte

Pat Maddox wrote:
> On 5/4/07, Pat Maddox <pergesu at gmail.com> wrote:
>   
>> I'm running FreeBSD 6.1 and installed the 1.0.1.1 mongrel_cluster
>> prerelease.  I had a problem with the mongrels not stopping, and it
>> turns out it's because ps is reporting my processes as just
>> [ruby18]
>>
>> instead of someting more like "mongrel_rails start -d ......."
>>
>> Not sure why it's doing that, but it is.  Any ideas?
>>
>> For the time being I just changed line 165 of init.rb to read
>> pid = ps_output =~ /mongrel_rails|ruby18/ ? pid : nil
>>
>> and that's working fine.
>>
>> Pat
>>
>>     
>
> I've got two sets of mongrels running now, one running a staging
> environment and the other production.
>
> [twist at jack ~/twist/shared/log]$ ps ax | grep ruby
> 88908  ??  S      0:01.96 [ruby18]
> 88911  ??  S      0:02.15 [ruby18]
> 88914  ??  S      0:02.14 [ruby18]
> 89021  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
> start -d -e production -c
> 89026  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
> start -d -e production -c
> 89029  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
> start -d -e production -c
>
> The [ruby18] processes are all staging mongrels.  Any clue as to why
> they wouldn't show the full command?
>
> Pat
> _______________________________________________
> 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/20070504/9753ccbc/attachment.html 

From carl.lerche at gmail.com  Fri May  4 22:59:27 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Fri, 4 May 2007 19:59:27 -0700
Subject: [Mongrel] Tell me why my Shoutcase handler sucks!
Message-ID: <ab90312e0705041959j40e2f8aeo4a1854e4bb109cc7@mail.gmail.com>

So, I want to build the greatest online radio ever! (for my, currently
crappy, faderwave.net radio station. Right now, I'm running Icecast
straight up. The only problem is that managing different DJs and
keeping them off the air when they aren't supposed to be there is a
pain. There also is not one single management package that does
everything. My current system is a hacked together mess.

So, I want to build a unified ruby based solution. No, I'm not going
to try to replace Icecast with a hacked pure ruby version, but I am
going to try to setup a proxy for DJs to connect to where I can manage
every small bit.

To do all that, I really have to understand how Icecast works. So, I
hacked together a mongrel handler that can accept broadcasting clients
and send the stream to listeners... except I don't really know what
I'm doing. So, I would appreciate it if you could look over the code
and tell me why it sucks and how to improve it. It's really short,
under 100 lines with comments.

Of course, this is just a really rough solution that I hacked together
to experiment with interfacing with broadcasting clients and audio
players. Anyway, here it is:

http://pastie.caboo.se/59073

Thanks,
-carl
-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From carl.lerche at gmail.com  Fri May  4 23:01:47 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Fri, 4 May 2007 20:01:47 -0700
Subject: [Mongrel] Tell me why my Shoutcase handler sucks!
In-Reply-To: <ab90312e0705041959j40e2f8aeo4a1854e4bb109cc7@mail.gmail.com>
References: <ab90312e0705041959j40e2f8aeo4a1854e4bb109cc7@mail.gmail.com>
Message-ID: <ab90312e0705042001ib61bfd3h5c35e11734ea88cb@mail.gmail.com>

woops, the subject is supposed to be Shoutcast!!!

On 5/4/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> So, I want to build the greatest online radio ever! (for my, currently
> crappy, faderwave.net radio station. Right now, I'm running Icecast
> straight up. The only problem is that managing different DJs and
> keeping them off the air when they aren't supposed to be there is a
> pain. There also is not one single management package that does
> everything. My current system is a hacked together mess.
>
> So, I want to build a unified ruby based solution. No, I'm not going
> to try to replace Icecast with a hacked pure ruby version, but I am
> going to try to setup a proxy for DJs to connect to where I can manage
> every small bit.
>
> To do all that, I really have to understand how Icecast works. So, I
> hacked together a mongrel handler that can accept broadcasting clients
> and send the stream to listeners... except I don't really know what
> I'm doing. So, I would appreciate it if you could look over the code
> and tell me why it sucks and how to improve it. It's really short,
> under 100 lines with comments.
>
> Of course, this is just a really rough solution that I hacked together
> to experiment with interfacing with broadcasting clients and audio
> players. Anyway, here it is:
>
> http://pastie.caboo.se/59073
>
> Thanks,
> -carl
> --
> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From tom at hur.st  Sat May  5 15:15:11 2007
From: tom at hur.st (Thomas Hurst)
Date: Sat, 5 May 2007 20:15:11 +0100
Subject: [Mongrel] Problems with mongrel_cluster 1.0.1.1 on FreeBSD
In-Reply-To: <810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>
References: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>
	<810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>
Message-ID: <20070505191511.GA90903@voi.aagh.net>

* Pat Maddox (pergesu at gmail.com) wrote:

> [twist at jack ~/twist/shared/log]$ ps ax | grep ruby
> 88908  ??  S      0:01.96 [ruby18]
..
> 89029  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
> start -d -e production -c
> 
> The [ruby18] processes are all staging mongrels.  Any clue as to why
> they wouldn't show the full command?

They've probably been swapped out; -f can bring the full command name
back if you're root.

-- 
Thomas 'Freaky' Hurst
    http://hur.st/

From pergesu at gmail.com  Sat May  5 18:27:56 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Sat, 5 May 2007 16:27:56 -0600
Subject: [Mongrel] Problems with mongrel_cluster 1.0.1.1 on FreeBSD
In-Reply-To: <20070505191511.GA90903@voi.aagh.net>
References: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>
	<810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>
	<20070505191511.GA90903@voi.aagh.net>
Message-ID: <810a540e0705051527p2ca9b266m47d2aca4a2fe0326@mail.gmail.com>

On 5/5/07, Thomas Hurst <tom at hur.st> wrote:
> * Pat Maddox (pergesu at gmail.com) wrote:
>
> > [twist at jack ~/twist/shared/log]$ ps ax | grep ruby
> > 88908  ??  S      0:01.96 [ruby18]
> ..
> > 89029  ??  S      0:01.95 /usr/local/bin/ruby18 /bin/mongrel_rails
> > start -d -e production -c
> >
> > The [ruby18] processes are all staging mongrels.  Any clue as to why
> > they wouldn't show the full command?
>
> They've probably been swapped out; -f can bring the full command name
> back if you're root.

What do you mean swapped out?

Pat

From msoulier at digitaltorque.ca  Sat May  5 21:04:11 2007
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Sat, 5 May 2007 21:04:11 -0400
Subject: [Mongrel] mongrel becoming unresponsive
Message-ID: <20070506010410.GS4346@tigger.digitaltorque.ca>

Hello,

I'm running mongrel behind apache via proxypass. Every now and then, a spammer
tries to proxy traffic through apache, and for some reason, apache forwards
the request to mongrel, even though it's not a site being hosted by me. 

At times this seems to cause mongrel to become unresponsive, and all requests
to the site then fail with a proxy error until mongrel is restarted. 

I'm not sure of how to troubleshoot this issue. Help appreciated. 

Mike
-- 
Michael P. Soulier <msoulier at digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." --Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070505/b7a71f69/attachment.bin 

From pete at nextengine.com  Sat May  5 21:33:53 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Sat, 5 May 2007 18:33:53 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <20070506010410.GS4346@tigger.digitaltorque.ca>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
Message-ID: <01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>

Hi Mike,

My mongrels are dying too, but running behind Lighttpd.  Are you  
seeing anything in the logs?  I see absolutely nothing.  Just the  
last request that went through... but it's pretty old.

At first, I thought it might be my version of Ruby or Rails.  But now  
I've tried all sort of combinations, and rebuilt all the gems each  
time (based on advice on this forum).

My solution for now is to run a few mongrels, and have Monit restart  
them when they become unresponsive.  I have a few die each day.

Zed, is there anything we can do to debug this further?  Is there a  
good place we can put some logs in the Mongrel code?  Or something we  
can try the next time they go down?

Thanks,
Pete

On May 5, 2007, at 6:04 PM, Michael P. Soulier wrote:

> Hello,
>
> I'm running mongrel behind apache via proxypass. Every now and  
> then, a spammer
> tries to proxy traffic through apache, and for some reason, apache  
> forwards
> the request to mongrel, even though it's not a site being hosted by  
> me.
>
> At times this seems to cause mongrel to become unresponsive, and  
> all requests
> to the site then fail with a proxy error until mongrel is restarted.
>
> I'm not sure of how to troubleshoot this issue. Help appreciated.
>
> Mike
> -- 
> Michael P. Soulier <msoulier at digitaltorque.ca>
> "Any intelligent fool can make things bigger and more complex... It
> takes a touch of genius - and a lot of courage to move in the opposite
> direction." --Albert Einstein
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From tom at hur.st  Sat May  5 21:39:02 2007
From: tom at hur.st (Thomas Hurst)
Date: Sun, 6 May 2007 02:39:02 +0100
Subject: [Mongrel] Problems with mongrel_cluster 1.0.1.1 on FreeBSD
In-Reply-To: <810a540e0705051527p2ca9b266m47d2aca4a2fe0326@mail.gmail.com>
References: <810a540e0705040222m569117eeo649ec72958a4bf50@mail.gmail.com>
	<810a540e0705040238p51e3f194jc46cbcddf9107c8b@mail.gmail.com>
	<20070505191511.GA90903@voi.aagh.net>
	<810a540e0705051527p2ca9b266m47d2aca4a2fe0326@mail.gmail.com>
Message-ID: <20070506013902.GA11635@voi.aagh.net>

* Pat Maddox (pergesu at gmail.com) wrote:

(Sorry to the moderator(s), who I keep spamming by sending from the wrong
address.  I've added a folder-hook to prevent it)

> > They've probably been swapped out; -f can bring the full command name
> > back if you're root.
> 
> What do you mean swapped out?

I mean, the pages which contain the command line are not in system
memory, so it's just showing you the command name instead of swapping
them back in, which could get quite expensive on a loaded system with
lots of inactive processes (think: 4k * 1000 processes for something the
user probably doesn't even want).

You can turn it off by rebuilding it without the -DLAZY_PS line, ala:

cd /usr/src/bin/ps && sed -i .orig -e 's/-DLAZY_PS//' Makefile && make clean all install

But obviously this isn't something mongrel should be depending on ;)

Maybe we could use a proper interface to process lists, with backends to
ps(1), procfs(5), kvm(3), Win32, etc.  I have a decent chunk of code for
FreeBSD/kvm(3) right here, though it's not yet 64bit clean.

-- 
Thomas 'Freaky' Hurst
    http://hur.st/

From tom at hur.st  Sat May  5 21:51:44 2007
From: tom at hur.st (Thomas Hurst)
Date: Sun, 6 May 2007 02:51:44 +0100
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <20070506010410.GS4346@tigger.digitaltorque.ca>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
Message-ID: <20070506015144.GB11635@voi.aagh.net>

* Michael P. Soulier (msoulier at digitaltorque.ca) wrote:

> At times this seems to cause mongrel to become unresponsive, and all
> requests to the site then fail with a proxy error until mongrel is
> restarted. 
> 
> I'm not sure of how to troubleshoot this issue. Help appreciated. 

Try using gdb to get a backtrace:

% gdb `which ruby` <pid of mongrel>

Then "bt" to get a list of the functions it's calling.  You may need to
recompile Ruby with debugging symbols if it's mostly "???".  On FreeBSD
this is as simple as "portupgrade -fm '-DWITH_DEBUG' ruby"

http://eigenclass.org/hiki/ruby+live+process+introspection may be of
use.

Other options are ktrace, strace and truss (depending on what system
you're on) to get an idea of the syscalls it's performing, but this may
not be very useful depending on how it's hung.

-- 
Thomas 'Freaky' Hurst
    http://hur.st/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070506/588fdd4b/attachment.bin 

From msoulier at digitaltorque.ca  Sat May  5 22:05:17 2007
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Sat, 5 May 2007 22:05:17 -0400
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
Message-ID: <20070506020517.GT4346@tigger.digitaltorque.ca>

On 05/05/07 Pete DeLaurentis said:

> Hi Mike,
> 
> My mongrels are dying too, but running behind Lighttpd.  Are you  
> seeing anything in the logs?  I see absolutely nothing.  Just the  
> last request that went through... but it's pretty old.

Nothing in the logs to indicate what the problem might be. Seems to happen
when it processes a 404 error sometimes. 

ActionController::RoutingError (no route found to match
"/2006/04/15/employee-of-the-century-dead-at-100/trackback/" with
{:method=>:post}):
    /usr/local/ruby/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/action_controller/routing.rb:1292:in
`recognize_path'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/action_controller/routing.rb:1282:in
`recognize'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/dispatcher.rb:40:in
`dispatch'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:78:in
`process'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:76:in
`process'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:618:in
`process_client'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in
`process_client'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:271:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:127:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in
`run'
    /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243
    /usr/local/ruby/bin/mongrel_rails:18


rescue_action_in_public executed
Rendering status404 Not
Foundfile/var/www/papproach/config/../public/404.htmllayoutfalse within
layouts//application
Rendering /var/www/papproach/config/../public/404.html (404 Not Found)

> My solution for now is to run a few mongrels, and have Monit restart  
> them when they become unresponsive.  I have a few die each day.

I have one instance supervised with runit, but supervision doesn't help since
the mongrel doesn't crash, it just hangs. I now have a 10 minute cron that
checks on it and restarts it if it's unresponsive, and it's doing so a few
times an hour now, which is disturbing. 

> Zed, is there anything we can do to debug this further?  Is there a  
> good place we can put some logs in the Mongrel code?  Or something we  
> can try the next time they go down?

It's happening a lot to me right now. No --debug option to mongrel?

Mike
-- 
Michael P. Soulier <msoulier at digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." --Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070505/453d1cdb/attachment.bin 

From pete at nextengine.com  Sat May  5 22:21:54 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Sat, 5 May 2007 19:21:54 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <20070506020517.GT4346@tigger.digitaltorque.ca>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
Message-ID: <C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>

Hi Mike,

You're definitely hitting this more often then I am (about once per  
day).

With monit, you can do an HTTP request and test the response, which  
is how I determined if it's hanged.  Sounds pretty similar to what  
you're doing with cron.

Which OS are you running + version of ruby?  I'm on OpenSUSE 10.3,  
Ruby 1.8.5, Rails 1.2, and Mongrel 1.0.1.  I also run memcached,  
lighttpd, and pound.  I'm running 6 mongrels using mongrel_cluster  
(the latest version).

Thanks,
Pete


On May 5, 2007, at 7:05 PM, Michael P. Soulier wrote:

> On 05/05/07 Pete DeLaurentis said:
>
>> Hi Mike,
>>
>> My mongrels are dying too, but running behind Lighttpd.  Are you
>> seeing anything in the logs?  I see absolutely nothing.  Just the
>> last request that went through... but it's pretty old.
>
> Nothing in the logs to indicate what the problem might be. Seems to  
> happen
> when it processes a 404 error sometimes.
>
> ActionController::RoutingError (no route found to match
> "/2006/04/15/employee-of-the-century-dead-at-100/trackback/" with
> {:method=>:post}):
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/ 
> action_controller/routing.rb:1292:in
> `recognize_path'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/ 
> action_controller/routing.rb:1282:in
> `recognize'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/ 
> dispatcher.rb:40:in
> `dispatch'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel/rails.rb:78:in
> `process'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel/rails.rb:76:in
> `process'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel.rb:618:in
> `process_client'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel.rb:617:in
> `process_client'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel.rb:736:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel.rb:736:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel.rb:720:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel/configurator.rb:271:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel/configurator.rb:270:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/ 
> mongrel_rails:127:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/ 
> mongrel/command.rb:211:in
> `run'
>     /usr/local/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/ 
> mongrel_rails:243
>     /usr/local/ruby/bin/mongrel_rails:18
>
>
> rescue_action_in_public executed
> Rendering status404 Not
> Foundfile/var/www/papproach/config/../public/404.htmllayoutfalse  
> within
> layouts//application
> Rendering /var/www/papproach/config/../public/404.html (404 Not Found)
>
>> My solution for now is to run a few mongrels, and have Monit restart
>> them when they become unresponsive.  I have a few die each day.
>
> I have one instance supervised with runit, but supervision doesn't  
> help since
> the mongrel doesn't crash, it just hangs. I now have a 10 minute  
> cron that
> checks on it and restarts it if it's unresponsive, and it's doing  
> so a few
> times an hour now, which is disturbing.
>
>> Zed, is there anything we can do to debug this further?  Is there a
>> good place we can put some logs in the Mongrel code?  Or something we
>> can try the next time they go down?
>
> It's happening a lot to me right now. No --debug option to mongrel?
>
> Mike
> -- 
> Michael P. Soulier <msoulier at digitaltorque.ca>
> "Any intelligent fool can make things bigger and more complex... It
> takes a touch of genius - and a lot of courage to move in the opposite
> direction." --Albert Einstein
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From msoulier at digitaltorque.ca  Sat May  5 22:54:06 2007
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Sat, 5 May 2007 22:54:06 -0400
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <20070506015144.GB11635@voi.aagh.net>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<20070506015144.GB11635@voi.aagh.net>
Message-ID: <20070506025406.GU4346@tigger.digitaltorque.ca>

On 06/05/07 Thomas Hurst said:

> Try using gdb to get a backtrace:
> 
> % gdb `which ruby` <pid of mongrel>

Unfortunately it's on a VPS where I don't get gdb. I don't have full control
over the box. 

> Then "bt" to get a list of the functions it's calling.  You may need to
> recompile Ruby with debugging symbols if it's mostly "???".  On FreeBSD
> this is as simple as "portupgrade -fm '-DWITH_DEBUG' ruby"
> 
> http://eigenclass.org/hiki/ruby+live+process+introspection may be of
> use.
> 
> Other options are ktrace, strace and truss (depending on what system
> you're on) to get an idea of the syscalls it's performing, but this may
> not be very useful depending on how it's hung.

Mike
-- 
Michael P. Soulier <msoulier at digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." --Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070505/6604fa81/attachment.bin 

From msoulier at digitaltorque.ca  Sat May  5 22:55:46 2007
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Sat, 5 May 2007 22:55:46 -0400
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
Message-ID: <20070506025545.GV4346@tigger.digitaltorque.ca>

On 05/05/07 Pete DeLaurentis said:

> Hi Mike,
> 
> You're definitely hitting this more often then I am (about once per  
> day).
> 
> With monit, you can do an HTTP request and test the response, which  
> is how I determined if it's hanged.  Sounds pretty similar to what  
> you're doing with cron.
> 
> Which OS are you running + version of ruby?  I'm on OpenSUSE 10.3,  
> Ruby 1.8.5, Rails 1.2, and Mongrel 1.0.1.  I also run memcached,  
> lighttpd, and pound.  I'm running 6 mongrels using mongrel_cluster  
> (the latest version).

I'm running a Linux VPS, which I think is RedHat based. ruby 1.8.4 and
mongrel 1.0.1, with Rails 1.2.2. 

Mike
-- 
Michael P. Soulier <msoulier at digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." --Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070505/09201a6f/attachment.bin 

From zach at plugthegap.co.uk  Sun May  6 20:15:51 2007
From: zach at plugthegap.co.uk (Zachary Powell)
Date: Sun, 6 May 2007 20:15:51 -0400
Subject: [Mongrel] Mongrel and EBADF error consuming resources
Message-ID: <ac243e420705061715q2b64e5e8r97d9486f94b2ad0e@mail.gmail.com>

In the last few weeks I've noticed the load average spiking up for 5
minutes at a time (2-3.5 on a system that usually runs around
0.5-1.5). Looking closer I found that one mongrel process and
litespeed are at the top, and using strace I've found that they're
passing the file below, seems to get stuck on single file/EBADF error.
It happens with a number of different urls, and they're all
caches_page so I don't think it has anything to do with my rails code.
Also, the mongrel process is still usable during this time (I can
request pages from it and the loop below continues uneffected, so its
not one request locking up the process). Any ideas on how I can
straighten this out?

thanks,

Zach

(mongrel (1.0.1, cluster 0.2.0, rails 1.1.16, ruby 1.8.4 on fedora)

read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
--- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "GET /flower_delivery/florists_in"..., 16384) = 471
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)
read(188, "", 16384)                    = 0
close(188)                              = 0
close(188)                              = -1 EBADF (Bad file descriptor)

From shodson at gmail.com  Mon May  7 01:45:25 2007
From: shodson at gmail.com (Scott Hodson)
Date: Sun, 6 May 2007 22:45:25 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <20070506025545.GV4346@tigger.digitaltorque.ca>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
Message-ID: <3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>

Try upgrading to Ruby 1.8.6, my mongrels were hanging too until I upgraded
my ruby, gem and rails to the latest versions and it's all working better
now.

On 5/5/07, Michael P. Soulier <msoulier at digitaltorque.ca> wrote:
>
> On 05/05/07 Pete DeLaurentis said:
>
> > Hi Mike,
> >
> > You're definitely hitting this more often then I am (about once per
> > day).
> >
> > With monit, you can do an HTTP request and test the response, which
> > is how I determined if it's hanged.  Sounds pretty similar to what
> > you're doing with cron.
> >
> > Which OS are you running + version of ruby?  I'm on OpenSUSE 10.3,
> > Ruby 1.8.5, Rails 1.2, and Mongrel 1.0.1.  I also run memcached,
> > lighttpd, and pound.  I'm running 6 mongrels using mongrel_cluster
> > (the latest version).
>
> I'm running a Linux VPS, which I think is RedHat based. ruby 1.8.4 and
> mongrel 1.0.1, with Rails 1.2.2.
>
> Mike
> --
> Michael P. Soulier <msoulier at digitaltorque.ca>
> "Any intelligent fool can make things bigger and more complex... It
> takes a touch of genius - and a lot of courage to move in the opposite
> direction." --Albert Einstein
>
> _______________________________________________
> 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/20070506/c85bff04/attachment.html 

From michael.dauria at gmail.com  Mon May  7 10:07:58 2007
From: michael.dauria at gmail.com (Michael D'Auria)
Date: Mon, 7 May 2007 10:07:58 -0400
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
Message-ID: <1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>

I wouldn't upgrade to Ruby 1.8.6 unless my app was written for Rails 1.2 as
Ruby 1.8.6 requires Rails 1.2.3/

On 5/7/07, Scott Hodson <shodson at gmail.com> wrote:
>
> Try upgrading to Ruby 1.8.6, my mongrels were hanging too until I upgraded
> my ruby, gem and rails to the latest versions and it's all working better
> now.
>
> On 5/5/07, Michael P. Soulier <msoulier at digitaltorque.ca> wrote:
> >
> > On 05/05/07 Pete DeLaurentis said:
> >
> > > Hi Mike,
> > >
> > > You're definitely hitting this more often then I am (about once per
> > > day).
> > >
> > > With monit, you can do an HTTP request and test the response, which
> > > is how I determined if it's hanged.  Sounds pretty similar to what
> > > you're doing with cron.
> > >
> > > Which OS are you running + version of ruby?  I'm on OpenSUSE 10.3,
> > > Ruby 1.8.5 , Rails 1.2, and Mongrel 1.0.1.  I also run memcached,
> > > lighttpd, and pound.  I'm running 6 mongrels using mongrel_cluster
> > > (the latest version).
> >
> > I'm running a Linux VPS, which I think is RedHat based. ruby 1.8.4 and
> > mongrel 1.0.1, with Rails 1.2.2.
> >
> > Mike
> > --
> > Michael P. Soulier <msoulier at digitaltorque.ca>
> > "Any intelligent fool can make things bigger and more complex... It
> > takes a touch of genius - and a lot of courage to move in the opposite
> > direction." --Albert Einstein
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070507/d3337094/attachment.html 

From pete at nextengine.com  Mon May  7 10:44:35 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Mon, 7 May 2007 07:44:35 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
Message-ID: <F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>

That's interesting Scott.  I was running Ruby 1.8.4, and first  
noticed the problem when I upgraded to 1.8.6.  I did some other  
things at that same time though... I also added memcached (which I  
connect to in environment.rb).

I recently tried having monit call a simple test controller / action  
every 2 minutes on each mongrel.  The controller doesn't access the  
DB or memcache... it just renders "hello world" to the HTML.   
Shouldn't help... but it does.

So far so good, the mongrels have stayed responsive for the last  
couple days.  Based on the fact that this fixed things, I'm thinking  
it's some kind of timeout issue within mongrel.

-Pete

On May 7, 2007, at 7:07 AM, Michael D'Auria wrote:

> I wouldn't upgrade to Ruby 1.8.6 unless my app was written for  
> Rails 1.2 as Ruby 1.8.6 requires Rails 1.2.3/
>
> On 5/7/07, Scott Hodson <shodson at gmail.com> wrote:
> Try upgrading to Ruby 1.8.6, my mongrels were hanging too until I  
> upgraded my ruby, gem and rails to the latest versions and it's all  
> working better now.
>
> On 5/5/07, Michael P. Soulier <msoulier at digitaltorque.ca > wrote:
> On 05/05/07 Pete DeLaurentis said:
>
> > Hi Mike,
> >
> > You're definitely hitting this more often then I am (about once per
> > day).
> >
> > With monit, you can do an HTTP request and test the response, which
> > is how I determined if it's hanged.  Sounds pretty similar to what
> > you're doing with cron.
> >
> > Which OS are you running + version of ruby?  I'm on OpenSUSE 10.3,
> > Ruby 1.8.5 , Rails 1.2, and Mongrel 1.0.1.  I also run memcached,
> > lighttpd, and pound.  I'm running 6 mongrels using mongrel_cluster
> > (the latest version).
>
> I'm running a Linux VPS, which I think is RedHat based. ruby 1.8.4 and
> mongrel 1.0.1, with Rails 1.2.2.
>
> Mike
> --
> Michael P. Soulier < msoulier at digitaltorque.ca>
> "Any intelligent fool can make things bigger and more complex... It
> takes a touch of genius - and a lot of courage to move in the opposite
> direction." --Albert Einstein
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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/20070507/ca516622/attachment-0001.html 

From wyhaines at gmail.com  Mon May  7 10:53:06 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Mon, 7 May 2007 07:53:06 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
Message-ID: <f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>

On 5/7/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> That's interesting Scott.  I was running Ruby 1.8.4, and first noticed the
> problem when I upgraded to 1.8.6.  I did some other things at that same time
> though... I also added memcached (which I connect to in environment.rb).

Just another useless data point, but I never have had a problem with
Mongrel on Ruby 1.8.5.


Kirk Haines

From miles at pixar.com  Mon May  7 11:22:35 2007
From: miles at pixar.com (Miles Egan)
Date: Mon, 7 May 2007 08:22:35 -0700
Subject: [Mongrel] Mongrel and EBADF error consuming resources
In-Reply-To: <ac243e420705061715q2b64e5e8r97d9486f94b2ad0e@mail.gmail.com>
References: <ac243e420705061715q2b64e5e8r97d9486f94b2ad0e@mail.gmail.com>
Message-ID: <AA092648-12A8-475B-B856-7C7787DFD323@pixar.com>

On May 6, 2007, at 5:15 PM, Zachary Powell wrote:
> In the last few weeks I've noticed the load average spiking up for 5
> minutes at a time (2-3.5 on a system that usually runs around
> 0.5-1.5). Looking closer I found that one mongrel process and
> litespeed are at the top, and using strace I've found that they're
> passing the file below, seems to get stuck on single file/EBADF error.

I've seen this too but I haven't found the cause yet.

--
miles

"If money played an instrument it would be the saxophone." - Achewood

From miles at pixar.com  Mon May  7 11:26:29 2007
From: miles at pixar.com (Miles Egan)
Date: Mon, 7 May 2007 08:26:29 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
Message-ID: <302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>

We've had this here too, to the point where it was becoming a bit of  
a crisis.  I've seen several suggested remedies:

1. make sure your log rotation is done outside mongrel, not using  
ruby's log rotation features
2. make sure your rails app doesn't ever try to write to stdout or  
stderr
3. avoid pstore-based sessions
4. disable http keepalive on the apache frontend

We tried all of these and it looks like #4 might have finally done  
the trick.

--
miles

"If money played an instrument it would be the saxophone." - Achewood

From pete at nextengine.com  Mon May  7 12:06:20 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Mon, 7 May 2007 09:06:20 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
Message-ID: <64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>

Thanks for the tips Miles.  One of them really hit home:

I love writing to stdout, and it's all over the place in my app.   
It's great because you can run your scripts / apps as foreground and  
get a live trace, or daemonized and it goes to the log file.  Your  
warning on this one sounds like the voice of experience, and I  
believe it.  But I'd like to understand the details.

Any ideas why this is a dangerous thing to do?

Thanks,
Pete

BTW. I don't know if lighty has a keepalive feature, but I'll look  
into this.   Sounds like it was the main issue for you, and it could  
be for me too.




On May 7, 2007, at 8:26 AM, Miles Egan wrote:

> We've had this here too, to the point where it was becoming a bit of
> a crisis.  I've seen several suggested remedies:
>
> 1. make sure your log rotation is done outside mongrel, not using
> ruby's log rotation features
> 2. make sure your rails app doesn't ever try to write to stdout or
> stderr
> 3. avoid pstore-based sessions
> 4. disable http keepalive on the apache frontend
>
> We tried all of these and it looks like #4 might have finally done
> the trick.
>
> --
> miles
>
> "If money played an instrument it would be the saxophone." - Achewood
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From miles at pixar.com  Mon May  7 12:20:25 2007
From: miles at pixar.com (Miles Egan)
Date: Mon, 7 May 2007 09:20:25 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<01DE4AEB-E4AD-44AD-9ADD-A198DD79A2E1@nextengine.com>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
Message-ID: <EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>

On May 7, 2007, at 9:06 AM, Pete DeLaurentis wrote:
> Thanks for the tips Miles.  One of them really hit home:
>
> I love writing to stdout, and it's all over the place in my app.
> It's great because you can run your scripts / apps as foreground and
> get a live trace, or daemonized and it goes to the log file.  Your
> warning on this one sounds like the voice of experience, and I
> believe it.  But I'd like to understand the details.
>
> Any ideas why this is a dangerous thing to do?

I gather from browsing this list that it interferes with Ruby's  
threads and non-blocking i/o but I'm sure somebody on the list can  
give you a better explanation.  I'd recommend using the logging  
features and just keeping an active tail -f on the log.

--
miles

"If money played an instrument it would be the saxophone." - Achewood

From wyhaines at gmail.com  Mon May  7 13:03:10 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Mon, 7 May 2007 10:03:10 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
Message-ID: <f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>

On 5/7/07, Miles Egan <miles at pixar.com> wrote:

> > I love writing to stdout, and it's all over the place in my app.
>
> I gather from browsing this list that it interferes with Ruby's
> threads and non-blocking i/o but I'm sure somebody on the list can
> give you a better explanation.  I'd recommend using the logging
> features and just keeping an active tail -f on the log.

It's a shameless plug, but you might look at
http://analogger.swiftcore.org to help with logging.  It should be
simple to use it from Rails, though nobody has given me any specific
feedback on that, yet.


Kirk Haines

From mzukowski at urbacon.net  Mon May  7 14:29:03 2007
From: mzukowski at urbacon.net (Matt Zukowski)
Date: Mon, 07 May 2007 14:29:03 -0400
Subject: [Mongrel] why put .pid's in log instead of tmp?
In-Reply-To: <f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>	<20070506025545.GV4346@tigger.digitaltorque.ca>	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
	<f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>
Message-ID: <463F6FEF.1030700@urbacon.net>

Just out of curiosity, why does mongrel_rails by default put its .pid 
files in the log directory rather than in tmp or tmp/pids? Putting them 
in the log directory seems to me like a strange decision, since they're 
not logs -- they're temporary state files.


This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. 
Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.



From doug.arogos at gmail.com  Mon May  7 14:39:35 2007
From: doug.arogos at gmail.com (Doug Smith)
Date: Mon, 7 May 2007 11:39:35 -0700
Subject: [Mongrel] why put .pid's in log instead of tmp?
In-Reply-To: <463F6FEF.1030700@urbacon.net>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
	<f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>
	<463F6FEF.1030700@urbacon.net>
Message-ID: <42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>

I have thought this as well -- but it's not just Mongrel that does
this.  Ferret's DRb server also puts the .pid file into the logs
directory.   I'd prefer a dedicated location myself.

Thanks,

Doug

On 5/7/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
> Just out of curiosity, why does mongrel_rails by default put its .pid
> files in the log directory rather than in tmp or tmp/pids? Putting them
> in the log directory seems to me like a strange decision, since they're
> not logs -- they're temporary state files.
>
>
> This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited.
> Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From don at jibjab.net  Mon May  7 14:44:33 2007
From: don at jibjab.net (Don Park)
Date: Mon, 7 May 2007 11:44:33 -0700
Subject: [Mongrel] why put .pid's in log instead of tmp?
In-Reply-To: <42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
	<f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>
	<463F6FEF.1030700@urbacon.net>
	<42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>
Message-ID: <FBC69C01-8620-4524-8340-86C29D4547FE@jibjab.net>

i believe the answer is the decision was made pre-rails 1.2 which  
added tmp/* to the rails directory tree. plus maybe other frameworks  
dont have tmp/pids and log was a safe default.

don

On May 7, 2007, at 11:39 AM, Doug Smith wrote:

> I have thought this as well -- but it's not just Mongrel that does
> this.  Ferret's DRb server also puts the .pid file into the logs
> directory.   I'd prefer a dedicated location myself.
>
> Thanks,
>
> Doug
>
> On 5/7/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
>> Just out of curiosity, why does mongrel_rails by default put its .pid
>> files in the log directory rather than in tmp or tmp/pids? Putting  
>> them
>> in the log directory seems to me like a strange decision, since  
>> they're
>> not logs -- they're temporary state files.
>>
>>
>> This e-mail message is privileged, confidential and subject to  
>> copyright. Any unauthorized use or disclosure is prohibited.
>> Le contenu du pr'esent courriel est privil'egi'e, confidentiel et  
>> soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de  
>> le divulguer sans autorisation.
>>
>>
>> _______________________________________________
>> 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


From matte at ruckuswireless.com  Mon May  7 14:46:03 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Mon, 07 May 2007 11:46:03 -0700
Subject: [Mongrel] why put .pid's in log instead of tmp?
In-Reply-To: <42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>	<f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>	<463F6FEF.1030700@urbacon.net>
	<42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>
Message-ID: <463F73EB.5020105@ruckuswireless.com>

So just change your config files.  Easy peasy.

Best practice, if using mongrel_cluster, is to throw it into a directory 
like what you're suggesting.  In the announcement thread for 
mongrel_cluster 1.0.1.1 it's recommended to config for using the 
/var/run directory.  But you can choose what you want.

FYI

matte - matte at ruckuswireless.com

Doug Smith wrote:
> I have thought this as well -- but it's not just Mongrel that does
> this.  Ferret's DRb server also puts the .pid file into the logs
> directory.   I'd prefer a dedicated location myself.
>
> Thanks,
>
> Doug
>
> On 5/7/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
>   
>> Just out of curiosity, why does mongrel_rails by default put its .pid
>> files in the log directory rather than in tmp or tmp/pids? Putting them
>> in the log directory seems to me like a strange decision, since they're
>> not logs -- they're temporary state files.
>>
>>     



From nathanclark80 at gmail.com  Mon May  7 18:55:24 2007
From: nathanclark80 at gmail.com (Nathan Clark)
Date: Mon, 7 May 2007 17:55:24 -0500
Subject: [Mongrel] mongrel becoming unresponsive
Message-ID: <d21af660705071555vca1e6f6wf31579e016554345@mail.gmail.com>

I am also having an issue with mongrel becoming unresponsive.
Here is it's environment:
    Red Hat Enterprise Linux ES release 4
        ruby 1.8.5 (2007-03-13 patchlevel 35) [x86_64-linux]
    Mongrel Web Server 1.0.1

In front of these mongrels, is Apache and the haproxy load balancer

I am running several different ROR sites on the same server.
after a few hours the rails application will become unresponsive.

My log file sings this tune:

    Server overloaded with 5 processors (5 max). Dropping connection.
    Mon May 07 11:53:04 -0500 2007: Reaping 4 threads for slow workers
because of 'max processors'
    Thread #<Thread:0x2a98447ab0 sleep> is too old, killing.
    Mon May 07 11:53:04 -0500 2007: ERROR: Mongrel timed out this thread:
max processorsThread #<Thread:0x2a98451740 sleep> is too old, killing.
    Mon May 07 11:53:04 -0500 2007: ERROR: Mongrel timed out this thread:
max processorsThread #<Thread:0x2a98459990 sleep> is too old, killing.
    Mon May 07 11:53:04 -0500 2007: ERROR: Mongrel timed out this thread:
max processorsThread #<Thread:0x2a984d9168 sleep> is too old, killing.

    Server overloaded with 5 processors (5 max). Dropping connection.
    Mon May 07 11:53:06 -0500 2007: Reaping 5 threads for slow workers
because of 'max processors'

    Mon May 07 13:29:29 -0500 2007: Reaping 3 threads for slow workers
because of 'shutdown'
    Thread #<Thread:0x2a98472468 sleep> is too old, killing.
    Mon May 07 13:29:29 -0500 2007: Error calling
Dispatcher.dispatch#<Mongrel::TimeoutError: Mongrel timed out this
thread: shutdown>Thread
#<Thread:0x2a98597b68 sleep> is too old, killing.

A restart of the mongrel, fixes it, but it doesn't last.
I have been trying to use the gdb to to gain some insight as the the root
cause.
Using the examples I found on the web,, the following was suggested

    (gdb) set $ary = (int)backtrace(-1)
    (gdb) set $count = *($ary+8)
    (gdb) set $index = 0
    (gdb) while $index < $count
    >  x/1s *((int)rb_ary_entry($ary, $index)+12)
    >  set $index = $index + 1
    >end

However, I get an error on the second line
    "(gdb) set $count = *($ary+8)
    Cannot access memory at address 0xffffffff985779d8"

Has anyone seen this before?

Cheers,
Nathan C.


-- 
Together we can solve any issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070507/87c2ab8b/attachment.html 

From ezmobius at gmail.com  Mon May  7 19:01:20 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Mon, 7 May 2007 16:01:20 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <d21af660705071555vca1e6f6wf31579e016554345@mail.gmail.com>
References: <d21af660705071555vca1e6f6wf31579e016554345@mail.gmail.com>
Message-ID: <FD6127AA-7612-4862-BA9F-97D9ECB0B08A@brainspl.at>

Nathan-


	This line is very telling:

   Server overloaded with 5 processors (5 max). Dropping connection

	Mongrel has a numprocs setting that defaults to 900 i think. It  
looks like somehow it is being set to 5 in your mongrels so they  
start timing out threads when there are more then 5 connections in  
mongrel being processed. I'd say up your numb procs to 50 or so and  
if you are using haproxy make it limit connections to mongrel to one  
at atime. That way the requests queue in haproxy and only go to  
mongrels that aren't busy.


Cheers-
-Ezra
	

On May 7, 2007, at 3:55 PM, Nathan Clark wrote:

> I am also having an issue with mongrel becoming unresponsive.
> Here is it's environment:
>     Red Hat Enterprise Linux ES release 4
>         ruby 1.8.5 (2007-03-13 patchlevel 35) [x86_64-linux]
>     Mongrel Web Server 1.0.1
>
> In front of these mongrels, is Apache and the haproxy load balancer
>
> I am running several different ROR sites on the same server.
> after a few hours the rails application will become unresponsive.
>
> My log file sings this tune:
>
>     Server overloaded with 5 processors (5 max). Dropping connection.
>     Mon May 07 11:53:04 -0500 2007: Reaping 4 threads for slow  
> workers because of 'max processors'
>     Thread #<Thread:0x2a98447ab0 sleep> is too old, killing.
>     Mon May 07 11:53:04 -0500 2007: ERROR: Mongrel timed out this  
> thread: max processorsThread #<Thread:0x2a98451740 sleep> is too  
> old, killing.
>     Mon May 07 11:53:04 -0500 2007: ERROR: Mongrel timed out this  
> thread: max processorsThread #<Thread:0x2a98459990 sleep> is too  
> old, killing.
>     Mon May 07 11:53:04 -0500 2007: ERROR: Mongrel timed out this  
> thread: max processorsThread #<Thread:0x2a984d9168 sleep> is too  
> old, killing.
>
>     Server overloaded with 5 processors (5 max). Dropping connection.
>     Mon May 07 11:53:06 -0500 2007: Reaping 5 threads for slow  
> workers because of 'max processors'
>
>     Mon May 07 13:29:29 -0500 2007: Reaping 3 threads for slow  
> workers because of 'shutdown'
>     Thread #<Thread:0x2a98472468 sleep> is too old, killing.
>     Mon May 07 13:29:29 -0500 2007: Error calling  
> Dispatcher.dispatch #<Mongrel::TimeoutError: Mongrel timed out this  
> thread: shutdown>Thread #<Thread:0x2a98597b68 sleep> is too old,  
> killing.
>
> A restart of the mongrel, fixes it, but it doesn't last.
> I have been trying to use the gdb to to gain some insight as the  
> the root cause.
> Using the examples I found on the web,, the following was suggested
>
>     (gdb) set $ary = (int)backtrace(-1)
>     (gdb) set $count = *($ary+8)
>     (gdb) set $index = 0
>     (gdb) while $index < $count
>     >  x/1s *((int)rb_ary_entry($ary, $index)+12)
>     >  set $index = $index + 1
>     >end
>
> However, I get an error on the second line
>     "(gdb) set $count = *($ary+8)
>     Cannot access memory at address 0xffffffff985779d8"
>
> Has anyone seen this before?
>
> Cheers,
> Nathan C.
>
>
> -- 
> Together we can solve any issue.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)



From eden at mojiti.com  Tue May  8 02:55:33 2007
From: eden at mojiti.com (Eden Li)
Date: Tue, 8 May 2007 14:55:33 +0800
Subject: [Mongrel] why put .pid's in log instead of tmp?
In-Reply-To: <463F73EB.5020105@ruckuswireless.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
	<f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>
	<463F6FEF.1030700@urbacon.net>
	<42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>
	<463F73EB.5020105@ruckuswireless.com>
Message-ID: <1dd361e10705072355x1b7128b3j3f90b16a54d0e22d@mail.gmail.com>

One more reason -- in capistrano deployed setups, the log directory is
shared among all releases, but the rails tmp directory is not.  The
default mongrel restart recipes will complain that they can't find pid
files because the xxx/current/tmp will have been moved to a freshly
checked-out version of your which doesn't have the old tmp directory
from your previous deploy.

You'd probably have to mess with your recipes if you're using
capistrano, or make the tmp directory shared as well...

On 5/8/07, Matte Edens <matte at ruckuswireless.com> wrote:
> So just change your config files.  Easy peasy.
>
> Best practice, if using mongrel_cluster, is to throw it into a directory
> like what you're suggesting.  In the announcement thread for
> mongrel_cluster 1.0.1.1 it's recommended to config for using the
> /var/run directory.  But you can choose what you want.
>
> FYI
>
> matte - matte at ruckuswireless.com
>
> Doug Smith wrote:
> > I have thought this as well -- but it's not just Mongrel that does
> > this.  Ferret's DRb server also puts the .pid file into the logs
> > directory.   I'd prefer a dedicated location myself.
> >
> > Thanks,
> >
> > Doug
> >
> > On 5/7/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
> >
> >> Just out of curiosity, why does mongrel_rails by default put its .pid
> >> files in the log directory rather than in tmp or tmp/pids? Putting them
> >> in the log directory seems to me like a strange decision, since they're
> >> not logs -- they're temporary state files.
> >>
> >>
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From luislavena at gmail.com  Tue May  8 10:06:43 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 8 May 2007 11:06:43 -0300
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
Message-ID: <71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>

On 5/7/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Thanks for the tips Miles.  One of them really hit home:
>
> I love writing to stdout, and it's all over the place in my app.
> It's great because you can run your scripts / apps as foreground and
> get a live trace, or daemonized and it goes to the log file.  Your
> warning on this one sounds like the voice of experience, and I
> believe it.  But I'd like to understand the details.
>
> Any ideas why this is a dangerous thing to do?
>

Pete,

puts or anything that prints to stdout/stderr interfere with CGI
(Servlet dispatcher used by Rails).

Also, puts not being threadsafe (you cannot garantee "this line #1"
will get print fully form one thread and other text line from another
will without interfere eachother).


use RAILS_DEFAULT_LOGGER (or just 'logger' in your controllers, views
or models).

logger.debug (for debug level) is very helpful during development.


-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From don at jibjab.net  Tue May  8 11:15:43 2007
From: don at jibjab.net (Don Park)
Date: Tue, 8 May 2007 08:15:43 -0700
Subject: [Mongrel] why put .pid's in log instead of tmp?
In-Reply-To: <1dd361e10705072355x1b7128b3j3f90b16a54d0e22d@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<EEB04F8C-A458-480F-837E-27AD7C932945@pixar.com>
	<f4cd26df0705071003g733df7cek177afe42b8bd6f35@mail.gmail.com>
	<463F6FEF.1030700@urbacon.net>
	<42d8808f0705071139u51657af0we61b50cc60d97b4c@mail.gmail.com>
	<463F73EB.5020105@ruckuswireless.com>
	<1dd361e10705072355x1b7128b3j3f90b16a54d0e22d@mail.gmail.com>
Message-ID: <395299B8-6808-45CB-968A-5341513E2992@jibjab.net>

I beileve that pid files are release specific, as are the running  
mongrels.

the problem you describe is when the capistrano recipe does an svn  
update, shutdown, startup. the svn update replaces the directory tree  
under the running processes. i imagine the reasoning was to minimize  
downtime if the svn up is a time-consuming process.

a better order is to shutdown, svn up, startup. there is an  
association between the running mongrels and the tmp/pids of the  
release directory in which they started. let the running processes  
shutdown in their own release directory, then replace the release  
directory.

don

On May 7, 2007, at 11:55 PM, Eden Li wrote:

> One more reason -- in capistrano deployed setups, the log directory is
> shared among all releases, but the rails tmp directory is not.  The
> default mongrel restart recipes will complain that they can't find pid
> files because the xxx/current/tmp will have been moved to a freshly
> checked-out version of your which doesn't have the old tmp directory
> from your previous deploy.
>
> You'd probably have to mess with your recipes if you're using
> capistrano, or make the tmp directory shared as well...
>
> On 5/8/07, Matte Edens <matte at ruckuswireless.com> wrote:
>> So just change your config files.  Easy peasy.
>>
>> Best practice, if using mongrel_cluster, is to throw it into a  
>> directory
>> like what you're suggesting.  In the announcement thread for
>> mongrel_cluster 1.0.1.1 it's recommended to config for using the
>> /var/run directory.  But you can choose what you want.
>>
>> FYI
>>
>> matte - matte at ruckuswireless.com
>>
>> Doug Smith wrote:
>>> I have thought this as well -- but it's not just Mongrel that does
>>> this.  Ferret's DRb server also puts the .pid file into the logs
>>> directory.   I'd prefer a dedicated location myself.
>>>
>>> Thanks,
>>>
>>> Doug
>>>
>>> On 5/7/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
>>>
>>>> Just out of curiosity, why does mongrel_rails by default put  
>>>> its .pid
>>>> files in the log directory rather than in tmp or tmp/pids?  
>>>> Putting them
>>>> in the log directory seems to me like a strange decision, since  
>>>> they're
>>>> not logs -- they're temporary state files.
>>>>
>>>>
>>
>>
>> _______________________________________________
>> 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


From pete at nextengine.com  Tue May  8 11:21:36 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Tue, 8 May 2007 08:21:36 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<20070506020517.GT4346@tigger.digitaltorque.ca>
	<C9751B2D-53E7-4837-B6B7-AAD6F790774D@nextengine.com>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>
Message-ID: <257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>

Thanks for the explanation Luis.  This makes good sense.  It seems  
like Mongrel is intercepting the stdout + sterr (puts it all into  
mongrel.log), but it's not good to work with something that isn't  
threadsafe.

Makes me wonder if the rails logs are safe if you write to them from  
different mongrels in a cluster.  Any experience with this?

Thanks,
Pete



> Pete,
>
> puts or anything that prints to stdout/stderr interfere with CGI
> (Servlet dispatcher used by Rails).
>
> Also, puts not being threadsafe (you cannot garantee "this line #1"
> will get print fully form one thread and other text line from another
> will without interfere eachother).
>
>
> use RAILS_DEFAULT_LOGGER (or just 'logger' in your controllers, views
> or models).
>
> logger.debug (for debug level) is very helpful during development.
>
>
> -- 
> Luis Lavena
> Multimedia systems
> -
> Leaders are made, they are not born. They are made by hard effort,
> which is the price which all of us must pay to achieve any goal that
> is worthwhile.
> Vince Lombardi
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From luislavena at gmail.com  Tue May  8 11:33:41 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 8 May 2007 12:33:41 -0300
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>
	<257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>
Message-ID: <71166b3b0705080833p1589094ak45fa9d9b503d755@mail.gmail.com>

On 5/8/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Thanks for the explanation Luis.  This makes good sense.  It seems
> like Mongrel is intercepting the stdout + sterr (puts it all into
> mongrel.log), but it's not good to work with something that isn't
> threadsafe.
>
> Makes me wonder if the rails logs are safe if you write to them from
> different mongrels in a cluster.  Any experience with this?
>

Are safe only under the following conditions:

2 Mongrels in the cluster don't get hit at the same time, with the
same request that takes the same time to parse and process...

That means: no :-)
(Even under labs conditions that couldn't be granted).

Page sharing of files opened between process is something difficult to
achieve, I'll suggest 1 log file per process on each port, which will
reduce chances of logfiles get corrupted.

> Thanks,
> Pete
>

You're welcome.

Good week,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From wyhaines at gmail.com  Tue May  8 11:47:12 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 8 May 2007 08:47:12 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>
	<257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>
Message-ID: <f4cd26df0705080847p6441416dx17eb3310232c1a33@mail.gmail.com>

On 5/8/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Thanks for the explanation Luis.  This makes good sense.  It seems
> like Mongrel is intercepting the stdout + sterr (puts it all into
> mongrel.log), but it's not good to work with something that isn't
> threadsafe.

This probably begs some elaboration on just what puts() does.  It
writes your string in one write operation, and does the newline in a
second operation, which opens the possibility that Ruby can make a
context switch between them.  If the newline is already in the string,
though, it is just a single write operation.  You can also use write()
instead of puts() to explicitly make sure that everything is done in a
single write call.

Take a look at the code in io.c for the details.

> Makes me wonder if the rails logs are safe if you write to them from
> different mongrels in a cluster.  Any experience with this?

Even if it can be made "safe", contention from multiple processes
trying to write to one file can be a non-trivial performance hit.
This was one of my motivations for writing an async logger.  I want
all of my app logs in the same place, even if I have multiple backend
processes, without worrying about resource contention.  It's that, or
I have N log files, one for each backend process for my app.


Kirk Haines

From pete at nextengine.com  Tue May  8 11:55:31 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Tue, 8 May 2007 08:55:31 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <f4cd26df0705080847p6441416dx17eb3310232c1a33@mail.gmail.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<20070506025545.GV4346@tigger.digitaltorque.ca>
	<3eb4ce590705062245h2cd9bcc7l6ab3531467d149b8@mail.gmail.com>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>
	<257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>
	<f4cd26df0705080847p6441416dx17eb3310232c1a33@mail.gmail.com>
Message-ID: <11DA6742-6DD4-4206-B3F4-1ECEAC4579DA@nextengine.com>

Thanks for the info Kirk, and for letting us know about your logger  
plugin.  It sounds like exactly what I need.

I think I'll override Kernel.puts to use your plugin.

-Pete


On May 8, 2007, at 8:47 AM, Kirk Haines wrote:

> On 5/8/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>> Thanks for the explanation Luis.  This makes good sense.  It seems
>> like Mongrel is intercepting the stdout + sterr (puts it all into
>> mongrel.log), but it's not good to work with something that isn't
>> threadsafe.
>
> This probably begs some elaboration on just what puts() does.  It
> writes your string in one write operation, and does the newline in a
> second operation, which opens the possibility that Ruby can make a
> context switch between them.  If the newline is already in the string,
> though, it is just a single write operation.  You can also use write()
> instead of puts() to explicitly make sure that everything is done in a
> single write call.
>
> Take a look at the code in io.c for the details.
>
>> Makes me wonder if the rails logs are safe if you write to them from
>> different mongrels in a cluster.  Any experience with this?
>
> Even if it can be made "safe", contention from multiple processes
> trying to write to one file can be a non-trivial performance hit.
> This was one of my motivations for writing an async logger.  I want
> all of my app logs in the same place, even if I have multiple backend
> processes, without worrying about resource contention.  It's that, or
> I have N log files, one for each backend process for my app.
>
>
> Kirk Haines
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From wyhaines at gmail.com  Tue May  8 12:17:14 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 8 May 2007 09:17:14 -0700
Subject: [Mongrel] mongrel becoming unresponsive
In-Reply-To: <11DA6742-6DD4-4206-B3F4-1ECEAC4579DA@nextengine.com>
References: <20070506010410.GS4346@tigger.digitaltorque.ca>
	<1907e2ca0705070707q5a9c1089hf23bfb0e6c755d43@mail.gmail.com>
	<F1390AAD-2B37-408B-97E2-19CA42AE4F38@nextengine.com>
	<f4cd26df0705070753s154d4e52w60798b36a8b62b30@mail.gmail.com>
	<302DE115-EE26-4C89-B368-6DB0D7122BB0@pixar.com>
	<64751C8C-EF98-463B-B189-37F25CF827AB@nextengine.com>
	<71166b3b0705080706n6065fc78vff7ee2885ca90d38@mail.gmail.com>
	<257A25CE-63EF-4B00-AE5F-CC7CD3AD8903@nextengine.com>
	<f4cd26df0705080847p6441416dx17eb3310232c1a33@mail.gmail.com>
	<11DA6742-6DD4-4206-B3F4-1ECEAC4579DA@nextengine.com>
Message-ID: <f4cd26df0705080917h591e557aj37b2804a5ee418f0@mail.gmail.com>

On 5/8/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Thanks for the info Kirk, and for letting us know about your logger
> plugin.  It sounds like exactly what I need.
>
> I think I'll override Kernel.puts to use your plugin.

Let me know if there's anything I can bundle in the next release to
make Rails or Mongrel logging integration simpler.


Kirk Haines

From ehudros at gmail.com  Tue May  8 17:06:38 2007
From: ehudros at gmail.com (Ehud Rosenberg)
Date: Wed, 9 May 2007 00:06:38 +0300
Subject: [Mongrel] mongrel_cluster 1.0.1.1 does not create
	/var/run/mongrel_cluster
In-Reply-To: <5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>
References: <1178658092.339964.297770@e51g2000hsg.googlegroups.com>
	<5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>
Message-ID: <ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>

Hi everyone,
I am going crazy over here! :)
I just want to be able to use --clean with my mongrel_rails
cluster::start command.
I've upgraded to mongrel_cluster 1.0.1.1 and mongrel_rails 1.0.1.
my config file is in /etc/mongrel_rails/config.yml
and contains:
---
log_file: log/mongrel.log
port: 8000
pid_file: /var/run/mongrel_cluster/mongrel.pid
servers: 2
address: 127.0.0.1
environment: production

in the following post it says the init.rb script from mongrel_cluster
should create the var/run directory itself, but it does not seem to do
so ( I get the message:
!!! Path to log file not valid: log/mongrel.8001.log
mongrel::start reported an error. Use mongrel_rails mongrel::start -h
to get help)

Also, when I manually set the pid file dir to what it used to be (the
log dir of my app)
it does not clean it up and still give the old message that a PID
already exists - i'm not sure if that's because it's not in /var/run
as I have seen different comments on this.

Any help would be appreciated...

Thanks!
Ehud.

PS - I have also tried running mongrel_rails cluster::configure -C /
etc/mongrel_rails/config.yml again but all it did was overwrite my
file...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070509/472910b0/attachment.html 

From ehudros at gmail.com  Tue May  8 17:10:17 2007
From: ehudros at gmail.com (Ehud Rosenberg)
Date: Wed, 9 May 2007 00:10:17 +0300
Subject: [Mongrel] mongrel_cluster 1.0.1.1 does not create
	/var/run/mongrel_cluster
In-Reply-To: <ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
References: <1178658092.339964.297770@e51g2000hsg.googlegroups.com>
	<5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>
	<ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
Message-ID: <ea839f150705081410k52ab42b5y9ee8b824f42daf3@mail.gmail.com>

Sorry for the quick double post, but the error message I pasted is wrong -
It says the log directory is wrong (and it was) but after fixing it I get
the message about the pid directory not valid: !!! Path to pid file not
valid: /var/run/mongrel_cluster/mongrel.8001.pid

I do not want to create this directory myself since I think something in my
installation is wrong and the init.rb file is not run.

On 5/9/07, Ehud Rosenberg <ehudros at gmail.com> wrote:
>
> Hi everyone,
> I am going crazy over here! :)
> I just want to be able to use --clean with my mongrel_rails
> cluster::start command.
> I've upgraded to mongrel_cluster 1.0.1.1 and mongrel_rails 1.0.1.
> my config file is in /etc/mongrel_rails/config.yml
> and contains:
> ---
> log_file: log/mongrel.log
> port: 8000
> pid_file: /var/run/mongrel_cluster/mongrel.pid
> servers: 2
> address: 127.0.0.1
> environment: production
>
> in the following post it says the init.rb script from mongrel_cluster
> should create the var/run directory itself, but it does not seem to do
> so ( I get the message:
> !!! Path to log file not valid: log/mongrel.8001.log
> mongrel::start reported an error. Use mongrel_rails mongrel::start -h
> to get help)
>
> Also, when I manually set the pid file dir to what it used to be (the
> log dir of my app)
> it does not clean it up and still give the old message that a PID
> already exists - i'm not sure if that's because it's not in /var/run
> as I have seen different comments on this.
>
> Any help would be appreciated...
>
> Thanks!
> Ehud.
>
> PS - I have also tried running mongrel_rails cluster::configure -C /
> etc/mongrel_rails/config.yml again but all it did was overwrite my
> file...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070509/3b97fef5/attachment.html 

From jgeiger at gmail.com  Tue May  8 17:10:22 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Tue, 8 May 2007 16:10:22 -0500
Subject: [Mongrel] mongrel_cluster 1.0.1.1 does not create
	/var/run/mongrel_cluster
In-Reply-To: <ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
References: <1178658092.339964.297770@e51g2000hsg.googlegroups.com>
	<5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>
	<ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
Message-ID: <466af3440705081410j7ec0416et1d7a6478e99a3111@mail.gmail.com>

I created a startup script that just creates the
/var/run/mongrel_cluster on boot, since it's removed every time you
restart.


On 5/8/07, Ehud Rosenberg <ehudros at gmail.com> wrote:
> Hi everyone,
> I am going crazy over here! :)
> I just want to be able to use --clean with my mongrel_rails
> cluster::start command.
> I've upgraded to mongrel_cluster 1.0.1.1 and mongrel_rails 1.0.1.
> my config file is in /etc/mongrel_rails/config.yml
> and contains:
> ---
> log_file: log/mongrel.log
> port: 8000
> pid_file: /var/run/mongrel_cluster/mongrel.pid
> servers: 2
> address: 127.0.0.1
> environment: production
>
> in the following post it says the init.rb script from mongrel_cluster
> should create the var/run directory itself, but it does not seem to do
> so ( I get the message:
> !!! Path to log file not valid: log/mongrel.8001.log
> mongrel::start reported an error. Use mongrel_rails mongrel::start -h
> to get help)
>
> Also, when I manually set the pid file dir to what it used to be (the
> log dir of my app)
> it does not clean it up and still give the old message that a PID
> already exists - i'm not sure if that's because it's not in /var/run
> as I have seen different comments on this.
>
> Any help would be appreciated...
>
> Thanks!
> Ehud.
>
> PS - I have also tried running mongrel_rails cluster::configure -C /
> etc/mongrel_rails/config.yml again but all it did was overwrite my
> file...
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From seanmichaelbrown at gmail.com  Tue May  8 17:28:26 2007
From: seanmichaelbrown at gmail.com (Sean Brown)
Date: Tue, 8 May 2007 17:28:26 -0400
Subject: [Mongrel] mongrel_cluster 1.0.1.1 does not create
	/var/run/mongrel_cluster
In-Reply-To: <ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
References: <1178658092.339964.297770@e51g2000hsg.googlegroups.com>
	<5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>
	<ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
Message-ID: <1086fb5f0705081428n5cacc679j4b4f56858ac780ac@mail.gmail.com>

On 5/8/07, Ehud Rosenberg <ehudros at gmail.com> wrote:
>
> in the following post it says the init.rb script from mongrel_cluster
> should create the var/run directory itself, but it does not seem to do
> so ( I get the message:
> !!! Path to log file not valid: log/mongrel.8001.log
> mongrel::start reported an error. Use mongrel_rails mongrel::start -h
> to get help)

Sounds like a ownership/permissions error.  Make sure that whatever
user you have running mongrel_cluster also has "write" permissions to
the log directory of your Rails app.  If you followed the instructions
on the Mongrel site, that user would be "mongrel".


-- 

Sean Brown

From bradley at railsmachine.com  Wed May  9 10:29:58 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Wed, 09 May 2007 10:29:58 -0400
Subject: [Mongrel] mongrel_cluster 1.0.1.1 does not
	create	/var/run/mongrel_cluster
In-Reply-To: <466af3440705081410j7ec0416et1d7a6478e99a3111@mail.gmail.com>
References: <1178658092.339964.297770@e51g2000hsg.googlegroups.com>	<5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>	<ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
	<466af3440705081410j7ec0416et1d7a6478e99a3111@mail.gmail.com>
Message-ID: <4641DAE6.50408@railsmachine.com>

The new init.d script already does this. Look in 
resources/mongrel_cluster in the gem directory.

Bradley

Joey Geiger wrote:
> I created a startup script that just creates the
> /var/run/mongrel_cluster on boot, since it's removed every time you
> restart.
> 
> 
> On 5/8/07, Ehud Rosenberg <ehudros at gmail.com> wrote:
>> Hi everyone,
>> I am going crazy over here! :)
>> I just want to be able to use --clean with my mongrel_rails
>> cluster::start command.
>> I've upgraded to mongrel_cluster 1.0.1.1 and mongrel_rails 1.0.1.
>> my config file is in /etc/mongrel_rails/config.yml
>> and contains:
>> ---
>> log_file: log/mongrel.log
>> port: 8000
>> pid_file: /var/run/mongrel_cluster/mongrel.pid
>> servers: 2
>> address: 127.0.0.1
>> environment: production
>>
>> in the following post it says the init.rb script from mongrel_cluster
>> should create the var/run directory itself, but it does not seem to do
>> so ( I get the message:
>> !!! Path to log file not valid: log/mongrel.8001.log
>> mongrel::start reported an error. Use mongrel_rails mongrel::start -h
>> to get help)
>>
>> Also, when I manually set the pid file dir to what it used to be (the
>> log dir of my app)
>> it does not clean it up and still give the old message that a PID
>> already exists - i'm not sure if that's because it's not in /var/run
>> as I have seen different comments on this.
>>
>> Any help would be appreciated...
>>
>> Thanks!
>> Ehud.
>>
>> PS - I have also tried running mongrel_rails cluster::configure -C /
>> etc/mongrel_rails/config.yml again but all it did was overwrite my
>> file...
>>
>>
>> _______________________________________________
>> 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


From jgeiger at gmail.com  Wed May  9 13:06:37 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Wed, 9 May 2007 12:06:37 -0500
Subject: [Mongrel] mongrel_cluster 1.0.1.1 does not create
	/var/run/mongrel_cluster
In-Reply-To: <4641DAE6.50408@railsmachine.com>
References: <1178658092.339964.297770@e51g2000hsg.googlegroups.com>
	<5649f11a0705081405s623ef0e9iecaa5dc6ddd7d934@mail.gmail.com>
	<ea839f150705081406p441487cq24384dd89373ffb0@mail.gmail.com>
	<466af3440705081410j7ec0416et1d7a6478e99a3111@mail.gmail.com>
	<4641DAE6.50408@railsmachine.com>
Message-ID: <466af3440705091006u1b5e6c57p1987e4f7360a2c93@mail.gmail.com>

I had an issue with the /var/run/mongrel_cluster issue as I'm not
starting the cluster via the init.d script anymore. I'm using monit to
start up each of the mongrels by themselves. Due to that, I need to
create that directory via it's own init.d script so it exists before
monit tries to start them up...

kinda hacky, but it's working for me now.


On 5/9/07, Bradley Taylor <bradley at railsmachine.com> wrote:
> The new init.d script already does this. Look in
> resources/mongrel_cluster in the gem directory.
>
> Bradley
>
> Joey Geiger wrote:
> > I created a startup script that just creates the
> > /var/run/mongrel_cluster on boot, since it's removed every time you
> > restart.
> >
> >
> > On 5/8/07, Ehud Rosenberg <ehudros at gmail.com> wrote:
> >> Hi everyone,
> >> I am going crazy over here! :)
> >> I just want to be able to use --clean with my mongrel_rails
> >> cluster::start command.
> >> I've upgraded to mongrel_cluster 1.0.1.1 and mongrel_rails 1.0.1.
> >> my config file is in /etc/mongrel_rails/config.yml
> >> and contains:
> >> ---
> >> log_file: log/mongrel.log
> >> port: 8000
> >> pid_file: /var/run/mongrel_cluster/mongrel.pid
> >> servers: 2
> >> address: 127.0.0.1
> >> environment: production
> >>
> >> in the following post it says the init.rb script from mongrel_cluster
> >> should create the var/run directory itself, but it does not seem to do
> >> so ( I get the message:
> >> !!! Path to log file not valid: log/mongrel.8001.log
> >> mongrel::start reported an error. Use mongrel_rails mongrel::start -h
> >> to get help)
> >>
> >> Also, when I manually set the pid file dir to what it used to be (the
> >> log dir of my app)
> >> it does not clean it up and still give the old message that a PID
> >> already exists - i'm not sure if that's because it's not in /var/run
> >> as I have seen different comments on this.
> >>
> >> Any help would be appreciated...
> >>
> >> Thanks!
> >> Ehud.
> >>
> >> PS - I have also tried running mongrel_rails cluster::configure -C /
> >> etc/mongrel_rails/config.yml again but all it did was overwrite my
> >> file...
> >>
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From carl.lerche at gmail.com  Wed May  9 17:39:05 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Wed, 9 May 2007 14:39:05 -0700
Subject: [Mongrel] Tell me why my Shoutcase handler sucks!
In-Reply-To: <ab90312e0705042001ib61bfd3h5c35e11734ea88cb@mail.gmail.com>
References: <ab90312e0705041959j40e2f8aeo4a1854e4bb109cc7@mail.gmail.com>
	<ab90312e0705042001ib61bfd3h5c35e11734ea88cb@mail.gmail.com>
Message-ID: <ab90312e0705091439r74646022o8536fc81e2ca1c8c@mail.gmail.com>

This sparks nobody's interest? That makes me a sad panda :(

On 5/4/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> woops, the subject is supposed to be Shoutcast!!!
>
> On 5/4/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> > So, I want to build the greatest online radio ever! (for my, currently
> > crappy, faderwave.net radio station. Right now, I'm running Icecast
> > straight up. The only problem is that managing different DJs and
> > keeping them off the air when they aren't supposed to be there is a
> > pain. There also is not one single management package that does
> > everything. My current system is a hacked together mess.
> >
> > So, I want to build a unified ruby based solution. No, I'm not going
> > to try to replace Icecast with a hacked pure ruby version, but I am
> > going to try to setup a proxy for DJs to connect to where I can manage
> > every small bit.
> >
> > To do all that, I really have to understand how Icecast works. So, I
> > hacked together a mongrel handler that can accept broadcasting clients
> > and send the stream to listeners... except I don't really know what
> > I'm doing. So, I would appreciate it if you could look over the code
> > and tell me why it sucks and how to improve it. It's really short,
> > under 100 lines with comments.
> >
> > Of course, this is just a really rough solution that I hacked together
> > to experiment with interfacing with broadcasting clients and audio
> > players. Anyway, here it is:
> >
> > http://pastie.caboo.se/59073
> >
> > Thanks,
> > -carl
> > --
> > EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> >
>
>
> --
> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From ezmobius at gmail.com  Wed May  9 17:43:21 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Wed, 9 May 2007 14:43:21 -0700
Subject: [Mongrel] Tell me why my Shoutcase handler sucks!
In-Reply-To: <ab90312e0705091439r74646022o8536fc81e2ca1c8c@mail.gmail.com>
References: <ab90312e0705041959j40e2f8aeo4a1854e4bb109cc7@mail.gmail.com>
	<ab90312e0705042001ib61bfd3h5c35e11734ea88cb@mail.gmail.com>
	<ab90312e0705091439r74646022o8536fc81e2ca1c8c@mail.gmail.com>
Message-ID: <0C5629D3-92E2-4789-BAB8-3AB1819F5587@brainspl.at>


	Hey Carl-- I thought it was cool ;)

Cheers-
-Ezra


On May 9, 2007, at 2:39 PM, Carl Lerche wrote:

> This sparks nobody's interest? That makes me a sad panda :(
>
> On 5/4/07, Carl Lerche <carl.lerche at gmail.com> wrote:
>> woops, the subject is supposed to be Shoutcast!!!
>>
>> On 5/4/07, Carl Lerche <carl.lerche at gmail.com> wrote:
>>> So, I want to build the greatest online radio ever! (for my,  
>>> currently
>>> crappy, faderwave.net radio station. Right now, I'm running Icecast
>>> straight up. The only problem is that managing different DJs and
>>> keeping them off the air when they aren't supposed to be there is a
>>> pain. There also is not one single management package that does
>>> everything. My current system is a hacked together mess.
>>>
>>> So, I want to build a unified ruby based solution. No, I'm not going
>>> to try to replace Icecast with a hacked pure ruby version, but I am
>>> going to try to setup a proxy for DJs to connect to where I can  
>>> manage
>>> every small bit.
>>>
>>> To do all that, I really have to understand how Icecast works. So, I
>>> hacked together a mongrel handler that can accept broadcasting  
>>> clients
>>> and send the stream to listeners... except I don't really know what
>>> I'm doing. So, I would appreciate it if you could look over the code
>>> and tell me why it sucks and how to improve it. It's really short,
>>> under 100 lines with comments.
>>>
>>> Of course, this is just a really rough solution that I hacked  
>>> together
>>> to experiment with interfacing with broadcasting clients and audio
>>> players. Anyway, here it is:
>>>
>>> http://pastie.caboo.se/59073
>>>
>>> Thanks,
>>> -carl
>>> --
>>> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
>>>
>>
>>
>> --
>> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
>>
>
>
> -- 
> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)



From veeraa.1 at gmail.com  Thu May 10 00:04:15 2007
From: veeraa.1 at gmail.com (veeraa bose)
Date: Thu, 10 May 2007 09:34:15 +0530
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.5
Message-ID: <1c22b00705092104m7ea1ed5avede22d01b4f6fbce@mail.gmail.com>

Dear  ALL,
I saw this in article from mongrel faq,

Q: Mongrel stops working if it's left alone for a long time.

If you find that Mongrel stops working after a long idle time and you're
using MySQL then you're hitting a bug in the MySQL driver that doesn't
properly timeout connections. What happens is the MySQL *server* side of the
connection times out and closes, but the MySQL *client* doesn't detect this
and just sits there.

What you have to do is set:

ActiveRecord::Base.verification_timeout = 14400

Or to any value that is lower than the MySQL server's
*interactive_timeout*setting. This will make sure that ActiveRecord
checks the connection often
enough to reset the connection..
Could anybody please tell me  in which  file I have to update this
"ActiveRecord::Base.verification_timeout = 14400"


Thanks and regards
veeraa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070510/16ca9146/attachment.html 

From luislavena at gmail.com  Thu May 10 00:07:08 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 10 May 2007 01:07:08 -0300
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.5
In-Reply-To: <1c22b00705092104m7ea1ed5avede22d01b4f6fbce@mail.gmail.com>
References: <1c22b00705092104m7ea1ed5avede22d01b4f6fbce@mail.gmail.com>
Message-ID: <71166b3b0705092107o3d8eecdag3e41d9494b366e4e@mail.gmail.com>

On 5/10/07, veeraa bose <veeraa.1 at gmail.com> wrote:
> Dear  ALL,
> I saw this in article from mongrel faq,
>
> Q: Mongrel stops working if it's left alone for a long time.
>
> If you find that Mongrel stops working after a long idle time and you're
> using MySQL then you're hitting a bug in the MySQL driver that doesn't
> properly timeout connections. What happens is the MySQL server side of the
> connection times out and closes, but the MySQL client doesn't detect this
> and just sits there.
>
> What you have to do is set: ActiveRecord::Base.verification_timeout = 14400
>
>
> Or to any value that is lower than the MySQL server's interactive_timeout
> setting. This will make sure that ActiveRecord checks the connection often
> enough to reset the connection..Could anybody please tell me  in which  file
> I have to update this "ActiveRecord::Base.verification_timeout = 14400"
>

config/environment.rb will do

--
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From secrectcode at gmail.com  Sat May 12 13:33:51 2007
From: secrectcode at gmail.com (Guy Nick)
Date: Sun, 13 May 2007 01:33:51 +0800
Subject: [Mongrel] Mongrel + Rails keep connecting DB
Message-ID: <1fae7c930705121033v52b086cfm24994c8ac38c6529@mail.gmail.com>

Hi,

I use apache2 + mongrel_cluster + rails + mysql  to run my website.
When I read mysql log, I found that rails will connect to mysql every sql
command.
And the connection will not be closed after the sql command is done.
I guess the connection cache will not be retrieved somehow.

It will not happened when I use either webrick or lighttpd.
Any idea about this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070513/69078e4e/attachment.html 

From pete at nextengine.com  Mon May 14 17:40:12 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Mon, 14 May 2007 14:40:12 -0700
Subject: [Mongrel] Timeout message
Message-ID: <43D8DEE4-548B-4153-B22A-A660376DF677@nextengine.com>

Anybody seen this message before?  I see it over and over in one of  
my mongrel processes log files.  I've never seen it before today.

/usr/local/bin/mongrel_rails:16Mon May 14 20:44:30 +0000 2007: Error  
calling Dispatcher.dispatch #<Mongrel::TimeoutError: Mongrel timed  
out this thread: shutdown>Thread #<Thread:0x2ae6288dbc40 sleep> is  
too old, killing.

Thanks,
Pete

From nstlaurent at wantedtech.com  Tue May 15 09:27:25 2007
From: nstlaurent at wantedtech.com (Nicolas St-Laurent)
Date: Tue, 15 May 2007 09:27:25 -0400
Subject: [Mongrel] Timeout message
In-Reply-To: <43D8DEE4-548B-4153-B22A-A660376DF677@nextengine.com>
References: <43D8DEE4-548B-4153-B22A-A660376DF677@nextengine.com>
Message-ID: <D3AF054B-7351-40A0-B0C2-EA98D15849CE@wantedtech.com>


Le 07-05-14 ? 17:40, Pete DeLaurentis a ?crit :

> Anybody seen this message before?  I see it over and over in one of
> my mongrel processes log files.  I've never seen it before today.
>
> /usr/local/bin/mongrel_rails:16Mon May 14 20:44:30 +0000 2007: Error
> calling Dispatcher.dispatch #<Mongrel::TimeoutError: Mongrel timed
> out this thread: shutdown>Thread #<Thread:0x2ae6288dbc40 sleep> is
> too old, killing.
>
> Thanks,
> Pete
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

Hi Pete,

I've got the same issue here on one of my RoR application. I doesn't  
found the real cause nor the solution. Since this application makes  
complex  requests on big tables (>29M records), I guess that doesn't  
helps. For now, I restart mongrel servers each morning with a crontab  
(the timeout occurs after some running time) and timeout stop to occurs.

Nicolas



From john-subscribed at recaffeinated.com  Tue May 15 11:19:25 2007
From: john-subscribed at recaffeinated.com (John Lauck)
Date: Tue, 15 May 2007 11:19:25 -0400
Subject: [Mongrel] Timeout message
In-Reply-To: <43D8DEE4-548B-4153-B22A-A660376DF677@nextengine.com>
References: <43D8DEE4-548B-4153-B22A-A660376DF677@nextengine.com>
Message-ID: <b46641a0705150819u4e1345cep773e83469e0c3c3@mail.gmail.com>

Pete, i had a problem with mongrel sleeping and resulting in errors (I think
404).  It essentially made it look like the app wasn't running and then it
would (reluctantly) start  after a browser refresh.  I can't remember the
specific error.  Anyway, my solution was to create a script that polled my
rails apps every 15 minutes to an hour and kept them alive.

This might be something completely different, but it sounds somewhat
similar.

John

On 5/14/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>
> Anybody seen this message before?  I see it over and over in one of
> my mongrel processes log files.  I've never seen it before today.
>
> /usr/local/bin/mongrel_rails:16Mon May 14 20:44:30 +0000 2007: Error
> calling Dispatcher.dispatch #<Mongrel::TimeoutError: Mongrel timed
> out this thread: shutdown>Thread #<Thread:0x2ae6288dbc40 sleep> is
> too old, killing.
>
> Thanks,
> Pete
> _______________________________________________
> 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/20070515/9f3f74fb/attachment-0001.html 

From john-subscribed at recaffeinated.com  Tue May 15 11:28:50 2007
From: john-subscribed at recaffeinated.com (John Lauck)
Date: Tue, 15 May 2007 11:28:50 -0400
Subject: [Mongrel] AJAX File Uploads with Rails
Message-ID: <b46641a0705150828h5b48b160ybb06e778afc57143@mail.gmail.com>

Can someone clear up this issue with file uploads for me?  I have the code
from Mongrel Upload Progress (
http://mongrel.rubyforge.org/docs/upload_progress.html) running, but I'm a
little confused at how to integrate this into my app.  Should I roll the
controller methods in the controller I want to use or do you handle the file
uploads and then somehow push the rest of the form data to the other
controller?   Doing the first option sounds best, but then if there are
multiple views that need uploads, I would need to add more handlers to the
mongrel upload_progress conf file.

What's the best way to handle errors in this case?  Specifically, if there's
an error in the form, it would be much faster to find that error and send
back an error message, rather than waiting for files to upload then
processing the form.

Anyone have any ideas?


Thanks,

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

From todd.fisher at gmail.com  Tue May 15 13:10:28 2007
From: todd.fisher at gmail.com (Todd Fisher)
Date: Tue, 15 May 2007 13:10:28 -0400
Subject: [Mongrel] esi cache server built on mongrel
Message-ID: <e9a952090705151010w7f7d3090xd41cea305b9af97c@mail.gmail.com>

Hi all,

   I just wanted to share a project I've been working on now for a few
months.  It's still far from complete, but has already been very useful for
me and my coworkers.  I'm calling it mongrel-esi.  ESI stands for Edge Side
Include.  The specs live here, http://www.w3.org/TR/esi-lang.  I currently
only have support for <esi:include, <esi:try, <esi:attempt, and
<esi:except.    Also, it supports HTTP_COOKIES, so fragments can be
conditionally cached by a cookie.


I have implemented a few different parsers for ESI, one using hpricot to
process the whole document and another that uses Transfer-Encoding: chunked
to stream the fragments back to the browser as they are available.


I'm hoping this might be useful to others and am interested to get
feedback.
The project page is here => http://code.google.com/p/mongrel-esi/


Thanks,
Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070515/2e798ad8/attachment.html 

From zedshaw at zedshaw.com  Tue May 15 14:07:25 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 15 May 2007 14:07:25 -0400
Subject: [Mongrel] esi cache server built on mongrel
In-Reply-To: <e9a952090705151010w7f7d3090xd41cea305b9af97c@mail.gmail.com>
References: <e9a952090705151010w7f7d3090xd41cea305b9af97c@mail.gmail.com>
Message-ID: <20070515140725.d920ac61.zedshaw@zedshaw.com>

On Tue, 15 May 2007 13:10:28 -0400
"Todd Fisher" <todd.fisher at gmail.com> wrote:

> Hi all,
> 
>    I just wanted to share a project I've been working on now for a few
> months.  It's still far from complete, but has already been very useful for
> me and my coworkers.  I'm calling it mongrel-esi.  ESI stands for Edge Side
> Include.  The specs live here, http://www.w3.org/TR/esi-lang.  I currently
> only have support for <esi:include, <esi:try, <esi:attempt, and
> <esi:except.    Also, it supports HTTP_COOKIES, so fragments can be
> conditionally cached by a cookie.
> 
> 
> I have implemented a few different parsers for ESI, one using hpricot to
> process the whole document and another that uses Transfer-Encoding: chunked
> to stream the fragments back to the browser as they are available.
> 
> 
> I'm hoping this might be useful to others and am interested to get
> feedback.
> The project page is here => http://code.google.com/p/mongrel-esi/

That's really cool.  I'll check it out at railsconf if I'm not busy.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From Luke.Stark at mathworks.com  Wed May 16 09:02:44 2007
From: Luke.Stark at mathworks.com (Luke Stark)
Date: Wed, 16 May 2007 09:02:44 -0400
Subject: [Mongrel] Hit mongrel once...all is well,
	hit it again...stack level too deep?
Message-ID: <7224B63940F10F40A48AC423597ADE57133C03F0@MESSAGE-AH.ad.mathworks.com>

Hi there.

 

I've dropped a mongrel log item here:

 

http://pastie.caboo.se/62052

 

I can hit my app fine, once. Hitting it again gives me a 500 error and
this log entry. I think it's application code causing the problem as I
have a second app running that doesn't have this behavior, but I'm
unsure how to proceed finding root cause here.

 

Suggestions?

 

-L

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

From Luke.Stark at mathworks.com  Wed May 16 10:35:52 2007
From: Luke.Stark at mathworks.com (Luke Stark)
Date: Wed, 16 May 2007 10:35:52 -0400
Subject: [Mongrel] Ping. (Just testing.) - EOM.
Message-ID: <7224B63940F10F40A48AC423597ADE57133C074B@MESSAGE-AH.ad.mathworks.com>

 

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

From Luke.Stark at mathworks.com  Wed May 16 09:16:28 2007
From: Luke.Stark at mathworks.com (Luke Stark)
Date: Wed, 16 May 2007 09:16:28 -0400
Subject: [Mongrel] Hit mongrel once...all is well,
	hit it again...stack level too deep?
Message-ID: <7224B63940F10F40A48AC423597ADE57133C046A@MESSAGE-AH.ad.mathworks.com>

Is this related to the current stack size for the user mongrel is
running as?

 

Current stack is 10240k. fyi.

 

Any hints or page references are appreciated.

 

-L

 

________________________________

From: Luke Stark 
Sent: Wednesday, May 16, 2007 9:03 AM
To: 'mongrel-users at rubyforge.org'
Subject: Hit mongrel once...all is well, hit it again...stack level too
deep?

 

Hi there.

 

I've dropped a mongrel log item here:

 

http://pastie.caboo.se/62052

 

I can hit my app fine, once. Hitting it again gives me a 500 error and
this log entry. I think it's application code causing the problem as I
have a second app running that doesn't have this behavior, but I'm
unsure how to proceed finding root cause here.

 

Suggestions?

 

-L

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

From Luke.Stark at mathworks.com  Wed May 16 13:11:00 2007
From: Luke.Stark at mathworks.com (Luke Stark)
Date: Wed, 16 May 2007 13:11:00 -0400
Subject: [Mongrel] Hit mongrel once...all is well,
	hit it again...stack level too deep?
In-Reply-To: <7224B63940F10F40A48AC423597ADE57133C03F0@MESSAGE-AH.ad.mathworks.com>
Message-ID: <7224B63940F10F40A48AC423597ADE57133C0BAF@MESSAGE-AH.ad.mathworks.com>

Duh. Never mind...the user I was running as had an irbrc file that was
overriding Object. Gah!

 

-L

 

________________________________

From: mongrel-users-bounces at rubyforge.org
[mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Luke Stark
Sent: Wednesday, May 16, 2007 9:03 AM
To: mongrel-users at rubyforge.org
Subject: [Mongrel] Hit mongrel once...all is well,hit it again...stack
level too deep?

 

Hi there.

 

I've dropped a mongrel log item here:

 

http://pastie.caboo.se/62052

 

I can hit my app fine, once. Hitting it again gives me a 500 error and
this log entry. I think it's application code causing the problem as I
have a second app running that doesn't have this behavior, but I'm
unsure how to proceed finding root cause here.

 

Suggestions?

 

-L

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070516/594d8390/attachment-0001.html 

From john-subscribed at recaffeinated.com  Wed May 16 13:48:42 2007
From: john-subscribed at recaffeinated.com (John Lauck)
Date: Wed, 16 May 2007 13:48:42 -0400
Subject: [Mongrel] Rails, Mongrel and Rmagick
Message-ID: <b46641a0705161048k3d54ebbwb23642d1449644e9@mail.gmail.com>

i have a rails app with a form that allows uploading an image file.  I take
the image file and read it into rmagick to verify that it's an image.  For
some reason I can't catch an exception thrown by rmagick inside the app.
After an invalid image file is uploaded the process just hangs.  I have to
kill mongrel and restart to use the app again.

img = Magick::Image::read(@uploaded_file.path).first

This line above should throw a Magick::ImageMagickError exception.  I've
confirmed this with a simple ruby script.

I've tried adding breakpoints and as soon as this line is reached there's no
coming back, even the breakpointer hangs.

I pasted the method from my active record class here:
http://pastie.caboo.se/62122 .

Does anyone have any ideas?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070516/2c9c5cd6/attachment.html 

From john-subscribed at recaffeinated.com  Thu May 17 09:28:52 2007
From: john-subscribed at recaffeinated.com (John Lauck)
Date: Thu, 17 May 2007 09:28:52 -0400
Subject: [Mongrel] Rails, Mongrel and Rmagick
In-Reply-To: <b46641a0705161048k3d54ebbwb23642d1449644e9@mail.gmail.com>
References: <b46641a0705161048k3d54ebbwb23642d1449644e9@mail.gmail.com>
Message-ID: <b46641a0705170628s5ba2b56dv1dbbdf8ef22d9590@mail.gmail.com>

I figured out my problem here, but I don't think it explains the entire
issue.  The problem was that some files where not uploading as image files
and instead the @uploaded_file was a String.  If I check the class of the
file first I can work around the problem.  I still don't think it makes
sense that there are no exceptions thrown.

Here's a simplified look at the code in my rails model.

    if @uploaded_file.class == File || @uploaded_file.class == Tempfile
      begin
        img = Magick::Image::read(@uploaded_file.path).first
        self.data = @uploaded_file.read
        self.attributes = {:data_format => img.format, :height => img.rows,
:width => img.columns, :filesize => img.filesize}
        return true
      rescue
        # there was an error
      end
    end


On 5/16/07, John Lauck <john-subscribed at recaffeinated.com> wrote:
>
> i have a rails app with a form that allows uploading an image file.  I
> take the image file and read it into rmagick to verify that it's an image.
> For some reason I can't catch an exception thrown by rmagick inside the
> app.  After an invalid image file is uploaded the process just hangs.  I
> have to kill mongrel and restart to use the app again.
>
> img = Magick::Image::read(@uploaded_file.path).first
>
> This line above should throw a Magick::ImageMagickError exception.  I've
> confirmed this with a simple ruby script.
>
> I've tried adding breakpoints and as soon as this line is reached there's
> no coming back, even the breakpointer hangs.
>
> I pasted the method from my active record class here:
> http://pastie.caboo.se/62122 .
>
> Does anyone have any ideas?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070517/a9c0198c/attachment.html 

From craig at itpartners.co.nz  Thu May 17 23:25:15 2007
From: craig at itpartners.co.nz (Craig Box)
Date: Fri, 18 May 2007 15:25:15 +1200
Subject: [Mongrel] No return status from mongrel upload progress (and thus
	no updates on the bar)
Message-ID: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C3DEEB0@penfold.itpartners.co.nz>

Hi all,

I'm using Boxroom (http://boxroom.rubyforge.org/) and trying to get
upload progress working.  I've also been testing the sample code at
http://itblog.mcgeecorp.com/2007/5/15/mongrel-upload-progress-demo/.

I run a Mongrel cluster, and so am using drb (as per
http://mongrel.rubyforge.org/docs/upload_progress.html).  Starting up
rails, I get lots of useful-sounding output:

** Starting Mongrel listening at 0.0.0.0:3000
** Loading script/../config/../config/mongrel_upload_progress.conf
external config script

The bar doesn't draw updates - if I connect with irb (as per the
upload_progress page)

irb(main):001:0> uploads = get_status
=> #<DRb::DRbObject:0xb7d1ef04 @ref=nil, @uri="druby://0.0.0.0:2999">
irb(main):002:0> uploads.list
=> []

Nice regular output in my development.log:

Processing UploadsController#upload_progress (for 127.0.0.1 at
2007-05-18 15:20:29) [POST]
  Parameters: {"action"=>"upload_progress", "controller"=>"uploads",
"upload_id"=>"aff07334-04ee-11dc-bd4b-000d608392b8"}
Completed in 0.00966 (103 reqs/sec) | Rendering: 0.00848 (87%) | 200 OK
[http://localhost/uploads/upload_progress?upload_id=aff07334-04ee-11dc-b
d4b-000d608392b8]


Processing UploadsController#upload_progress (for 127.0.0.1 at
2007-05-18 15:21:11) [POST]
  Parameters: {"action"=>"upload_progress", "controller"=>"uploads",
"upload_id"=>"aff07334-04ee-11dc-bd4b-000d608392b8"}
Completed in 0.00909 (109 reqs/sec) | Rendering: 0.00800 (88%) | 200 OK
[http://localhost/uploads/upload_progress?upload_id=aff07334-04ee-11dc-b
d4b-000d608392b8]

status is always nil.  It sounds like exactly the same problem as this
person is having: http://www.ruby-forum.com/topic/102380


The entire setup is running on Ubuntu Dapper, with mongrel 1.0.1,
cluster/upload_progress 0.2.1, rails 1.2.3 and rubygems 0.9.3.

Any ideas?  Should I (as per
http://rubyforge.org/pipermail/mongrel-users/2006-November/002237.html)
look at running something other than Mongrel for accepting uploads?


Regards,
Craig


From john-subscribed at recaffeinated.com  Fri May 18 10:05:18 2007
From: john-subscribed at recaffeinated.com (John Lauck)
Date: Fri, 18 May 2007 10:05:18 -0400
Subject: [Mongrel] No return status from mongrel upload progress (and
	thus no updates on the bar)
In-Reply-To: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C3DEEB0@penfold.itpartners.co.nz>
References: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C3DEEB0@penfold.itpartners.co.nz>
Message-ID: <b46641a0705180705q1d5d3217r1dc092d4e4fc43ea@mail.gmail.com>

Craig,

I have no experience with Boxroom, but I did just recently get the Mongrel
Upload Progress working using the instructions on mongrel's site.

I'm developing locally on OS X, haven't tested moving it to my Cent OS
production environment yet.

Anyway, are you running the upload.rb mentioned on the site?  I forgot to
execute that script along with mongrel a couple times and couldn't figure
out what was wrong.  I also changed all the 0.0.0.0 IPs  serving drb to
127.0.0.1 and it worked at that point.  It was hard to gauge the upload
progress because I only tested it on my local LAN so all uploads were at
100% within a second.  However, it seemed to be working fine.


John

On 5/17/07, Craig Box <craig at itpartners.co.nz> wrote:
>
> Hi all,
>
> I'm using Boxroom (http://boxroom.rubyforge.org/) and trying to get
> upload progress working.  I've also been testing the sample code at
> http://itblog.mcgeecorp.com/2007/5/15/mongrel-upload-progress-demo/.
>
> I run a Mongrel cluster, and so am using drb (as per
> http://mongrel.rubyforge.org/docs/upload_progress.html).  Starting up
> rails, I get lots of useful-sounding output:
>
> ** Starting Mongrel listening at 0.0.0.0:3000
> ** Loading script/../config/../config/mongrel_upload_progress.conf
> external config script
>
> The bar doesn't draw updates - if I connect with irb (as per the
> upload_progress page)
>
> irb(main):001:0> uploads = get_status
> => #<DRb::DRbObject:0xb7d1ef04 @ref=nil, @uri="druby://0.0.0.0:2999">
> irb(main):002:0> uploads.list
> => []
>
> Nice regular output in my development.log:
>
> Processing UploadsController#upload_progress (for 127.0.0.1 at
> 2007-05-18 15:20:29) [POST]
>   Parameters: {"action"=>"upload_progress", "controller"=>"uploads",
> "upload_id"=>"aff07334-04ee-11dc-bd4b-000d608392b8"}
> Completed in 0.00966 (103 reqs/sec) | Rendering: 0.00848 (87%) | 200 OK
> [http://localhost/uploads/upload_progress?upload_id=aff07334-04ee-11dc-b
> d4b-000d608392b8]
>
>
> Processing UploadsController#upload_progress (for 127.0.0.1 at
> 2007-05-18 15:21:11) [POST]
>   Parameters: {"action"=>"upload_progress", "controller"=>"uploads",
> "upload_id"=>"aff07334-04ee-11dc-bd4b-000d608392b8"}
> Completed in 0.00909 (109 reqs/sec) | Rendering: 0.00800 (88%) | 200 OK
> [http://localhost/uploads/upload_progress?upload_id=aff07334-04ee-11dc-b
> d4b-000d608392b8]
>
> status is always nil.  It sounds like exactly the same problem as this
> person is having: http://www.ruby-forum.com/topic/102380
>
>
> The entire setup is running on Ubuntu Dapper, with mongrel 1.0.1,
> cluster/upload_progress 0.2.1, rails 1.2.3 and rubygems 0.9.3.
>
> Any ideas?  Should I (as per
> http://rubyforge.org/pipermail/mongrel-users/2006-November/002237.html)
> look at running something other than Mongrel for accepting uploads?
>
>
> Regards,
> Craig
>
> _______________________________________________
> 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/20070518/a1701614/attachment.html 

From luislavena at gmail.com  Sat May 19 16:05:40 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 19 May 2007 17:05:40 -0300
Subject: [Mongrel] Warning: mongrel_service and users of mysql
Message-ID: <71166b3b0705191305j343990ccp9411ba9c0bddd96b@mail.gmail.com>

Hello Mongrels,

I know I've been promising an update to mongrel_service, I'm working
on it, and will shine, I promise.

Anyway, for those using mongrel_service with MySQL, 5.x community
series, I must inform:

There is a bug report at mysql (#25621) [1] that describe the
situation with sleeping threads that didn't respond in timely fashion.

That bug causes mongrel_service to stop abnormally (premature
termination, broken pipe and other errors describing the same
situation.

As far mongrel and ruby code is involved, mongrel_service send the
right things to stop them, but mysql driver add delays and take longer
in release these locks, making the service fail.

Wanted to share this with the list, for those without luck that
couldn't get into RailsConf this year ;-)

Good weekend everybody.

[1] http://bugs.mysql.com/25621

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From andrew at andrewloe.com  Sat May 19 18:45:09 2007
From: andrew at andrewloe.com (W. Andrew Loe III)
Date: Sat, 19 May 2007 18:45:09 -0400
Subject: [Mongrel] 100% CPU
Message-ID: <9007bd350705191545x3dddc836o33a571b365c7ef32@mail.gmail.com>

I'm running Mephisto on two mongrels behind Apache 2.2. I'm getting HUGE
spikes to 100% of CPU on uncached (not served by Apache) requests. These
requests also take an exorbitant amount of time, ~20 seconds when my
production.log reports the database responding in > .2 seconds and the
render time is > .002 seconds. I have no idea where to start with debugging
this. I have two other rails apps that are extremely snappy. Could it be an
issue generating cached pages?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070519/258210de/attachment.html 

From craig at itpartners.co.nz  Sat May 19 20:30:40 2007
From: craig at itpartners.co.nz (Craig Box)
Date: Sun, 20 May 2007 12:30:40 +1200
Subject: [Mongrel] No return status from mongrel upload progress
	(andthus no updates on the bar)
References: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C3DEEB0@penfold.itpartners.co.nz>
	<b46641a0705180705q1d5d3217r1dc092d4e4fc43ea@mail.gmail.com>
Message-ID: <87ECFF3F9E2DBD4FBD1F74F9A80BBD1C360695@penfold.itpartners.co.nz>

> Anyway, are you running the upload.rb mentioned on the site?  I forgot to
> execute that script along with mongrel a couple times and couldn't figure
> out what was wrong.  I also changed all the 0.0.0.0 IPs  serving drb to
> 127.0.0.1 and it worked at that point.  It was hard to gauge the upload
> progress because I only tested it on my local LAN so all uploads were at
> 100% within a second.  However, it seemed to be working fine.

Yes, I am running all the right things, as far as I can tell.. a friend ran it on his machine and it all seemed to work for him.  There must be something subtle I'm missing.  Changing 0.0.0.0 to 127.0.0.1 didn't change anything.  (As an aside, if it matters, I'm starting mongrel on port 3000, and tunneling it to my web browser via SSH.)

I've just read through the thread at http://rubyforge.org/pipermail/mongrel-users/2007-February/003028.html - another similar problem.  Ultimately, a flash upload plugin would be the correct answer, but that will take a bit more time to implement (can anyone point me at a guide?) and the upload progress is the only part of the puzzle missing for me in the current version of the code.

Regards
Craig
-------------- next part --------------
A non-text attachmen