From lists at ruby-forum.com Fri Jan 2 17:20:54 2009 From: lists at ruby-forum.com (Andi Geheim) Date: Fri, 2 Jan 2009 23:20:54 +0100 Subject: [Mongrel] mongrel_rails cluster::stop not working In-Reply-To: <4067fba3311b88a080150e7cad481170@ruby-forum.com> References: <05e318561b3dc617b7e8cab6d20d40e7@ruby-forum.com> <48513B54.1050403@jhu.edu> <4067fba3311b88a080150e7cad481170@ruby-forum.com> Message-ID: I have the same problem: andreasP:/var/www/web1/bla# mongrel_rails cluster::start starting port 3000 andreasP:/var/www/web1/bla# mongrel_rails cluster::stop already stopped port 3000 And no pid file will be created after starting the mongrel. log_file: log/mongrel.log port: "3000" cwd: /var/www/web1/bla environment: production pid_file: tmp/pids/mongrel.pid address: xxx.xxx.xxx.xxx (the server ip) servers: 1 rails -v Rails 2.2.2 ruby -v ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux] ** Daemonized, any open files are closed. Look at tmp/pids/mongrel.3000.pid and log/mongrel.3000.log for info. ** Starting Mongrel listening at xxx.xxx.xxx.xxx:3000 ** Starting Rails with production environment... /usr/local/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/initializer.rb:530:in `send': undefined method `cache_template_loading=' for ActionView::Base:Class (NoMethodError) from /usr/local/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/initializer.rb:530:in `initialize_framework_settings' from /usr/local/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/initializer.rb:529:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/initializer.rb:529:in `initialize_framework_settings' from /usr/local/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/initializer.rb:526:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/initializer.rb:526:in `initialize_framework_settings' from /usr/local/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/initializer.rb:154:in `process' from /usr/local/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/initializer.rb:112:in `send' from /usr/local/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/initializer.rb:112:in `run' from /var/www/web1/aekschen/config/environment.rb:13 from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/rails.rb:147:in `rails' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:113:in `cloaker_' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:149:in `call' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:149:in `listener' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:99:in `cloaker_' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:50:in `call' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:50:in `initialize' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:84:in `new' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:84:in `run' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in `run' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 from /usr/local/bin/mongrel_rails:19:in `load' from /usr/local/bin/mongrel_rails:19 I dont know whats wrong! Greetings Chaos -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Wed Jan 7 14:44:45 2009 From: lists at ruby-forum.com (Robbie Allen) Date: Wed, 7 Jan 2009 20:44:45 +0100 Subject: [Mongrel] HTTP parse error due to an extra percent sign Message-ID: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> If you append an extra percent sign to a URL that gets passed to mongrel, it will return a Bad Request error. Kind of odd that "http://localhost/%" causes a "Bad Request" instead of a "Not Found" error. Here is the error from the mongrel log: HTTP parse error, malformed request (127.0.0.1): # I'm using Nginx in front of mongrel. I understand this is a bad URL, but is there anyway to have mongrel ignore lone percent signs? Or perhaps a Nginx rewrite rule that will encode extraneous percent signs? -- Posted via http://www.ruby-forum.com/. From stephanwehner at gmail.com Wed Jan 7 15:00:14 2009 From: stephanwehner at gmail.com (Stephan Wehner) Date: Wed, 7 Jan 2009 12:00:14 -0800 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> Message-ID: On Wed, Jan 7, 2009 at 11:44 AM, Robbie Allen wrote: > If you append an extra percent sign to a URL that gets passed to > mongrel, it will return a Bad Request error. Kind of odd that > "http://localhost/%" causes a "Bad Request" instead of a "Not Found" > error. > > Here is the error from the mongrel log: > HTTP parse error, malformed request (127.0.0.1): > # > > I'm using Nginx in front of mongrel. I understand this is a bad URL, > but is there anyway to have mongrel ignore lone percent signs? Or > perhaps a Nginx rewrite rule that will encode extraneous percent signs? Out of curiousity, why does mongrel's handling of this case bother you? Looks like entirely standard behaviour, see http://groklaw.net/% http://slashdot.org/% http://w3c.org/% (All produce status 400) Stephan > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Stephan Wehner -> http://stephan.sugarmotor.org -> http://www.thrackle.org -> http://www.buckmaster.ca -> http://www.trafficlife.com -> http://stephansmap.org -- blog.stephansmap.org From rochkind at jhu.edu Wed Jan 7 15:06:03 2009 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Wed, 07 Jan 2009 15:06:03 -0500 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> Message-ID: <49650B2B.3050803@jhu.edu> Yes. I have run into this before. Mongrel will error on an invalid HTTP URI, with one common case being characters not properly escaped, which is what your example is. When one of the developers of my app brought this up before, he was told by the Mongrel developer that this was intentional, and would not be changed. I didn't like this then, and I don't like it now, for a variety of reasons, including that my app needs to respond to URLs sent by third parties that are not under my control. Perhaps the current mongrel developers (IS there even any active development on mongrel?) have a different opinion, and this could be changed, or made configurable. In the meantime, I have gotten around it with some mod_rewrite rules in apache on top of mongrel, to take illegal URLs and escape/rewrite them to be legal. Except due to some weird (bugs?) in apache and mod_rewrite around escaping and difficulty of controlling escaping in the apache conf, I actually had to use an external perl file too. Here's what I do: Apache conf, applying to mongrel urls (which in my setup are all urls on a given apache virtual host) RewriteEngine on RewriteMap query_escape prg:/data/web/findit/Umlaut/distribution/script/rewrite_map.pl #RewriteLock /var/lock/subsys/apache.rewrite.lock RewriteCond %{query_string} ^(.*[\>\<].*)$ RewriteRule ^(.*)$ $1?${query_escape:%1} [R,L,NE] The rewrite_map.pl file: #!/usr/bin/perl $| = 1; # Turn off buffering while () { s/>/%3E/g; s/ If you append an extra percent sign to a URL that gets passed to > mongrel, it will return a Bad Request error. Kind of odd that > "http://localhost/%" causes a "Bad Request" instead of a "Not Found" > error. > > Here is the error from the mongrel log: > HTTP parse error, malformed request (127.0.0.1): > # > > I'm using Nginx in front of mongrel. I understand this is a bad URL, > but is there anyway to have mongrel ignore lone percent signs? Or > perhaps a Nginx rewrite rule that will encode extraneous percent signs? > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu From lists at ruby-forum.com Wed Jan 7 15:28:42 2009 From: lists at ruby-forum.com (Robbie Allen) Date: Wed, 7 Jan 2009 21:28:42 +0100 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> Message-ID: <4478b70ce652e196d26c1f56411b88c6@ruby-forum.com> So how do you catch it? All of those errors are not very friendly and completely bypass the site look and feel. See these: http://www.google.com/% http://www.yahoo.com/% Robbie Stephan Wehner wrote: > On Wed, Jan 7, 2009 at 11:44 AM, Robbie Allen > wrote: >> but is there anyway to have mongrel ignore lone percent signs? Or >> perhaps a Nginx rewrite rule that will encode extraneous percent signs? > > Out of curiousity, why does mongrel's handling of this case bother you? > Looks like entirely standard behaviour, see > > http://groklaw.net/% > http://slashdot.org/% > http://w3c.org/% > > (All produce status 400) > > > Stephan -- Posted via http://www.ruby-forum.com/. From stephanwehner at gmail.com Wed Jan 7 16:09:02 2009 From: stephanwehner at gmail.com (Stephan Wehner) Date: Wed, 7 Jan 2009 13:09:02 -0800 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: <49650B2B.3050803@jhu.edu> References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> <49650B2B.3050803@jhu.edu> Message-ID: On Wed, Jan 7, 2009 at 12:06 PM, Jonathan Rochkind wrote: > Yes. I have run into this before. Mongrel will error on an invalid HTTP URI, > with one common case being characters not properly escaped, which is what > your example is. When one of the developers of my app brought this up > before, he was told by the Mongrel developer that this was intentional, and > would not be changed. > > I didn't like this then, and I don't like it now, for a variety of reasons, > including that my app needs to respond to URLs sent by third parties that > are not under my control. Perhaps the current mongrel developers (IS there > even any active development on mongrel?) have a different opinion, and this > could be changed, or made configurable. > > In the meantime, I have gotten around it with some mod_rewrite rules in > apache on top of mongrel, to take illegal URLs and escape/rewrite them to be > legal. Except due to some weird (bugs?) in apache and mod_rewrite around > escaping and difficulty of controlling escaping in the apache conf, I > actually had to use an external perl file too. Here's what I do: > > Apache conf, applying to mongrel urls (which in my setup are all urls on a > given apache virtual host) > > RewriteEngine on > RewriteMap query_escape > prg:/data/web/findit/Umlaut/distribution/script/rewrite_map.pl > #RewriteLock /var/lock/subsys/apache.rewrite.lock > RewriteCond %{query_string} ^(.*[\>\<].*)$ > RewriteRule ^(.*)$ $1?${query_escape:%1} [R,L,NE] > > The rewrite_map.pl file: > > #!/usr/bin/perl > $| = 1; # Turn off buffering > while () { > > s/>/%3E/g; > s/ s/\//%2F/g; > s/\\/%5C/g; > s/ /\+/g; > print $_; > } > ## It strikes me as a good thing that Apache weeds out bad URL's. Less parsing for mongrel, less work, and one less point of failure to worry about. (When I see code like above after "Turn off buffering" - with all respect - I get worried.) On the other hand, does Apache not allow configuring the page returned for 400 Bad Request. This would then also allow addressing the issue that "All of those errors are not very friendly and completely bypass the site look and feel." ("Robbie") Stephan > Looks like I'm not actually escaping bare '%' chars, since i hadn't run into > those before in the URLs I need to handle. It would be trickier to add a > regexp for that, since you need to distinguish an improper % from an % > that's actually part of an entity reference. Maybe something like: > > s/%([^A-F0-9]|$)([^A-F0-9]|$)/%25/g; > > '/%25' would be a valid URI path representing the % char. '/%' is not. > > Hope this helps, > > Jonathan > > > Robbie Allen wrote: >> >> If you append an extra percent sign to a URL that gets passed to >> mongrel, it will return a Bad Request error. Kind of odd that >> "http://localhost/%" causes a "Bad Request" instead of a "Not Found" >> error. >> >> Here is the error from the mongrel log: >> HTTP parse error, malformed request (127.0.0.1): >> # >> >> I'm using Nginx in front of mongrel. I understand this is a bad URL, >> but is there anyway to have mongrel ignore lone percent signs? Or >> perhaps a Nginx rewrite rule that will encode extraneous percent signs? >> > > -- > Jonathan Rochkind > Digital Services Software Engineer > The Sheridan Libraries > Johns Hopkins University > 410.516.8886 rochkind (at) jhu.edu > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Stephan Wehner -> http://stephan.sugarmotor.org -> http://www.thrackle.org -> http://www.buckmaster.ca -> http://www.trafficlife.com -> http://stephansmap.org -- blog.stephansmap.org From lists at ruby-forum.com Wed Jan 7 16:25:29 2009 From: lists at ruby-forum.com (Robbie Allen) Date: Wed, 7 Jan 2009 22:25:29 +0100 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> <49650B2B.3050803@jhu.edu> Message-ID: > On the other hand, does Apache not allow configuring the page returned > for 400 Bad Request. This would > then also allow addressing the issue that I'm using Nginx and it does allow you to set error_pages, but that doesn't seem to work in this case (at least for me). Has anyone got it to work so Nginx will use an actual error page instead of the default when encountering a Bad Request? Robbie -- Posted via http://www.ruby-forum.com/. From wyhaines at gmail.com Wed Jan 7 16:33:39 2009 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 7 Jan 2009 14:33:39 -0700 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: <49650B2B.3050803@jhu.edu> References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> <49650B2B.3050803@jhu.edu> Message-ID: On 1/7/09, Jonathan Rochkind wrote: > Yes. I have run into this before. Mongrel will error on an invalid HTTP URI, > with one common case being characters not properly escaped, which is what > your example is. When one of the developers of my app brought this up > before, he was told by the Mongrel developer that this was intentional, and > would not be changed. Mongrel's HTTP parser grammar was written by Zed to be very RFC conformant. > I didn't like this then, and I don't like it now, for a variety of reasons, > including that my app needs to respond to URLs sent by third parties that > are not under my control. Perhaps the current mongrel developers (IS there > even any active development on mongrel?) have a different opinion, and this > could be changed, or made configurable. The mongrel HTTP parser is very stable, and is in use by multiple projects. I can't speak for the other mongrel devs, but if it were up to me alone, I'd keep mongrel's HTTP parser RFC compliant. Since you have a special case, I would suggest that you just take a look at the grammar for the parser and consider compiling your own parser. You could probably just remove '%' from the unsafe type, and see if that will work for you: It looks like this: unsafe = (CTL | " " | "\"" | "#" | "%" | "<" | ">"); Kirk Haines From rochkind at jhu.edu Wed Jan 7 16:38:20 2009 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Wed, 07 Jan 2009 16:38:20 -0500 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> <49650B2B.3050803@jhu.edu> Message-ID: <496520CC.3050905@jhu.edu> Stephan Wehner wrote: > > It strikes me as a good thing that Apache weeds out bad URL's. Less > parsing for mongrel, less work, and one less point of failure to worry > about. (When I see code like above after "Turn off buffering" - with > all respect - I get worried.) > Um, that code that worries you is the code that was neccesary to get Apache to 'fix' these bad URLs to be good URLs. If you have a better way to do it, let me know and I'm happy to use it! That actually took me several solid days of work to get that far, because Apache is _weird_ when it comes to escaping and mod_rewrite. Without using the external perl rewrite map, I could only get it to end up double-escaped or not properly escaped at all, I could NOT get mod_rewrite alone withotu perl to rewrite > to %3E etc all by itself. I kept ending up with things like %253E instead, because Apache would go ahead and apply another escaping when I didn't want it to. I could get apache to do no escaping, or double escaping, but couldn't get it to do the kind of escaping I needed---until I figured out I had to resort to an external perl rewrite map. Which yes, resulted in code that I don't like that much either, but it was all I could come up with to figure out a solution to my unavoidable business problem. So you like solving it in Apache rather than Mongrel, but don't like the best way I came up with to solve it in Apache after nearly a week of hacking? Heh, I'm not sure what you're suggesting. Now that I've got it done, it works, but it was kind of a frustrating four days of work hacking mod_rewrite and apache conf when that's not what I wanted to be doing. Oddly, I could find hardly anyone Googling who had to deal with this problem before. I guess the circumstance of having to deal with long complicated possibly ill-formed query strings sent by third parties is rare. And having to deal with it at the Apache layer is not the choice anyone else made, when they did have to deal with it. (In general, doing complicated things in apache conf reminds me of trying to do complicated things in sendmail. It gets unpredictable and turns into 'twist this knob and see what happens' pretty quick. I'd much rather be writing ruby than hacking apache confs.) Jonathan > On the other hand, does Apache not allow configuring the page returned > for 400 Bad Request. This would > then also allow addressing the issue that > > "All of those errors are not very friendly and completely bypass the > site look and feel." ("Robbie") > > Stephan > > >> Looks like I'm not actually escaping bare '%' chars, since i hadn't run into >> those before in the URLs I need to handle. It would be trickier to add a >> regexp for that, since you need to distinguish an improper % from an % >> that's actually part of an entity reference. Maybe something like: >> >> s/%([^A-F0-9]|$)([^A-F0-9]|$)/%25/g; >> >> '/%25' would be a valid URI path representing the % char. '/%' is not. >> >> Hope this helps, >> >> Jonathan >> >> >> Robbie Allen wrote: >> >>> If you append an extra percent sign to a URL that gets passed to >>> mongrel, it will return a Bad Request error. Kind of odd that >>> "http://localhost/%" causes a "Bad Request" instead of a "Not Found" >>> error. >>> >>> Here is the error from the mongrel log: >>> HTTP parse error, malformed request (127.0.0.1): >>> # >>> >>> I'm using Nginx in front of mongrel. I understand this is a bad URL, >>> but is there anyway to have mongrel ignore lone percent signs? Or >>> perhaps a Nginx rewrite rule that will encode extraneous percent signs? >>> >>> >> -- >> Jonathan Rochkind >> Digital Services Software Engineer >> The Sheridan Libraries >> Johns Hopkins University >> 410.516.8886 rochkind (at) jhu.edu >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> >> > > > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu From toolbag at gmail.com Wed Jan 7 17:09:47 2009 From: toolbag at gmail.com (Cody Caughlan) Date: Wed, 7 Jan 2009 14:09:47 -0800 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> <49650B2B.3050803@jhu.edu> Message-ID: <749ead610901071409y5e3c89efrd232bc0dc1a8869f@mail.gmail.com> > Has anyone got it to work so Nginx will use an actual error page instead > of the default when encountering a Bad Request? This is pretty easy to do, just use the "error_page" directive and list all of the ones you want to capture and then specify it to use your 500 page, e.g. we capture all 5xx errors using these nginx config rules: error_page 500 502 503 504 /500.html; location = /500.html { root /u/apps/project/public; } Just add 400 to the list of 5xx errors. You will also want to have a "500.html" in your document root or modify the path to the file accordingly. /Cody On Wed, Jan 7, 2009 at 1:25 PM, Robbie Allen wrote: >> On the other hand, does Apache not allow configuring the page returned >> for 400 Bad Request. This would >> then also allow addressing the issue that > > I'm using Nginx and it does allow you to set error_pages, but that > doesn't seem to work in this case (at least for me). > > Has anyone got it to work so Nginx will use an actual error page instead > of the default when encountering a Bad Request? > > Robbie > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From rochkind at jhu.edu Wed Jan 7 16:31:50 2009 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Wed, 07 Jan 2009 16:31:50 -0500 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> Message-ID: <49651F46.2010500@jhu.edu> This particular case actually doesn't bother me in particular. It may be fine for "/%" to be a 400 rather than a 404. My particular case involved needing to process mal-formed query strings sent by third parties. I had no control over these third parties. I _needed_ to be able to process query strings that included un-escaped ampersands and such. Yes, the third party sending me this information in a query string was doing it in a way that was illegal and violated standards, but they are more powerful than I, and I can not make them change their behavior, and I need to handle those URLs anyway. I took care of it with a rewrite on the apache end before it reached mongrel though. This ended up being somewhat more complicated then I hoped it would be becuase of Apache's weird and unpredictable behavior when it came to escaping, but now that I have it working, it works out. Jonathan Stephan Wehner wrote: > On Wed, Jan 7, 2009 at 11:44 AM, Robbie Allen wrote: > >> If you append an extra percent sign to a URL that gets passed to >> mongrel, it will return a Bad Request error. Kind of odd that >> "http://localhost/%" causes a "Bad Request" instead of a "Not Found" >> error. >> >> Here is the error from the mongrel log: >> HTTP parse error, malformed request (127.0.0.1): >> # >> >> I'm using Nginx in front of mongrel. I understand this is a bad URL, >> but is there anyway to have mongrel ignore lone percent signs? Or >> perhaps a Nginx rewrite rule that will encode extraneous percent signs? >> > > Out of curiousity, why does mongrel's handling of this case bother you? > Looks like entirely standard behaviour, see > > http://groklaw.net/% > http://slashdot.org/% > http://w3c.org/% > > (All produce status 400) > > > Stephan > > >> Posted via http://www.ruby-forum.com/. >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> >> > > > > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu From jftucker at gmail.com Wed Jan 7 19:39:58 2009 From: jftucker at gmail.com (James Tucker) Date: Thu, 8 Jan 2009 00:39:58 +0000 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: <49651F46.2010500@jhu.edu> References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> <49651F46.2010500@jhu.edu> Message-ID: <3C93AEEC-018D-4925-9D6E-03ECAF5CFA6D@gmail.com> On 7 Jan 2009, at 21:31, Jonathan Rochkind wrote: > Yes, the third party sending me this information in a query string > was doing it in a way that was illegal and violated standards, but > they are more powerful than I, and I can not make them change their > behavior, and I need to handle those URLs anyway. This is a sad day, they won. Next time, scream from the rooftops, unless you already signed your free speech away, that is. Printing an RFC and highlighting the relevant clauses and handing that to a level higher than disgruntled developers is often relatively effective too. From lists at ruby-forum.com Thu Jan 8 08:17:11 2009 From: lists at ruby-forum.com (Sathish Sundaram) Date: Thu, 8 Jan 2009 14:17:11 +0100 Subject: [Mongrel] MONGREL HANDLER Message-ID: <27c5f4a1bcf354b0418c3a829ff6555f@ruby-forum.com> When i try to get the remote address of the system ,its returning only the proxy server ip or localhost ip address.But i need the service provider ip address of the system.Is there is any http header variables,because i used (['REMOTE_ADDR'] ,['SERVER_NAME'],['REMOTE_HOST'],['SERVER_PORT'],['HTTP_HOST']) nothing works for me . I need the solution for this can you please suggest with me the solution. thanks, -- Posted via http://www.ruby-forum.com/. From piyush.pr at gmail.com Thu Jan 8 09:42:33 2009 From: piyush.pr at gmail.com (Piyush Ranjan) Date: Thu, 8 Jan 2009 20:12:33 +0530 Subject: [Mongrel] MONGREL HANDLER In-Reply-To: <27c5f4a1bcf354b0418c3a829ff6555f@ruby-forum.com> References: <27c5f4a1bcf354b0418c3a829ff6555f@ruby-forum.com> Message-ID: <325148f70901080642y2e48d4fo42bced23af8abda3@mail.gmail.com> You will not get these things from any of those variables. If you are using Apache look for "set X-FORWARDED-FOR". In fact X-FF can be used to get ip address for many http servers. More info at http://en.wikipedia.org/wiki/X-Forwarded-For On Thu, Jan 8, 2009 at 6:47 PM, Sathish Sundaram wrote: > When i try to get the remote address of the system ,its returning only > the proxy server ip or localhost ip address.But i need the service > provider ip address of the system.Is there is any http header > variables,because i used (['REMOTE_ADDR'] > ,['SERVER_NAME'],['REMOTE_HOST'],['SERVER_PORT'],['HTTP_HOST']) nothing > works for me . I need the solution for this can you please suggest with > me the solution. > > thanks, > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rochkind at jhu.edu Thu Jan 8 12:51:03 2009 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Thu, 08 Jan 2009 12:51:03 -0500 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: <3C93AEEC-018D-4925-9D6E-03ECAF5CFA6D@gmail.com> References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> <49651F46.2010500@jhu.edu> <3C93AEEC-018D-4925-9D6E-03ECAF5CFA6D@gmail.com> Message-ID: <49663D07.5080405@jhu.edu> I can scream to the rooftops all I want. This particular product I am working on is an OpenURL Resolver that handles OpenURLs representing scholarly citations sent from third-party licensed search providers that the library (where I work) pays for. We have contracts with literally hundreds of such providers. This one provider in particular that sends the bad URL is a particular large company (EBSCO), with billions of dollars in revenue, and thousands of customers of which we are just one. Most of their other customers are not using mongrel-fronted (or Rails at all) solutions for OpenURL link resolving; the solutions they are using manage to deal with the faulty URLs. Now ours does too, with some ugly apache/perl hacking in front of mongrel. I complained both privately and publically about this. But the world is not always as we would like it, and sometimes our software needs to deal with incoming data that is not standards compliant, just the way it is. Jonathan James Tucker wrote: > > On 7 Jan 2009, at 21:31, Jonathan Rochkind wrote: > >> Yes, the third party sending me this information in a query string >> was doing it in a way that was illegal and violated standards, but >> they are more powerful than I, and I can not make them change their >> behavior, and I need to handle those URLs anyway. > > This is a sad day, they won. > > Next time, scream from the rooftops, unless you already signed your > free speech away, that is. > > Printing an RFC and highlighting the relevant clauses and handing that > to a level higher than disgruntled developers is often relatively > effective too. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu From rochkind at jhu.edu Thu Jan 8 12:53:54 2009 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Thu, 08 Jan 2009 12:53:54 -0500 Subject: [Mongrel] MONGREL HANDLER In-Reply-To: <325148f70901080642y2e48d4fo42bced23af8abda3@mail.gmail.com> References: <27c5f4a1bcf354b0418c3a829ff6555f@ruby-forum.com> <325148f70901080642y2e48d4fo42bced23af8abda3@mail.gmail.com> Message-ID: <49663DB2.4060905@jhu.edu> Hmm, I've never had this problem with a Mongrel in front of Rails via Apache, using the standard Apache mod_proxy reverse proxy setup for apache and mongrel. My guess is that that mod_proxy in apache will automatically set X-FORWARDED-FOR without the need for any special setup beyond the reverse proxy setup; and that Rails will also automatically use that x-ff header. But I've never looked into it, because I didn't need, it just worked. If you are not using apache and/or not using Rails, your mileage may very. What is your environment? Jonathan Piyush Ranjan wrote: > You will not get these things from any of those variables. If you are using > Apache look for "set X-FORWARDED-FOR". In fact X-FF can be used to get ip > address for many http servers. More info at > http://en.wikipedia.org/wiki/X-Forwarded-For > > > On Thu, Jan 8, 2009 at 6:47 PM, Sathish Sundaram wrote: > > >> When i try to get the remote address of the system ,its returning only >> the proxy server ip or localhost ip address.But i need the service >> provider ip address of the system.Is there is any http header >> variables,because i used (['REMOTE_ADDR'] >> ,['SERVER_NAME'],['REMOTE_HOST'],['SERVER_PORT'],['HTTP_HOST']) nothing >> works for me . I need the solution for this can you please suggest with >> me the solution. >> >> thanks, >> -- >> Posted via http://www.ruby-forum.com/. >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu From david at vrensk.com Thu Jan 8 14:03:03 2009 From: david at vrensk.com (David Vrensk) Date: Thu, 8 Jan 2009 20:03:03 +0100 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: <49663D07.5080405@jhu.edu> References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> <49651F46.2010500@jhu.edu> <3C93AEEC-018D-4925-9D6E-03ECAF5CFA6D@gmail.com> <49663D07.5080405@jhu.edu> Message-ID: <81b453920901081103v1ac26708tb89f99582f1e38b4@mail.gmail.com> On Thu, Jan 8, 2009 at 18:51, Jonathan Rochkind wrote: > I can scream to the rooftops all I want. [...] > > I complained both privately and publically about this. But the world is not > always as we would like it, and sometimes our software needs to deal with > incoming data that is not standards compliant, just the way it is. > Absolutely true. And I think the solution you devised is a good one: take a piece of software that (for reasons unknown to me) accepts malformed input, have it clean up the input and pass it on. No reason to disable checks in a tool that actually does what it should. Out of curiosity: what did this company respond when you asked them to provide protocol-compliant data? I'd like to think that they at least apologised profusely for being unable to keep the tubes clean, as it were, instead of saying "standards shmandards". BR, /David -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ruby-forum.com Fri Jan 9 02:36:33 2009 From: lists at ruby-forum.com (Erik Berg) Date: Fri, 9 Jan 2009 08:36:33 +0100 Subject: [Mongrel] Serve files by alias Message-ID: <15dd8e1727505b252bb56187ffe5a041@ruby-forum.com> Hi there. I'd like to serve a bunch of files stored in the filesystem. Unlike serving them directly by their name, I would like to have them served by ID, e.g. like http://example.com/file/1337 serves /u01/media/some.ogm http://example.com/file/2342 serves /u01/media/other.ogm Further I need to add (and eventually modify) headers in the response created by the webserver. I choosed to do realize it with mongrel, because webrick is told to be slow serving big files. I choosed not to use e.g. nginx directly, because the application should be easily deployable on different platforms where ruby is available, without compiling needed and spending much time getting it work in some special platform. Now to my problem... :) I wasn't able to figure out, how to "link" static files into the webspace, like the Alias directive of apache e.g.. The idea was that mongrel should serve e.g. /u01/media/some.ogm if /file/1337 is requested and the header modification would be done by a handler hooked onto /file. Is that possible, or have I read to and send the files on my own by a servlet? I'd be very happy for comments, tips or sample code regarding this topic. Thanks in advance! Erik. PS: It's a pity that you blacklist posting from Tor nodes. I understand that some people could abuse it for spamming, but please also think about that not everybody has the luxury to use the internet unanonymously without beeing afraid, for whatever reasons. It took my ages to send this post to your site, chaining tor with other proxy. -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Fri Jan 9 04:47:51 2009 From: lists at ruby-forum.com (Sathish Sundaram) Date: Fri, 9 Jan 2009 10:47:51 +0100 Subject: [Mongrel] Cannot get HTTP HEADERS in Mongrel Handler with Nginx Message-ID: Hi, I am reposting this question because I think that I may have not been clear with the earlier question I am using nginx as a reverse proxy sending the requests to mongrel_handler This handler is not able to receive any HTTP HEADER variables Here is a dump ---- HTTP_VIA nil HTTP_ACCEPT_ENCODING nil HTTP_USER_AGENT nil SCRIPT_NAME nil SERVER_PROTOCOL nil HTTP_CACHE_CONTROL nil HTTP_ACCEPT_LANGUAGE nil HTTP_HOST nil REMOTE_ADDR nil SERVER_SOFTWARE nil REQUEST_PATH nil HTTP_COOKIE nil HTTP_ACCEPT_CHARSET nil HTTP_VERSION nil REQUEST_URI nil SERVER_PORT nil GATEWAY_INTERFACE nil QUERY_STRING nil HTTP_ACCEPT nil HTTP_X_FORWARDED_FOR nil HTTP_CONNECTION nil HTTP_X_REAL_IP nil REQUEST_METHOD nil ---- My nginx config is fine, my access log is dumping those variables and a rails application is able to receive them whereas mongrel_handler cannot Can someone suggest what is the issue?. Thanks in advance -- -- Posted via http://www.ruby-forum.com/. From jftucker at gmail.com Fri Jan 9 07:29:59 2009 From: jftucker at gmail.com (James Tucker) Date: Fri, 9 Jan 2009 12:29:59 +0000 Subject: [Mongrel] HTTP parse error due to an extra percent sign In-Reply-To: <49663D07.5080405@jhu.edu> References: <548a5e1d62235689ad9ab41308d0eb88@ruby-forum.com> <49651F46.2010500@jhu.edu> <3C93AEEC-018D-4925-9D6E-03ECAF5CFA6D@gmail.com> <49663D07.5080405@jhu.edu> Message-ID: <1029470F-6C91-4955-A0A9-867BBAA865FA@gmail.com> On 8 Jan 2009, at 17:51, Jonathan Rochkind wrote: > We have contracts with literally hundreds of such providers. Most of which do the right thing. > This one provider in particular that sends the bad URL is a > particular large company (EBSCO), with billions of dollars in > revenue, and thousands of customers of which we are just one. It should generally take one, or a handful of lines of code to properly escape urls. It sounds like they can definitely afford to do this. > Most of their other customers are not using mongrel-fronted (or > Rails at all) solutions for OpenURL link resolving; the solutions > they are using manage to deal with the faulty URLs. There are plenty of stories of how mongrels conformance to the RFC has raised similar concerns. Indeed this happened with Google too. Some of the stories can be found on Zeds blog. AFAIK, Google fixed their stuff. > Now ours does too, with some ugly apache/perl hacking in front of > mongrel. As David said, your solution is a valid one. Changing mongrel is not. > I complained both privately and publically about this. But the world > is not always as we would like it, and sometimes our software needs > to deal with incoming data that is not standards compliant, just the > way it is. Understood, nonetheless, you should keep trying, as we all should, to improve this world. From lists at ruby-forum.com Sat Jan 10 22:52:00 2009 From: lists at ruby-forum.com (Chris Markle) Date: Sun, 11 Jan 2009 04:52:00 +0100 Subject: [Mongrel] "service mongrel_cluster start" startup fails In-Reply-To: <81b453920812141547i17ce9dbbl19a37528034929d@mail.gmail.com> References: <84fd6e976c4d045b76b9601ec79b291d@ruby-forum.com> <81b453920809150501t68f85760i759009ba2751b795@mail.gmail.com> <82a18437e66d13591a496769254211d2@ruby-forum.com> <81b453920812141547i17ce9dbbl19a37528034929d@mail.gmail.com> Message-ID: <991b9f92b784df7171b6206fd5a73b8e@ruby-forum.com> All, > /usr/bin/mongrel_cluster_ctl:9:in `require': no such file to load -- > [...] I have tried adding /usr/local/bin to the path; didn't work A similar thing happened to me when I was testing a Ruby-based startup (/etc/init.d) script and was getting failures on my "load" command (similar symptoms to David's failure on "require". I looked at the failure using strace and noticed that the final library lookup for say xxx.rb would be ./xxx.rb. This made me wonder what the current working directory was and it seems that scripts started with /sbin/service are started in the directory "/". So unless your loaded or required script is in "/" it will fail. Here is what the contents of var $: look like on my machine that seem to confirm this (this is the load order): /usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby/1.8/i386-linux /usr/lib/ruby/site_ruby /usr/lib/site_ruby/1.8 /usr/lib/site_ruby/1.8/i386-linux /usr/lib/site_ruby /usr/lib/ruby/1.8 /usr/lib/ruby/1.8/i386-linux . Notice that "." (current dir is the last one). I tried adding /etc/init.d (where my other scripts were for startup) using: $:.unshift("/etc/init.d") to dynamically change the search order and ended up with this, which worked: /etc/init.d /usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby/1.8/i386-linux /usr/lib/ruby/site_ruby /usr/lib/site_ruby/1.8 /usr/lib/site_ruby/1.8/i386-linux /usr/lib/site_ruby /usr/lib/ruby/1.8 /usr/lib/ruby/1.8/i386-linux . Now I can keep the whole thing Ruby-based without having to change the /sbin/service code or resort to bash startup scripts to kick things off... The section entitled "Where Ruby Finds Its Modules" in the Programming Ruby book (http://www.ruby-doc.org/docs/ProgrammingRuby/) was helpful to me in understanding this. Hope this helps the next victim. -- Posted via http://www.ruby-forum.com/. From singhi.surendra at gmail.com Mon Jan 12 13:13:44 2009 From: singhi.surendra at gmail.com (Surendra Singhi) Date: Mon, 12 Jan 2009 23:43:44 +0530 Subject: [Mongrel] mongrel_rails cluster::stop not working In-Reply-To: References: <05e318561b3dc617b7e8cab6d20d40e7@ruby-forum.com> <48513B54.1050403@jhu.edu> <4067fba3311b88a080150e7cad481170@ruby-forum.com> Message-ID: > ** Daemonized, any open files are closed. Look at > tmp/pids/mongrel.3000.pid and log/mongrel.3000.log for info. > ** Starting Mongrel listening at xxx.xxx.xxx.xxx:3000 > ** Starting Rails with production environment... > /usr/local/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/initializer.rb:530:in > `send': undefined method `cache_template_loading=' for it seems your project was developed for an earlier version of rails. >From your rails environment config files you have to remove the line containing cache_template_loading to make it work. Cheers, -- Surendra Singhi http://ssinghi.kreeti.com, http://www.kreeti.com From harpoon45 at hotmail.com Wed Jan 14 21:05:43 2009 From: harpoon45 at hotmail.com (Ghost rider) Date: Thu, 15 Jan 2009 02:05:43 +0000 Subject: [Mongrel] Mongrel timeout error Message-ID: My mongrel cluster seems to have some weird issues. Anyone here with some insight into whats going on? Tue Jan 13 09:36:34 -0800 2009: Reaping 7 threads for slow workers because of 'shutdown' Thread # is too old, killing. Tue Jan 13 09:36:34 -0800 2009: Error calling Dispatcher.dispatch #Thread # is too old, killing. /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:221:in `process' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in `process_client' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `each' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `process_client' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `initialize' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `new' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `initialize' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `new' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `each' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 /usr/bin/mongrel_rails:19:in `load' /usr/bin/mongrel_rails:19Tue Jan 13 09:36:34 -0800 2009: Error calling Dispatcher.dispatch #Thread # is too old, killing. /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:221:in `process' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in `process_client' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `each' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `process_client' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `initialize' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `new' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `initialize' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `new' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `each' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 /usr/bin/mongrel_rails:19:in `load' /usr/bin/mongrel_rails:19Tue Jan 13 09:36:34 -0800 2009: Error calling Dispatcher.dispatch #Thread # is too old, killing. /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:221:in `process' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in `process_client' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `each' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `process_client' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `initialize' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `new' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `initialize' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `new' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `each' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 /usr/bin/mongrel_rails:19:in `load' /usr/bin/mongrel_rails:19Tue Jan 13 09:36:34 -0800 2009: Error calling Dispatcher.dispatch #Thread # is too old, killing. /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:221:in `process' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in `process_client' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `each' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `process_client' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `initialize' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `new' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `initialize' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `new' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `each' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 /usr/bin/mongrel_rails:19:in `load' /usr/bin/mongrel_rails:19Tue Jan 13 09:36:34 -0800 2009: Error calling Dispatcher.dispatch #Thread # is too old, killing. /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:221:in `process' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in `process_client' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `each' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `process_client' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `initialize' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `new' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `initialize' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `new' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `each' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 /usr/bin/mongrel_rails:19:in `load' /usr/bin/mongrel_rails:19Tue Jan 13 09:36:34 -0800 2009: Error calling Dispatcher.dispatch #Thread # is too old, killing. /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:221:in `process' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in `process_client' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `each' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `process_client' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `initialize' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `new' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `initialize' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `new' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `each' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in `run' /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 /usr/bin/mongrel_rails:19:in `load' /usr/bin/mongrel_rails:19Waiting for 3 requests to finish, could take 60.0 seconds. ** Daemonized, any open files are closed. Look at tmp/pids/mongrel.8000.pid and log/mongrel.8000.log for info. ** Starting Mongrel listening at 0.0.0.0:8000 ** Initiating groups for "mongrel":"mongrel". ** Changing group to "mongrel". ** Changing user to "mongrel". ** Starting Rails with production environment... _________________________________________________________________ Windows Live?: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgrant01101 at gmail.com Wed Jan 14 23:01:15 2009 From: bgrant01101 at gmail.com (benjamin grant) Date: Wed, 14 Jan 2009 20:01:15 -0800 Subject: [Mongrel] Mongrel timeout error In-Reply-To: References: Message-ID: <5adf07c80901142001k5a58c9f8lb8acea5bbde74df2@mail.gmail.com> Recommended: http://www.informit.com/store/product.aspx?isbn=0321544684 Specifically sections 3 and 4, on lsof and strace, the latter of which should be informative re: what the threads are doing when they're not responding to a shutdown, provided you can catch one "in the act". Does this happen -every- time you issue a shutdown, or only after the cluster has been running for awhile? This is otherwise stock mongrel behaviour; it's just trying to comply with a shutdown request, and will forcibly kill threads that are unresponsive. -- On Wed, Jan 14, 2009 at 6:05 PM, Ghost rider wrote: > My mongrel cluster seems to have some weird issues. Anyone here with > some insight into whats going on? > > > Tue Jan 13 09:36:34 -0800 2009: Reaping 7 threads for slow workers > because of 'shutdown' > Thread # is too old, killing. > Tue Jan 13 09:36:34 -0800 2009: Error calling Dispatcher.dispatch > #Thread > # is too old, killing. > > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:221:in > `process' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in > `process_client' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in > `each' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in > `process_client' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `initialize' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `new' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `initialize' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `new' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in > `each' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 > /usr/bin/mongrel_rails:19:in `load' > /usr/bin/mongrel_rails:19Tue Jan 13 09:36:34 -0800 2009: Error calling > Dispatcher.dispatch # thread: shutdown>Thread # is too old, > killing. > > > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:221:in > `process' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in > `process_client' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in > `each' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in > `process_client' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `initialize' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `new' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `initialize' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `new' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in > `each' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 > /usr/bin/mongrel_rails:19:in `load' > /usr/bin/mongrel_rails:19Tue Jan 13 09:36:34 -0800 2009: Error calling > Dispatcher.dispatch # thread: shutdown>Thread # is too old, > killing. > > > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:221:in > `process' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in > `process_client' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in > `each' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in > `process_client' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `initialize' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `new' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `initialize' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `new' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in > `each' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 > /usr/bin/mongrel_rails:19:in `load' > /usr/bin/mongrel_rails:19Tue Jan 13 09:36:34 -0800 2009: Error calling > Dispatcher.dispatch # thread: shutdown>Thread # is too old, > killing. > > > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:221:in > `process' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in > `process_client' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in > `each' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in > `process_client' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `initialize' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `new' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `initialize' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `new' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in > `each' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 > /usr/bin/mongrel_rails:19:in `load' > /usr/bin/mongrel_rails:19Tue Jan 13 09:36:34 -0800 2009: Error calling > Dispatcher.dispatch # thread: shutdown>Thread # is too old, > killing. > > > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:221:in > `process' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in > `process_client' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in > `each' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in > `process_client' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `initialize' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `new' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `initialize' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `new' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in > `each' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 > /usr/bin/mongrel_rails:19:in `load' > /usr/bin/mongrel_rails:19Tue Jan 13 09:36:34 -0800 2009: Error calling > Dispatcher.dispatch # thread: shutdown>Thread # is too old, > killing. > > > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:221:in > `process' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in > `process_client' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in > `each' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in > `process_client' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `initialize' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `new' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `initialize' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `new' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in > `each' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in > `run' > /usr/lib64/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281 > /usr/bin/mongrel_rails:19:in `load' > /usr/bin/mongrel_rails:19Waiting for 3 requests to finish, could take > 60.0 seconds. > > ** Daemonized, any open files are closed. Look at > tmp/pids/mongrel.8000.pid and log/mongrel.8000.log for info. > ** Starting Mongrel listening at 0.0.0.0:8000 > ** Initiating groups for "mongrel":"mongrel". > ** Changing group to "mongrel". > ** Changing user to "mongrel". > ** Starting Rails with production environment... > > > ------------------------------ > Windows Live?: Keep your life in sync. Check it out. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at cheney.net Thu Jan 15 01:00:24 2009 From: dave at cheney.net (Dave Cheney) Date: Thu, 15 Jan 2009 01:00:24 -0500 Subject: [Mongrel] Mongrel timeout error In-Reply-To: <5adf07c80901142001k5a58c9f8lb8acea5bbde74df2@mail.gmail.com> References: <5adf07c80901142001k5a58c9f8lb8acea5bbde74df2@mail.gmail.com> Message-ID: <23dc8b2773bd130e189fd4fe4bc7c823@cheney.net> > This is otherwise stock mongrel behaviour; it's just trying to comply with > a > shutdown request, and will forcibly kill threads that are unresponsive. Yup, you have one active request that is blocked on something (most likely the db, or a web services call). The standard mogrel shutdown behviour is to issue a thread#kill for each thread in the queue. The thread at the head of the queue gets a few seconds grace before it gets a forcefull kill. Cheers DAve From jalmberg at identry.com Wed Jan 28 08:52:50 2009 From: jalmberg at identry.com (John Almberg) Date: Wed, 28 Jan 2009 08:52:50 -0500 Subject: [Mongrel] Sharing a mongrel cluster in a multi-url environment Message-ID: <329C8E03-26B5-4D9B-BE83-D32B3881C916@identry.com> I have a 2.2.2 ROR website package that I sell to my clients. After deploying a few instances, I realized that the only difference between the accounts was the client's URL and the database. It seemed wasteful to have many copies of the same software on my web server, not to mention a separate mongrel cluster for each client, most of which were running at very low load levels. So I had the idea of combining all these separate websites into one 'shared' system. Having no idea how to do that, I had to wing it. Here's what I'm using: 1. Apache as the front end server, running mod_proxy 2. A single mongrel cluster (4 mongrels) 3. A single instance of my Rails application I had each Apache virtual host configuration insert a unique client_id header in all requests, like so: RequestHeader set X_CLIENT_ID '7563TY7732UUW9' # a unique id for each domain The Rails app then reads this header and knows which client database to use. Thus, a request comes in for the url example1.com, Apache adds the unique X_CLIENT_ID header for that URL, the request gets forwarded through Mongrel, Rails reads the client_id, connects to the correct database, and then renders the page as it would if this were not a multi-domain system. This all works very well except for one serious problem: mongrel seems to mess up cookie handling in a multi-domain situation. The problem is illustrated in the log snippet at the bottom of this email: The 1st request is from User 1, already logged in and working on example1.com. The 2nd request is from User 2, for the example2.com home page. The 3rd request is from User 1, for another page in the application. The HTTP request included the original cookie, but note that the cookie value, the session id that Rails sees, has changed! The 4th request shows User 1 being redirected to the login page, because to Rails it looks like User 1 is a new, un-authenticated user, who does not have the rights to access that page. If no one ever accesses example2.com, then the users of example1.com have no problem. That is, their cookies are not changed. However, as soon as anyone hits example2.com, anyone subsequently hitting example1.com will have their session_id cookie changed. The same is true in the other direction... hits on example1 also change the cookies of users on example2. I can solve the problem by not sharing mongrels. That is, by keeping everything else the same, but dedicating one or more mongrel instances to each URL. As soon as mongrel stops handling multiple URLs, the cookie problem vanishes. However, this gets me back to having one or more mongrels for each domain, which seems wasteful. A single mongrel cluster of 4 or 6 can easily handle the load, if it weren't for this cookie problem. Can anyone explain this problem to me? I don't actually understand why mongrel doesn't just pass the cookie in the request straight through to Rails. Why does it change it? And can anyone suggest a work-around? Or perhaps I've got the wrong end of the stick, and it's not Mongrel's fault? Or maybe I should take an entirely different approach to this multi-domain problem? As I said, this is straight out of my head. I have not been able to google any other approach to what I'm trying to do here. Any help, much appreciated. Again, this is a fully upgraded Rails 2.2.2 system. -- John **1st Request from USER 1 for example1.com** Processing Admin::CmsController#index (for 75.127.142.66 at 2009-01-27 13:15:27) [GET] Session ID: 00b9cfb6fd397e5c9934ea58eaef648d >>> Request for client 90873721, EXAMPLE1.COM Rendering template within layouts/admin/standard Rendering admin/cms/list Completed in 114ms (View: 14, DB: 81) | 200 OK [https:// example1.com/admin/cms] **2nd Request from User 2 for example2.com** Processing CmsController#cms_show (for 64.1.215.163 at 2009-01-27 13:16:15) [GET] Session ID: 4fed1c59001f7484a63fb6280376825a Parameters: {"alias"=>"home.html"} >>> Request for client 48218343, EXAMPLE2.COM ### alias: home.html Rendering template within layouts/two-column Rendering cms/cms_show Completed in 23ms (View: 13, DB: 3) | 200 OK [http:// example2.com/] **3rd Request from User 1 for example1.com -- note session ID changes!!!** Processing Admin::CmsController#index (for 75.127.142.66 at 2009-01-27 13:16:18) [GET] Session ID: 85c178aa70ed2bef6a767e844bf6c6d6 >>> Request for client 90873721, EXAMPLE1.COM ####### 'admin/cms', 'index' Redirected to actionsignincontroller/admin/user Filter chain halted as [:check_authentication] rendered_or_redirected. Completed in 4ms | 302 Found [https://example1.com/admin/cms] **4th request -- redirected from 3rd request** Processing Admin::UserController#signin (for 75.127.142.66 at 2009-01-27 13:16:18) [GET] Session ID: 85c178aa70ed2bef6a767e844bf6c6d6 >>> Request for client 90873721, EXAMPLE1.COM Rendering template within layouts/admin/standard Rendering admin/user/signin Completed in 10ms (View: 6, DB: 0) | 200 OK [https:// example1.com/admin/user/signin] From david at vrensk.com Wed Jan 28 17:45:23 2009 From: david at vrensk.com (David Vrensk) Date: Wed, 28 Jan 2009 23:45:23 +0100 Subject: [Mongrel] Sharing a mongrel cluster in a multi-url environment In-Reply-To: <329C8E03-26B5-4D9B-BE83-D32B3881C916@identry.com> References: <329C8E03-26B5-4D9B-BE83-D32B3881C916@identry.com> Message-ID: <81b453920901281445y68c74c3as5eff5bf03fed74dc@mail.gmail.com> I don't think this is mongrel's fault, but it's interesting nonetheless. Could you have apache log the incoming cookie value to shed some more light on what happens? I believe that the cookie you see is not the cookie that the client sends, but a new cookie that Rails generates when it cannot find the cookie from the request in its current db. My theory (aka wild guess) is that Rails picks up the cookie before you change/set the database connection. Like this: User1 requests the login page. Rails connects to db1 and renders the page. User1 logs in and is given a cookie, and session data is stored in db1. User1 does something and all is good. User2 requests the login page. Rails connects to db2 and renders. User1 requests a new page. Rails is connected to db2 and fails to find the cookie. Rails connects to db1 and redirects user. Now, this isn't exactly what's happening in your logs, but add the fact that the different requests are being handled by different mongrels, each with their Rails stacks and db connections, and you have a fine mess. Could you try running just one mongrel for a short while to minimise the number of moving parts? HTH, /David -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ruby-forum.com Wed Jan 28 19:23:34 2009 From: lists at ruby-forum.com (Ripta Pasay) Date: Thu, 29 Jan 2009 01:23:34 +0100 Subject: [Mongrel] Sharing a mongrel cluster in a multi-url environment In-Reply-To: <329C8E03-26B5-4D9B-BE83-D32B3881C916@identry.com> References: <329C8E03-26B5-4D9B-BE83-D32B3881C916@identry.com> Message-ID: <27acdba0e160f1c903106409dd426b8e@ruby-forum.com> > 1. Apache as the front end server, running mod_proxy > 2. A single mongrel cluster (4 mongrels) > 3. A single instance of my Rails application > My question is, which one of the four mongrels is handling each of the request? Can it be that your application isn't thread-safe, and the same mongrel instance is getting sent a new request before the previous request completes? > I had each Apache virtual host configuration insert a unique > client_id header in all requests, like so: > > RequestHeader set X_CLIENT_ID '7563TY7732UUW9' # a unique id for > each domain > Also, just curious: was there a specific reason you added another layer to the request routing with the use of X_CLIENT_ID, rather than just use the value of "request.host" in Rails? It seems there's a one-to-one mapping between virtual hostnames and X_CLIENT_ID. -Ripta -- Posted via http://www.ruby-forum.com/. From jalmberg at identry.com Thu Jan 29 09:32:36 2009 From: jalmberg at identry.com (John Almberg) Date: Thu, 29 Jan 2009 09:32:36 -0500 Subject: [Mongrel] Sharing a mongrel cluster in a multi-url environment In-Reply-To: <81b453920901281445y68c74c3as5eff5bf03fed74dc@mail.gmail.com> References: <329C8E03-26B5-4D9B-BE83-D32B3881C916@identry.com> <81b453920901281445y68c74c3as5eff5bf03fed74dc@mail.gmail.com> Message-ID: <6C6CFC06-E4D6-4745-9488-F2A195013CE3@identry.com> On Jan 28, 2009, at 5:45 PM, David Vrensk wrote: > I don't think this is mongrel's fault, but it's interesting > nonetheless. > > Could you have apache log the incoming cookie value to shed some > more light on what happens? I believe that the cookie you see is > not the cookie that the client sends, but a new cookie that Rails > generates when it cannot find the cookie from the request in its > current db. > > My theory (aka wild guess) is that Rails picks up the cookie before > you change/set the database connection. Like this: > > User1 requests the login page. > Rails connects to db1 and renders the page. > User1 logs in and is given a cookie, and session data is stored in > db1. > User1 does something and all is good. > User2 requests the login page. > Rails connects to db2 and renders. > User1 requests a new page. > Rails is connected to db2 and fails to find the cookie. > Rails connects to db1 and redirects user. > > Now, this isn't exactly what's happening in your logs, but add the > fact that the different requests are being handled by different > mongrels, each with their Rails stacks and db connections, and you > have a fine mess. H'mmm. This is an interesting idea. I will do some testing to see if this is the problem . > Could you try running just one mongrel for a short while to > minimise the number of moving parts? Yes, I tried that and it made no difference. In fact, the log trace I sent was with one mongrel in the mongrel cluster. I will get back with results of the db testing later today. Thanks for the idea. -- John From jalmberg at identry.com Thu Jan 29 09:42:58 2009 From: jalmberg at identry.com (John Almberg) Date: Thu, 29 Jan 2009 09:42:58 -0500 Subject: [Mongrel] Sharing a mongrel cluster in a multi-url environment In-Reply-To: <27acdba0e160f1c903106409dd426b8e@ruby-forum.com> References: <329C8E03-26B5-4D9B-BE83-D32B3881C916@identry.com> <27acdba0e160f1c903106409dd426b8e@ruby-forum.com> Message-ID: On Jan 28, 2009, at 7:23 PM, Ripta Pasay wrote: > >> 1. Apache as the front end server, running mod_proxy >> 2. A single mongrel cluster (4 mongrels) >> 3. A single instance of my Rails application >> > > My question is, which one of the four mongrels is handling each of the > request? Can it be that your application isn't thread-safe, and the > same > mongrel instance is getting sent a new request before the previous > request completes? No, sorry, I should have mentioned that I had already cut down the number of mongrels in the cluster to 1. I would have, but in my mind I had already ruled that out, so didn't think to mention it. > >> I had each Apache virtual host configuration insert a unique >> client_id header in all requests, like so: >> >> RequestHeader set X_CLIENT_ID '7563TY7732UUW9' # a unique id for >> each domain >> > > > Also, just curious: was there a specific reason you added another > layer > to the request routing with the use of X_CLIENT_ID, rather than > just use > the value of "request.host" in Rails? It seems there's a one-to-one > mapping between virtual hostnames and X_CLIENT_ID. Yes, I just didn't realize that at the outset. This is the first time I'm doing something like this, so I'm sort of making it up as I go along. -- John From jalmberg at identry.com Thu Jan 29 10:33:24 2009 From: jalmberg at identry.com (John Almberg) Date: Thu, 29 Jan 2009 10:33:24 -0500 Subject: [Mongrel] Sharing a mongrel cluster in a multi-url environment In-Reply-To: <6C6CFC06-E4D6-4745-9488-F2A195013CE3@identry.com> References: <329C8E03-26B5-4D9B-BE83-D32B3881C916@identry.com> <81b453920901281445y68c74c3as5eff5bf03fed74dc@mail.gmail.com> <6C6CFC06-E4D6-4745-9488-F2A195013CE3@identry.com> Message-ID: On Jan 29, 2009, at 9:32 AM, John Almberg wrote: > > On Jan 28, 2009, at 5:45 PM, David Vrensk wrote: > >> I don't think this is mongrel's fault, but it's interesting >> nonetheless. >> >> Could you have apache log the incoming cookie value to shed some >> more light on what happens? I believe that the cookie you see is >> not the cookie that the client sends, but a new cookie that Rails >> generates when it cannot find the cookie from the request in its >> current db. >> >> My theory (aka wild guess) is that Rails picks up the cookie >> before you change/set the database connection. Like this: >> >> User1 requests the login page. >> Rails connects to db1 and renders the page. >> User1 logs in and is given a cookie, and session data is stored in >> db1. >> User1 does something and all is good. >> User2 requests the login page. >> Rails connects to db2 and renders. >> User1 requests a new page. >> Rails is connected to db2 and fails to find the cookie. >> Rails connects to db1 and redirects user. >> >> Now, this isn't exactly what's happening in your logs, but add the >> fact that the different requests are being handled by different >> mongrels, each with their Rails stacks and db connections, and you >> have a fine mess. > > H'mmm. This is an interesting idea. I will do some testing to see > if this is the problem Okay, here is what I did. 1. I retested the configuration that used a separate mongrel instance (fired up from the command line) for each virtual host. No problem. [2 virtual hosts, 2 mongrels, 1 rails app, 2 databases] 2. I connected the two Apache virtual hosts back to the mongrel_cluster (of 1 mongrel). The problem re-appeared. [2 virtual hosts, 1 mongrel cluster, 1 rails app, 2 databases] 3. I changed the X_CLIENT_ID header in example2.com so it matched the client_id in example1.com. This means that both domains connected to the same database, without changing anything else. The problem disappeared. [2 virtual hosts, 1 mongrel cluster, 1 rails app, 1 database] This test seems to confirm that the problem is in the database switching. But scenario #1 also had the database switching and worked fine. This makes me think that a mongrel instance has some sort of persistent connection to the rails application, and the database that is 'active'. Is this true? Is the problem seen in scenario #2 caused by this persistent connection being forced over to different URL and different database? -- John From will at hotgazpacho.com Thu Jan 29 22:17:19 2009 From: will at hotgazpacho.com (Will Green) Date: Thu, 29 Jan 2009 22:17:19 -0500 Subject: [Mongrel] Sharing a mongrel cluster in a multi-url environment In-Reply-To: References: <329C8E03-26B5-4D9B-BE83-D32B3881C916@identry.com> <81b453920901281445y68c74c3as5eff5bf03fed74dc@mail.gmail.com> <6C6CFC06-E4D6-4745-9488-F2A195013CE3@identry.com> Message-ID: <002c01c98289$42bf8d30$c83ea790$@com> I'm not sure that instance-specific connections are supported by ActiveRecord (you can, however, use class-specific connections). From the ActiveRecord documentation, http://api.rubyonrails.org/classes/ActiveRecord/Base.html, the database connection information is tied to your model at the class level. I don't think you can accomplish what you have described without a separate Mongrel cluster for each virtual host. Here's an alternate idea: Assuming you're deploying to a *nix server, what you might try instead is having your rails app live in one location on the file system. Then, since the only thing that is different is the configuration, for each domain, symlink in all but the config directory. The config directory will then be unique for each app, but all the code will be shared. When you update the application code, simply restart all the mongrel clusters. Another idea: you may want to reconsider your application architecture. Do you really need a separate database for each host? Could you instead introduce a ClientAccount class (that has the value from X_CLIENT_ID as the Primary Key), and tie it into the other models with has_many relationships and a before_filter on the ApplicationController? This way, you don't need separate configs, you could point each VirtualHost at the same Mongrel cluster, AND you could manage the Client Account within rails. == Will Green From jalmberg at identry.com Fri Jan 30 04:22:02 2009 From: jalmberg at identry.com (John Almberg) Date: Fri, 30 Jan 2009 04:22:02 -0500 Subject: [Mongrel] Sharing a mongrel cluster in a multi-url environment In-Reply-To: <002c01c98289$42bf8d30$c83ea790$@com> References: <329C8E03-26B5-4D9B-BE83-D32B3881C916@identry.com> <81b453920901281445y68c74c3as5eff5bf03fed74dc@mail.gmail.com> <6C6CFC06-E4D6-4745-9488-F2A195013CE3@identry.com> <002c01c98289$42bf8d30$c83ea790$@com> Message-ID: <4F142A0D-78CF-4078-BCAB-47B548CB67D5@identry.com> On Jan 29, 2009, at 10:17 PM, Will Green wrote: > I'm not sure that instance-specific connections are supported by > ActiveRecord (you can, however, use class-specific connections). > From the > ActiveRecord documentation, > http://api.rubyonrails.org/classes/ActiveRecord/Base.html, the > database > connection information is tied to your model at the class level. I > don't > think you can accomplish what you have described without a separate > Mongrel > cluster for each virtual host. I'm hoping I can. What I'm going to try next is to use a common database (the one defined in environment/production.rb) for the sessions table. Then when I switch the database to the client's db, the session table won't be affected. That's the theory, anyway. > > Here's an alternate idea: > > Assuming you're deploying to a *nix server, what you might try > instead is > having your rails app live in one location on the file system. > Then, since > the only thing that is different is the configuration, for each > domain, > symlink in all but the config directory. The config directory will > then be > unique for each app, but all the code will be shared. When you > update the > application code, simply restart all the mongrel clusters. Well, if I can get what I need working, I'll only have one shared mongrel cluster. That is the goal -- to eliminate the need to have dedicated mongrels for every client. I really don't want to have hundreds of mongrels cluttering up the system. BTW, I don't think it is a problem to have multiple mongrel clusters on one directory. I haven't tried this, but don't see why it wouldn't work. Just use a different pid for each cluster. > > Another idea: you may want to reconsider your application > architecture. Do > you really need a separate database for each host? Could you instead > introduce a ClientAccount class (that has the value from > X_CLIENT_ID as the > Primary Key), and tie it into the other models with has_many > relationships > and a before_filter on the ApplicationController? This way, you > don't need > separate configs, you could point each VirtualHost at the same Mongrel > cluster, AND you could manage the Client Account within rails. I've thought about that, but each client potentially has thousands of records in his/her database. I believe the system will get too slow if all records are in one db, and all clients will be impacted by the one client who has a million records. Plus each and every table would have to have client_id in it. That just smells bad to me. Much simpler to just give each client his own db and switch on the request. That's what I'm hoping for, anyway. -- John From rochkind at jhu.edu Fri Jan 30 10:28:47 2009 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Fri, 30 Jan 2009 10:28:47 -0500 Subject: [Mongrel] Sharing a mongrel cluster in a multi-url environment In-Reply-To: <4F142A0D-78CF-4078-BCAB-47B548CB67D5@identry.com> References: <329C8E03-26B5-4D9B-BE83-D32B3881C916@identry.com> <81b453920901281445y68c74c3as5eff5bf03fed74dc@mail.gmail.com> <6C6CFC06-E4D6-4745-9488-F2A195013CE3@identry.com> <002c01c98289$42bf8d30$c83ea790$@com> <4F142A0D-78CF-4078-BCAB-47B548CB67D5@identry.com> Message-ID: <49831CAF.9030504@jhu.edu> I'm suspicious of your idea that having each client have their own db is going to be more efficient. Most rdbms are set up to support very large tables, if you have the proper indexes created, but not neccesarily set up to support thousands of seperate databases within an rdbms instance. At least, AR is written assuming you are NOT going to do what you're trying to do, so you're definitely going to be fighting AR to do this. But this is really an AR question rather than a mongrel question. You could try asking on the AR lists. Jonathan John Almberg wrote: > On Jan 29, 2009, at 10:17 PM, Will Green wrote: > > >> I'm not sure that instance-specific connections are supported by >> ActiveRecord (you can, however, use class-specific connections). >> From the >> ActiveRecord documentation, >> http://api.rubyonrails.org/classes/ActiveRecord/Base.html, the >> database >> connection information is tied to your model at the class level. I >> don't >> think you can accomplish what you have described without a separate >> Mongrel >> cluster for each virtual host. >> > > I'm hoping I can. What I'm going to try next is to use a common > database (the one defined in environment/production.rb) for the > sessions table. Then when I switch the database to the client's db, > the session table won't be affected. > > That's the theory, anyway. > > >> Here's an alternate idea: >> >> Assuming you're deploying to a *nix server, what you might try >> instead is >> having your rails app live in one location on the file system. >> Then, since >> the only thing that is different is the configuration, for each >> domain, >> symlink in all but the config directory. The config directory will >> then be >> unique for each app, but all the code will be shared. When you >> update the >> application code, simply restart all the mongrel clusters. >> > > Well, if I can get what I need working, I'll only have one shared > mongrel cluster. That is the goal -- to eliminate the need to have > dedicated mongrels for every client. I really don't want to have > hundreds of mongrels cluttering up the system. > > BTW, I don't think it is a problem to have multiple mongrel clusters > on one directory. I haven't tried this, but don't see why it wouldn't > work. Just use a different pid for each cluster. > > >> Another idea: you may want to reconsider your application >> architecture. Do >> you really need a separate database for each host? Could you instead >> introduce a ClientAccount class (that has the value from >> X_CLIENT_ID as the >> Primary Key), and tie it into the other models with has_many >> relationships >> and a before_filter on the ApplicationController? This way, you >> don't need >> separate configs, you could point each VirtualHost at the same Mongrel >> cluster, AND you could manage the Client Account within rails. >> > > I've thought about that, but each client potentially has thousands of > records in his/her database. I believe the system will get too slow > if all records are in one db, and all clients will be impacted by the > one client who has a million records. > > Plus each and every table would have to have client_id in it. That > just smells bad to me. Much simpler to just give each client his own > db and switch on the request. That's what I'm hoping for, anyway. > > -- John > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu