From paul.danter at gmail.com Mon Dec 3 14:16:21 2007 From: paul.danter at gmail.com (Paul Danter) Date: Mon, 3 Dec 2007 11:16:21 -0800 Subject: [Mongrel] Originating Client Request Message-ID: <3E7522EB-34FD-4EEC-8768-B150C79FD7F5@gmail.com> Hi, I'm a newbie to Mongrel, so apologies if this is a dumb question. I'm trying to write a Mongrel handler to give my the *raw* client request, however all I seem to be able to get is the CGI headers using the Mongrel API. I want to be able to capture the originating request, not the CGI version as it may contain issues (like case, underscore's rather than hypens and any linefeed issues). It's imperative a capture this exactly as it was sent by the client as this is an essential part of my rails application. I wrote a very simple WEBrick Servlet which does this: class OriginatingHeaderServlet < WEBrick::HTTPServlet::AbstractServlet def do_GET(request, response) response['Content-Type'] = 'text/plain' response.status = 200 response.body = request.to_s end end which produces... GET /header HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us) AppleWebKit/523.10.3 (KHTML, like Gecko) Version/3.0.4 Safari/523.10 Accept: text/xml,application/xml,application/xhtml+xml,text/ html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us Accept-Encoding: gzip, deflate Cookie: _dk_session_id=5d1bb099d2a1ba28f06a0bd60e091e3d Connection: keep-alive Host: localhost:8000 ...this represents the correct raw originating headers... When I try implementing the same thing using a Mongrel handler... class ClientHandler < Mongrel::HttpHandler def process(request, response) response.start(200) do |head, out| head["Content-Type"] = "text/plain" out.write request.params end end end ... I get the CGI headers (request.body is empty, is that correct?) ... SERVER_NAMElocalhostPATH_INFOHTTP_ACCEPT_ENCODINGgzip, deflateHTTP_USER_AGENTMozilla/5.0 (Macintosh; U; Intel Mac OS X; en- us) AppleWebKit/523.10.3 (KHTML, like Gecko) Version/3.0.4 Safari/ 523.10SCRIPT_NAME/cSERVER_PROTOCOLHTTP/1.1HTTP_HOSTlocalhost: 3000HTTP_ACCEPT_LANGUAGEen-usHTTP_CACHE_CONTROLmax- age=0REMOTE_ADDR127.0.0.1SERVER_SOFTWAREMongrel 1.0.1REQUEST_PATH/ cHTTP_COOKIE_dk_session_id=5d1bb099d2a1ba28f06a0bd60e091e3dHTTP_VERSIONHTTP/1.1REQUEST_URI/cSERVER_PORT3000GATEWAY_INTERFACECGI/1.2HTTP_ACCEPTtext/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5HTTP_CONNECTIONkeep-aliveREQUEST_METHODGET Is is possible to get to the raw request from within a Mongrel handler? Many thanks, -Paul From eden at mojiti.com Mon Dec 3 20:19:47 2007 From: eden at mojiti.com (Eden Li) Date: Tue, 4 Dec 2007 09:19:47 +0800 Subject: [Mongrel] Originating Client Request In-Reply-To: <3E7522EB-34FD-4EEC-8768-B150C79FD7F5@gmail.com> References: <3E7522EB-34FD-4EEC-8768-B150C79FD7F5@gmail.com> Message-ID: <1dd361e10712031719h54a44256jddb3b9717a6b736d@mail.gmail.com> You could try rewinding request.body and re-reading it, although I'm not sure mongrel puts the whole request there... It's gotta process the header enough in order to find your handler in the first place, so you may be out of luck here. On 12/4/07, Paul Danter wrote: > Hi, > > I'm a newbie to Mongrel, so apologies if this is a dumb question. > > I'm trying to write a Mongrel handler to give my the *raw* client > request, however all I seem to be able to get is the CGI headers using > the Mongrel API. > > I want to be able to capture the originating request, not the CGI > version as it may contain issues (like case, underscore's rather than > hypens and any linefeed issues). It's imperative a capture this > exactly as it was sent by the client as this is an essential part of > my rails application. > > I wrote a very simple WEBrick Servlet which does this: > > class OriginatingHeaderServlet < WEBrick::HTTPServlet::AbstractServlet > def do_GET(request, response) > response['Content-Type'] = 'text/plain' > response.status = 200 > response.body = request.to_s > end > end > > which produces... > > GET /header HTTP/1.1 > User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us) > AppleWebKit/523.10.3 (KHTML, like Gecko) Version/3.0.4 Safari/523.10 > Accept: text/xml,application/xml,application/xhtml+xml,text/ > html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 > Accept-Language: en-us > Accept-Encoding: gzip, deflate > Cookie: _dk_session_id=5d1bb099d2a1ba28f06a0bd60e091e3d > Connection: keep-alive > Host: localhost:8000 > > ...this represents the correct raw originating headers... > > When I try implementing the same thing using a Mongrel handler... > > class ClientHandler < Mongrel::HttpHandler > def process(request, response) > response.start(200) do |head, out| > head["Content-Type"] = "text/plain" > out.write request.params > end > end > end > > ... I get the CGI headers (request.body is empty, is that correct?) ... > > SERVER_NAMElocalhostPATH_INFOHTTP_ACCEPT_ENCODINGgzip, > deflateHTTP_USER_AGENTMozilla/5.0 (Macintosh; U; Intel Mac OS X; en- > us) AppleWebKit/523.10.3 (KHTML, like Gecko) Version/3.0.4 Safari/ > 523.10SCRIPT_NAME/cSERVER_PROTOCOLHTTP/1.1HTTP_HOSTlocalhost: > 3000HTTP_ACCEPT_LANGUAGEen-usHTTP_CACHE_CONTROLmax- > age=0REMOTE_ADDR127.0.0.1SERVER_SOFTWAREMongrel 1.0.1REQUEST_PATH/ > cHTTP_COOKIE_dk_session_id=5d1bb099d2a1ba28f06a0bd60e091e3dHTTP_VERSIONHTTP/1.1REQUEST_URI/cSERVER_PORT3000GATEWAY_INTERFACECGI/1.2HTTP_ACCEPTtext/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5HTTP_CONNECTIONkeep-aliveREQUEST_METHODGET > > Is is possible to get to the raw request from within a Mongrel handler? > > Many thanks, > > -Paul > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From ftotheu at gmail.com Tue Dec 4 15:05:51 2007 From: ftotheu at gmail.com (A R) Date: Tue, 4 Dec 2007 20:05:51 +0000 Subject: [Mongrel] Mongrel 1.1.1 Win32 (latest) + Rubygems Message-ID: <5c76aeb60712041205o60e5f5ecwa4f4793c4aef9503@mail.gmail.com> Hello all. Hope this doesn't appear as spam... I am trying to run Mongrel on Win XP (SP2) for a web site (just one at the moment). For some reason it is giving me this error: E:\web\app2>mongrel_rails start -p 4001 -d ** WARNING: Win32 does not support daemon mode. ** Daemonized, any open files are closed. Look at log/mongrel.pid and log/mongr el.log for info. ** Starting Mongrel listening at 0.0.0.0:4001 ** Starting Rails with development environment... ** Rails loaded. ** Loading any Rails specific GemPlugins e:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_re quire': no such file to load -- e:/ruby/lib/ruby/gems/1.8/gems/mongrel- 1.1.1-x86 -mswin32-60/lib/mongrel/init.rb (MissingSourceFile) from e:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `re quire' ||||||| V from e:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.1-mswin32 /bin/mongrel_ra ils:281 from e:/ruby/bin/mongrel_rails:19:in `load' from e:/ruby/bin/mongrel_rails:19 When I look for "e:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.1-x86-mswin32-60/lib/mongrel/init.rb" I notice that the directory is called .../gems/mongrel-1.1.1-mswin32/.. I don't really know anything about how the internals of rubygems works and I assume that simply renaming the directory is a bad idea? When I rename the directory it loads fine, although I don't know what the implications are! Thanks if you have any answers! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071204/14a83e5a/attachment.html From luislavena at gmail.com Tue Dec 4 15:15:50 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 4 Dec 2007 17:15:50 -0300 Subject: [Mongrel] Mongrel 1.1.1 Win32 (latest) + Rubygems In-Reply-To: <5c76aeb60712041205o60e5f5ecwa4f4793c4aef9503@mail.gmail.com> References: <5c76aeb60712041205o60e5f5ecwa4f4793c4aef9503@mail.gmail.com> Message-ID: <71166b3b0712041215x51b17019me082399ab6c87414@mail.gmail.com> On Dec 4, 2007 5:05 PM, A R wrote: > Hello all. Hope this doesn't appear as spam... > > I am trying to run Mongrel on Win XP (SP2) for a web site (just one at the > moment). For some reason it is giving me this error: > [snip] This is a known problem with RubyGems 0.9.5 You should downgrade back to 0.9.4 until 0.9.5.1 or greater get released (since I think is fixed on trunk). Oh, also remove the -d (daemonize) option from the command line, daemonize requires fork() which don't work under Windows. For running mongrel_rails in a deattached (background) fashion, please take a look at mongrel_service gem. HTH, -- 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 evan at cloudbur.st Tue Dec 4 15:23:55 2007 From: evan at cloudbur.st (Evan Weaver) Date: Tue, 4 Dec 2007 15:23:55 -0500 Subject: [Mongrel] Mongrel 1.1.1 Win32 (latest) + Rubygems In-Reply-To: <5c76aeb60712041205o60e5f5ecwa4f4793c4aef9503@mail.gmail.com> References: <5c76aeb60712041205o60e5f5ecwa4f4793c4aef9503@mail.gmail.com> Message-ID: http://rubyforge.org/tracker/index.php?func=detail&aid=15817&group_id=1306&atid=5145 Evan On Dec 4, 2007 3:05 PM, A R wrote: > Hello all. Hope this doesn't appear as spam... > > I am trying to run Mongrel on Win XP (SP2) for a web site (just one at the > moment). For some reason it is giving me this error: > > E:\web\app2>mongrel_rails start -p 4001 -d > ** WARNING: Win32 does not support daemon mode. > ** Daemonized, any open files are closed. Look at log/mongrel.pid and > log/mongr > el.log for info. > ** Starting Mongrel listening at 0.0.0.0:4001 > ** Starting Rails with development environment... > ** Rails loaded. > ** Loading any Rails specific GemPlugins > e:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_re > quire': no such file to load -- e:/ruby/lib/ruby/gems/1.8/gems/mongrel- > 1.1.1-x86 > -mswin32-60/lib/mongrel/init.rb (MissingSourceFile) > from > e:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `re > quire' > ||||||| > V > from > e:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.1-mswin32/bin/mongrel_ra > ils:281 > from e:/ruby/bin/mongrel_rails:19:in `load' > from e:/ruby/bin/mongrel_rails:19 > > When I look for > "e:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.1-x86-mswin32-60/lib/mongrel/init.rb" > I notice that the directory is called .../gems/mongrel- 1.1.1-mswin32/.. > > I don't really know anything about how the internals of rubygems works and I > assume that simply renaming the directory is a bad idea? When I rename the > directory it loads fine, although I don't know what the implications are! > > Thanks if you have any answers! > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From lists at ruby-forum.com Wed Dec 5 13:31:15 2007 From: lists at ruby-forum.com (Roger Pack) Date: Wed, 5 Dec 2007 19:31:15 +0100 Subject: [Mongrel] mongrel startup fails now: already initialized constant In-Reply-To: <5775c6d8efa9ca8ba589632b005647cc@ruby-forum.com> References: <04A94C21-D841-449A-8BCC-9181973A526A@wisc.edu> <5775c6d8efa9ca8ba589632b005647cc@ruby-forum.com> Message-ID: In my case this didn't help--when I tried to boot script/server webrick it booted webrick THEN mongrel (odd). Temporary fix: gem uninstall mongrel > I had a similar problem today that was resolved by uninstalling and > re-installing mongrel. I don't have ruport installed. I tried > uninstalling gem_plugin first and then reinstalling, but that seemed to > make no difference, mongrel still died with the "options" method error > for Array. In case it helps, here are the relevant lines: > -- Posted via http://www.ruby-forum.com/. From luislavena at gmail.com Wed Dec 5 13:55:44 2007 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 5 Dec 2007 15:55:44 -0300 Subject: [Mongrel] mongrel startup fails now: already initialized constant In-Reply-To: References: <04A94C21-D841-449A-8BCC-9181973A526A@wisc.edu> <5775c6d8efa9ca8ba589632b005647cc@ruby-forum.com> Message-ID: <71166b3b0712051055l1b422ffdhacd39ca957892b3d@mail.gmail.com> On Dec 5, 2007 3:31 PM, Roger Pack wrote: > In my case this didn't help--when I tried to boot script/server webrick > it booted webrick THEN mongrel (odd). Temporary fix: gem uninstall > mongrel > > I had a similar problem today that was resolved by uninstalling and > > re-installing mongrel. I don't have ruport installed. I tried > > uninstalling gem_plugin first and then reinstalling, but that seemed to > > make no difference, mongrel still died with the "options" method error > > for Array. In case it helps, here are the relevant lines: > > script/server is borked. Historically it do odd things with the way it loads and loads mongrel, if you search this list you will find a few cases that describe this situation. I suggest stick to mongrel_rails start or mongrel_service in case you're running on Windows. -- 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 njvack at wisc.edu Thu Dec 6 12:34:37 2007 From: njvack at wisc.edu (Nathan Vack) Date: Thu, 6 Dec 2007 11:34:37 -0600 Subject: [Mongrel] Solved: Mongrel hangs, consumes all CPU on shutdown In-Reply-To: References: Message-ID: <44ECB47C-EC79-4B60-8087-CEC7AB557ADF@wisc.edu> OK, it's kind of a weenie solution, but Rails 2.0RC2 seems to totally fix this. So, if you're hanging in OS X, there's one more reason to look at upgrading :) -Nate On Sep 12, 2007, at 4:47 PM, Nathan Vack wrote: > Hi, > > I'm doing development with Mongrel 1.0.1 on Ruby 1.8.4 / OS X > 10.4.10, and I've found that often when I shut down my server with > ^C, it hangs for a while, gobbling up all CPU. Sometimes it stops > after a few seconds, sometimes it's run for several minutes at least. > This happens across all the apps I develop on, but it seems to hang > longer after they've been heavily used for many hours / days. > > It's not a very big deal -- I just kill -9 it... but has anyone else > seen this? And suggestions as to how I can avoid it? > > Thanks! > -Nate > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From colo0logo at gmail.com Thu Dec 6 16:02:53 2007 From: colo0logo at gmail.com (colo) Date: Thu, 6 Dec 2007 16:02:53 -0500 Subject: [Mongrel] No matter what I do, Mongrel will not write pid files Message-ID: <886c3b3d0712061302yf6ff45exc7d2a518c8475479@mail.gmail.com> I have been trying to run mongrel_rails start -e production -p 41740 -P /home/user/railsftpapp/log/mongrel.41740.pid And cluster but it wont make a pid file ! It's driving me crazy.... Cluster verbose mongrel_rails start -d -e production -S /home/nhall/railsftpapp/config/mongrel_upload_progress.conf --user mongrel --group mongrel -p 41740 -P /home/nhall/railsftpapp/fake/mongrel.41740.pid -l log/mongrel.41740.log It's building the log files just file but no pid files I put the folder to 755 777 and put absolutes and locals CentOS 5 Rails 1.2.6 mongrel 1.1.1 From thomas.tmp at gmail.com Fri Dec 7 08:47:21 2007 From: thomas.tmp at gmail.com (Thomas Balthazar) Date: Fri, 7 Dec 2007 14:47:21 +0100 Subject: [Mongrel] Mongrel and memory usage In-Reply-To: References: <20071105180510.02A331858641@rubyforge.org> Message-ID: Hello, I just wanted to tell the list that I've spent some time to optimize my code a little, I've reworked some SQL queries, removed some part of Rails I wasn't using ... Now, both mongrel processes are stable at 150Mb each. T. On Nov 5, 2007 7:27 PM, Thomas Balthazar wrote: > > On 11/5/07, Steve Midgley wrote: > > At 09:17 AM 11/5/2007, you wrote: > > > > Which kink of issues with my code could use that much memory? > > > > If I load lots of records with Active Records, aren't they > > > "unloaded" at > > > > some times? > > > > > >Does your code or any of those pluginx use Array#shift? There was a > > >bug with Array#shift which still existed in 1.8.5 which basically left > > >stuff inside the array data structure after a shift, so that those > > >things didn't get GCd when they should have. It's a sneaky bug that > > >can easily eat a lot of memory. > > > > > >Otherwise, can you start a test instance of your application, and then > > >test it to see if there are certain actions which cause the memory > > >growth. That would help you pinpoint where the likely problems are. > > >Just use ab or httperf to send a large number of requests to specific > > >urls in your app, and see how ram usage changes as you do that. > > > > > > > > >Kirk Haines > > > > Thanks Kirk - I guess I'm totally OT at this point, but I hadn't heard > > about this bug before. From your description this is a specific problem > > to the underlying C code implementing shift, which is not found in > > related functions? So "array.slice!(0)" would be identical in function > > to shift but not contain this leak? > > > > Thanks again, > > > > Steve > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > Hello, > > Thanks everybody for all those informations. > I'll make some tests and I'll keep you posted. > I won't have the time to run those tests this week, but I won't forget > to post the results on the list. > > Best, > Thomas. > From jeremy at ibexinternet.co.uk Fri Dec 7 09:18:56 2007 From: jeremy at ibexinternet.co.uk (Jeremy Wilkins) Date: Fri, 7 Dec 2007 14:18:56 +0000 Subject: [Mongrel] Handling multiple requests at once Message-ID: Hi, I'm trying to write a custom handler for mongrel. My understanding is that whilst rails is not multithreaded, mongrel is - does this mean it should be able to handle multiple requests at once? I've written the following test code class HelloHandler < Mongrel::HttpHandler def process(request, response) response.start(200) do |head, out| head["Content-Type"] = "text/html" (1..50).each do |i| puts "Loop #{i}" sleep 3 end out.write("FINISHED") end end end uri "/hello", :handler => HelloHandler.new, :in_front => true Which just sleeps for a while outputting a counter to the command prompt before finishing. If I request this file multiple times the requests are run synchronously, not in parallel? Is there anything I can do to make mongrel process the requests in parallel? Thanks jebw From lists at ruby-forum.com Sat Dec 8 06:31:11 2007 From: lists at ruby-forum.com (Sj Seo) Date: Sat, 8 Dec 2007 12:31:11 +0100 Subject: [Mongrel] mongrel startup fails now: already initialized constant In-Reply-To: References: Message-ID: <6157d35f0b42389234242367d66e5971@ruby-forum.com> Stephen Bannasch wrote: > I updated to ruby 1.8.6p111 last night and updated some gems and now > mongrel doesn't work: > > MacOS 10.4.10 > > $ ruby --version > ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin8.10.1] > > $ gem list rails > > *** LOCAL GEMS *** > > rails (1.2.5, 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.6) > > Here's a simple test: > > $ rails test5 > create ... > > $ cd test5 > $ script/server > => Booting Mongrel (use 'script/server webrick' to force WEBrick) > => Rails application starting on http://0.0.0.0:3000 > => Call with -d to detach > => Ctrl-C to shutdown server > ** Starting Mongrel listening at 0.0.0.0:3000 > ** Starting Rails with development environment... > ** Rails loaded. > ** Loading any Rails specific GemPlugins > Exiting > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:15: > warning: already initialized constant OPTIONS > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:18: > undefined method `options' for []:Array (NoMethodError) > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in > `gem_original_require' > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in > `require' > from > /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in > `require' > from > /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in > `new_constants_in' > from > /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in > `require' > from > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/server.rb:39 > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require' > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > > Here were the gems I upgraded: > > $ gem outdated > Bulk updating Gem source index for: http://gems.rubyforge.org > fastercsv (1.2.0 < 1.2.1) > ruby-debug (0.8.1 < 0.9.3) > mofo (0.2.1 < 0.2.10) > mongrel (1.0.1 < 1.1.1) > rails (1.2.4 < 1.2.5) > actionwebservice (1.2.4 < 1.2.5) > ruby-debug-base (0.8.1 < 0.9.3) > activerecord (1.15.4 < 1.15.5) > tzinfo (0.3.3 < 0.3.5) > gem_plugin (0.2.2 < 0.2.3) > libxml-ruby (0.3.8.4.1 < 0.5.2.0) > ruport (0.8.12 < 1.2.2) > image_science (1.1.1 < 1.1.3) > erubis (2.2.0 < 2.4.1) > uuidtools (1.0.0 < 1.0.2) > cgi_multipart_eof_fix (2.1 < 2.5.0) > attributes (4.0.0 < 5.0.0) > net-ssh (1.0.10 < 1.1.2) > mongrel_cluster (1.0.2 < 1.0.4) > capistrano (1.4.1 < 2.1.0) > merb (0.2.0 < 0.4.1) > actionmailer (1.3.4 < 1.3.5) > actionpack (1.13.4 < 1.13.5) > json (1.0.1 < 1.1.1) > daemons (1.0.5 < 1.0.9) > RubyInline (3.6.2 < 3.6.5) > activesupport (1.4.3 < 1.4.4) > builder (2.1.1 < 2.1.2) > hpricot (0.5.110 < 0.6) > fastthread (1.0 < 1.0.1) > > from script/server:3 ---------------- I had a similar issue, but now I have resolved it. After I've installed some rails plugins on window xp, mongrel server didn't work. As I ran the rake task, 'rake rails:update', web server has worked. ## change to the root of rails project $ cd test5 ## check the rake tasks $ test5> rake --tasks ## run the 'rails:update' task $ test5> rake rails:update If you have installed the ruby 1.8.6 from souce package, maybe you must be re-install all the gem plugins(rails, rake, mysql, ...). ref. - http://scoop.cheerfactory.co.uk/2007/11/02/upgrading-ruby-on-ubuntu-dapper/ - http://wiki.ajaxstart.com/usemodj/browse.screen?Ruby_1.8.6_Source_Install -- Posted via http://www.ruby-forum.com/. From evan at cloudbur.st Sat Dec 8 11:52:47 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 8 Dec 2007 11:52:47 -0500 Subject: [Mongrel] mongrel startup fails now: already initialized constant In-Reply-To: <6157d35f0b42389234242367d66e5971@ruby-forum.com> References: <6157d35f0b42389234242367d66e5971@ruby-forum.com> Message-ID: Blanket gem updates is usually a bad idea. Evan On Dec 8, 2007 6:31 AM, Sj Seo wrote: > Stephen Bannasch wrote: > > I updated to ruby 1.8.6p111 last night and updated some gems and now > > mongrel doesn't work: > > > > MacOS 10.4.10 > > > > $ ruby --version > > ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin8.10.1] > > > > $ gem list rails > > > > *** LOCAL GEMS *** > > > > rails (1.2.5, 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.6) > > > > Here's a simple test: > > > > $ rails test5 > > create ... > > > > $ cd test5 > > $ script/server > > => Booting Mongrel (use 'script/server webrick' to force WEBrick) > > => Rails application starting on http://0.0.0.0:3000 > > => Call with -d to detach > > => Ctrl-C to shutdown server > > ** Starting Mongrel listening at 0.0.0.0:3000 > > ** Starting Rails with development environment... > > ** Rails loaded. > > ** Loading any Rails specific GemPlugins > > Exiting > > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:15: > > warning: already initialized constant OPTIONS > > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:18: > > undefined method `options' for []:Array (NoMethodError) > > from > > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in > > `gem_original_require' > > from > > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in > > `require' > > from > > /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in > > `require' > > from > > /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in > > `new_constants_in' > > from > > /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in > > `require' > > from > > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/server.rb:39 > > from > > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `gem_original_require' > > from > > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > > > Here were the gems I upgraded: > > > > $ gem outdated > > Bulk updating Gem source index for: http://gems.rubyforge.org > > fastercsv (1.2.0 < 1.2.1) > > ruby-debug (0.8.1 < 0.9.3) > > mofo (0.2.1 < 0.2.10) > > mongrel (1.0.1 < 1.1.1) > > rails (1.2.4 < 1.2.5) > > actionwebservice (1.2.4 < 1.2.5) > > ruby-debug-base (0.8.1 < 0.9.3) > > activerecord (1.15.4 < 1.15.5) > > tzinfo (0.3.3 < 0.3.5) > > gem_plugin (0.2.2 < 0.2.3) > > libxml-ruby (0.3.8.4.1 < 0.5.2.0) > > ruport (0.8.12 < 1.2.2) > > image_science (1.1.1 < 1.1.3) > > erubis (2.2.0 < 2.4.1) > > uuidtools (1.0.0 < 1.0.2) > > cgi_multipart_eof_fix (2.1 < 2.5.0) > > attributes (4.0.0 < 5.0.0) > > net-ssh (1.0.10 < 1.1.2) > > mongrel_cluster (1.0.2 < 1.0.4) > > capistrano (1.4.1 < 2.1.0) > > merb (0.2.0 < 0.4.1) > > actionmailer (1.3.4 < 1.3.5) > > actionpack (1.13.4 < 1.13.5) > > json (1.0.1 < 1.1.1) > > daemons (1.0.5 < 1.0.9) > > RubyInline (3.6.2 < 3.6.5) > > activesupport (1.4.3 < 1.4.4) > > builder (2.1.1 < 2.1.2) > > hpricot (0.5.110 < 0.6) > > fastthread (1.0 < 1.0.1) > > > > from script/server:3 > > > ---------------- > > I had a similar issue, but now I have resolved it. > After I've installed some rails plugins on window xp, > mongrel server didn't work. > > As I ran the rake task, 'rake rails:update', > web server has worked. > > ## change to the root of rails project > $ cd test5 > > ## check the rake tasks > $ test5> rake --tasks > > ## run the 'rails:update' task > $ test5> rake rails:update > > If you have installed the ruby 1.8.6 from souce package, > maybe you must be re-install all the gem plugins(rails, rake, mysql, > ...). > > ref. > - > http://scoop.cheerfactory.co.uk/2007/11/02/upgrading-ruby-on-ubuntu-dapper/ > - > http://wiki.ajaxstart.com/usemodj/browse.screen?Ruby_1.8.6_Source_Install > > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From yves.dastous at intertrade.com Mon Dec 10 13:38:19 2007 From: yves.dastous at intertrade.com (Yves D'Astous) Date: Mon, 10 Dec 2007 13:38:19 -0500 Subject: [Mongrel] Mongrel and http 1.1 OPTIONS keyword Message-ID: <475D879B.1080200@intertrade.com> Hello. I just seen some errors in my mongrel application log: It seems related to the httpd OPTIONS keyword Example: Processing LoginController#login (for .30.5.208 at 2007-12-10 09:00:23) [OPTIONS] and our ruby application does not know what to do with it. and finally send an error Does mongrel (which is the http server) is supposed to deal with these kind of request ? I think these request are coming from a MS Front Page application, what other are doing when these requests happen ? Yves D'Astous From zedshaw at zedshaw.com Mon Dec 10 19:57:18 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Mon, 10 Dec 2007 19:57:18 -0500 Subject: [Mongrel] Mongrel and http 1.1 OPTIONS keyword In-Reply-To: <475D879B.1080200@intertrade.com> References: <475D879B.1080200@intertrade.com> Message-ID: <20071210195718.533bb381.zedshaw@zedshaw.com> On Mon, 10 Dec 2007 13:38:19 -0500 Yves D'Astous wrote: > Hello. > > I just seen some errors in my mongrel application log: > > It seems related to the httpd OPTIONS keyword > > Example: > Processing LoginController#login (for .30.5.208 at 2007-12-10 09:00:23) > [OPTIONS] > and our ruby application does not know what to do with it. and finally > send an error > > Does mongrel (which is the http server) is supposed to deal with these > kind of request ? > I think these request are coming from a MS Front Page application, what > other are doing when these requests happen ? If you need to tell options to remote servers then you can write the handler that returns them. Most applications don't need this since they run rails, and usually the web app would have a different interpretation for each option they wanted. Otherwise, I suggest telling your front server to quit asking that. It's dubious feature at best which doesn't do anything for a proxy server situation. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From lists at ruby-forum.com Tue Dec 11 08:03:28 2007 From: lists at ruby-forum.com (Phil Thompson) Date: Tue, 11 Dec 2007 14:03:28 +0100 Subject: [Mongrel] Mongrel install crash on win32 In-Reply-To: <71166b3b0711280816x4241035p5a01cda3ff540761@mail.gmail.com> References: <78de7f038919ce30d788674eee2c3bea@ruby-forum.com> <71166b3b0711270438i3a2320cbx9ba9b31f2ece6278@mail.gmail.com> <7994e5929e93182b0dc518ef1cf5ce4a@ruby-forum.com> <71166b3b0711280816x4241035p5a01cda3ff540761@mail.gmail.com> Message-ID: <90a27ccce8cbbdf12ca03a36b69df66e@ruby-forum.com> > > Regarding your problem, you should have: > > Downloaded rubygems-0.9.4.zip from rubyforge page [1] > > Unpacked into any clean folder, > > run: ruby setup.rb install > > that should have overwrite your 0.9.5 installation. > > If that didn't work as expected, you an also remove > lib/ruby/site_ruby/1.8 the files and folders for rubygems: > > ubygems.rb rubygems.rb and rubygems folder. > > Then install 0.9.4 again as described above. ... Before I could do "ruby setup.rb install" I needed to do "ruby setup.rb config". 0.9.4 then installed although it seemed to install the docs for 0.9.5. Thanks for this. -- Posted via http://www.ruby-forum.com/. From luislavena at gmail.com Tue Dec 11 09:42:52 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 11 Dec 2007 11:42:52 -0300 Subject: [Mongrel] Mongrel install crash on win32 In-Reply-To: <90a27ccce8cbbdf12ca03a36b69df66e@ruby-forum.com> References: <78de7f038919ce30d788674eee2c3bea@ruby-forum.com> <71166b3b0711270438i3a2320cbx9ba9b31f2ece6278@mail.gmail.com> <7994e5929e93182b0dc518ef1cf5ce4a@ruby-forum.com> <71166b3b0711280816x4241035p5a01cda3ff540761@mail.gmail.com> <90a27ccce8cbbdf12ca03a36b69df66e@ruby-forum.com> Message-ID: <71166b3b0712110642g5de49e3dwac58e63f905b9ecc@mail.gmail.com> On Dec 11, 2007 10:03 AM, Phil Thompson wrote: > ... > > Before I could do "ruby setup.rb install" I needed to do "ruby setup.rb > config". 0.9.4 then installed although it seemed to install the docs for > 0.9.5. > Oh, I always forget about config _before_ install :-P The 0.9.5 docs can be removed from lib/ruby/gems/1.8/doc I hope Eric and the RubyGems team release a fix soon, removes the joy of using Ruby... -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From robjlucas at googlemail.com Tue Dec 11 10:27:49 2007 From: robjlucas at googlemail.com (rob lucas) Date: Tue, 11 Dec 2007 15:27:49 +0000 Subject: [Mongrel] Mongrel install problem Message-ID: <486be5dc0712110727x44e44e78gf484befb4f75c7a4@mail.gmail.com> Hi, I'm having difficulties getting mongrel running on my Debian Etch machine. It seems to install and is listed with my other gems, but things like... "mongrel_rails start ..." ... are not recognised. Perhaps this is something to do with the file "lib" not being found in the install process: ruby extconf.rb install mongrel --include-dependencies checking for main() in -lc... no creating Makefile make make install make clean Successfully installed mongrel-1.1.1 Successfully installed fastthread-1.0.1 Installing ri documentation for mongrel-1.1.1... Installing ri documentation for fastthread-1.0.1... File not found: lib I've done the usual Googling for solutions to this, but no luck so far. Any help would be appreciated. Thanks, Rob. From jazzyy at gmail.com Tue Dec 11 10:19:14 2007 From: jazzyy at gmail.com (Nii Amon Dsane) Date: Tue, 11 Dec 2007 15:19:14 +0000 Subject: [Mongrel] Mongrel not starting: `initialize_without_backlog': Cannot assign requested address - bind(2) (Errno::EADDRNOTAVAIL) Message-ID: <7cf2a5480712110719v16d447cen14f1585218ada0e2@mail.gmail.com> Hi I have a rather strange problem with mongrel and I would be grateful if anyone could assist me with resolving. I have an application running mongrel 1.1.1 and rails 1.2.5 with ruby 1.8.6. It was all working fine and starting as expected. But I did a server reboot once and mongrel has refused to start up since. I get the following error: /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/tcphack.rb:12:in `initialize_without_backlog': Cannot assign requested address - bind(2) (Errno::EADDRNOTAVAIL) from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/tcphack.rb:12:in `initialize' from /usr/lib/ruby/1.8/drb/drb.rb:865:in `open' from /usr/lib/ruby/1.8/drb/drb.rb:865:in `open_server' from /usr/lib/ruby/1.8/drb/drb.rb:759:in `open_server' from /usr/lib/ruby/1.8/drb/drb.rb:757:in `each' from /usr/lib/ruby/1.8/drb/drb.rb:757:in `open_server' from /usr/lib/ruby/1.8/drb/drb.rb:1339:in `initialize' from /usr/lib/ruby/1.8/drb/drb.rb:1627:in `new' ... 31 levels... from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/command.rb:212:in `run' from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:281 from /usr/bin/mongrel_rails:16:in `load' from /usr/bin/mongrel_rails:16 Initially I though that it was due to the fact that somehow there were processes that were holding onto the ports so I did a netstat to check for listening processes. However there were no processes holding onto the ports. I suspect that it is something that is in the configuration for that particular application because there are other applications on the server which are still working fine. Has anyone else experienced this before and what was the resolution. Thanks Nii Amon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071211/a00c7db9/attachment-0001.html From michael.dauria at gmail.com Tue Dec 11 12:31:10 2007 From: michael.dauria at gmail.com (Michael D'Auria) Date: Tue, 11 Dec 2007 12:31:10 -0500 Subject: [Mongrel] Mongrel not starting: `initialize_without_backlog': Cannot assign requested address - bind(2) (Errno::EADDRNOTAVAIL) In-Reply-To: <7cf2a5480712110719v16d447cen14f1585218ada0e2@mail.gmail.com> References: <7cf2a5480712110719v16d447cen14f1585218ada0e2@mail.gmail.com> Message-ID: <1907e2ca0712110931l6dfbace6tfe5dcee151debc27@mail.gmail.com> Hi Nii, Looks like something else is already running on the port that Mongrel wants, 3000 by default. See if you have any other mongrels running (ps -ef) or better yet, bring up http://localhost:3000 and see what's running. Michael On Dec 11, 2007 10:19 AM, Nii Amon Dsane wrote: > Hi > I have a rather strange problem with mongrel and I would be grateful if > anyone could assist me with resolving. > > I have an application running mongrel 1.1.1 and rails 1.2.5 with ruby > 1.8.6. It was all working fine and starting as expected. But I did a > server reboot once and mongrel has refused to start up since. I get the > following error: > > /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/tcphack.rb:12:in > `initialize_without_backlog': Cannot assign requested address - bind(2) > (Errno::EADDRNOTAVAIL) > from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/tcphack.rb:12:in > `initialize' > from /usr/lib/ruby/1.8/drb/drb.rb:865:in `open' > from /usr/lib/ruby/1.8/drb/drb.rb:865:in `open_server' > from /usr/lib/ruby/1.8/drb/drb.rb:759:in `open_server' > from /usr/lib/ruby/1.8/drb/drb.rb:757:in `each' > from /usr/lib/ruby/1.8/drb/drb.rb:757:in `open_server' > from /usr/lib/ruby/1.8/drb/drb.rb:1339:in `initialize' > from /usr/lib/ruby/1.8/drb/drb.rb:1627:in `new' > ... 31 levels... > from /usr/lib/ruby/gems/1.8/gems/mongrel- 1.1.1/bin/../lib/mongrel/command.rb:212:in > `run' > from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1 > /bin/mongrel_rails:281 > from /usr/bin/mongrel_rails:16:in `load' > from /usr/bin/mongrel_rails:16 > > Initially I though that it was due to the fact that somehow there were > processes that were holding onto the ports so I did a netstat to check for > listening processes. However there were no processes holding onto the > ports. > > I suspect that it is something that is in the configuration for that > particular application because there are other applications on the server > which are still working fine. > > Has anyone else experienced this before and what was the resolution. > > Thanks > Nii Amon > > _______________________________________________ > 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/20071211/9a3e71e9/attachment.html From sobrien at yahoo-inc.com Tue Dec 11 12:31:34 2007 From: sobrien at yahoo-inc.com (Sean O'Brien) Date: Tue, 11 Dec 2007 09:31:34 -0800 Subject: [Mongrel] Mongrel install problem In-Reply-To: <486be5dc0712110727x44e44e78gf484befb4f75c7a4@mail.gmail.com> References: <486be5dc0712110727x44e44e78gf484befb4f75c7a4@mail.gmail.com> Message-ID: <570BBEFE-51FD-4635-A652-8B1D0FACE930@yahoo-inc.com> I had the same issue on Etch, try adding '/var/lib/gems/1.8/bin/' to your path - see if that works. - sob On Dec 11, 2007, at 7:27 AM, rob lucas wrote: > Hi, > > I'm having difficulties getting mongrel running on my Debian Etch > machine. It seems to install and is listed with my other gems, but > things like... > "mongrel_rails start ..." > ... are not recognised. > > Perhaps this is something to do with the file "lib" not being found in > the install process: > > ruby extconf.rb install mongrel --include-dependencies > checking for main() in -lc... no > creating Makefile > > make > > make install > > make clean > Successfully installed mongrel-1.1.1 > Successfully installed fastthread-1.0.1 > Installing ri documentation for mongrel-1.1.1... > Installing ri documentation for fastthread-1.0.1... > File not found: lib > > I've done the usual Googling for solutions to this, but no luck so > far. Any help would be appreciated. > > Thanks, > > Rob. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From wyhaines at gmail.com Tue Dec 11 12:50:34 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Tue, 11 Dec 2007 10:50:34 -0700 Subject: [Mongrel] Mongrel and http 1.1 OPTIONS keyword In-Reply-To: <475D879B.1080200@intertrade.com> References: <475D879B.1080200@intertrade.com> Message-ID: On Dec 10, 2007 11:38 AM, Yves D'Astous wrote: > Does mongrel (which is the http server) is supposed to deal with these > kind of request ? Mongrel is the HTTP server, but _Mongrel_ itself should not be dealing with OPTIONS reqests. Mongrel doesn't know what the correct answer is for a given request because the responsibility for handling a request falls onto the shoulders of some handler or other. In the case of a handler like DirHandler, which itself directly handles the request, it would make sense for the handler to return the response because the handler knows what is reasonable for a given request. However, in the case of a handler like the RailsHandler, where the handler just passes control to another entity (the application), that entity is the only thing that can return a meaningful response to an OPTIONS request -- the handler doesn't know what the application is willing to handle for a given request. I think that the value in changing the standard Mongrel handlers, like DirHandler, to deal with OPTIONS is meager, at best, though. As easy as it is in Ruby to either subclass or just reopen a class and change parts of it, I'd suggest that if one really _needs_ to do something like handle OPTIONS, that they just create a custom handler for their application which will do so in a way that makes sense for them. And if your Rails app really needs to handle OPTIONS, can't you just do that? Kirk Haines From jazzyy at gmail.com Tue Dec 11 13:39:56 2007 From: jazzyy at gmail.com (Nii Amon Dsane) Date: Tue, 11 Dec 2007 18:39:56 +0000 Subject: [Mongrel] Mongrel not starting: `initialize_without_backlog': Cannot assign requested address - bind(2) (Errno::EADDRNOTAVAIL) In-Reply-To: <7cf2a5480712110719v16d447cen14f1585218ada0e2@mail.gmail.com> References: <7cf2a5480712110719v16d447cen14f1585218ada0e2@mail.gmail.com> Message-ID: <7cf2a5480712111039v5df20961ta6cca0905ebb2a70@mail.gmail.com> Hi Michael I can verify that there is no other application on that port: I setup a dummy app on the server and started it on the port 3013 which my app is trying to access. That worked without any problems. Therefore I think that it is something more to do with my own app than perhaps with a held port. Thanks Nii Amon On Dec 11, 2007 3:19 PM, Nii Amon Dsane wrote: > Hi > I have a rather strange problem with mongrel and I would be grateful if > anyone could assist me with resolving. > > I have an application running mongrel 1.1.1 and rails 1.2.5 with ruby > 1.8.6. It was all working fine and starting as expected. But I did a > server reboot once and mongrel has refused to start up since. I get the > following error: > > /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/tcphack.rb:12:in > `initialize_without_backlog': Cannot assign requested address - bind(2) > (Errno::EADDRNOTAVAIL) > from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/tcphack.rb:12:in > `initialize' > from /usr/lib/ruby/1.8/drb/drb.rb:865:in `open' > from /usr/lib/ruby/1.8/drb/drb.rb:865:in `open_server' > from /usr/lib/ruby/1.8/drb/drb.rb:759:in `open_server' > from /usr/lib/ruby/1.8/drb/drb.rb:757:in `each' > from /usr/lib/ruby/1.8/drb/drb.rb:757:in `open_server' > from /usr/lib/ruby/1.8/drb/drb.rb:1339:in `initialize' > from /usr/lib/ruby/1.8/drb/drb.rb:1627:in `new' > ... 31 levels... > from /usr/lib/ruby/gems/1.8/gems/mongrel- 1.1.1/bin/../lib/mongrel/command.rb:212:in > `run' > from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1 > /bin/mongrel_rails:281 > from /usr/bin/mongrel_rails:16:in `load' > from /usr/bin/mongrel_rails:16 > > Initially I though that it was due to the fact that somehow there were > processes that were holding onto the ports so I did a netstat to check for > listening processes. However there were no processes holding onto the > ports. > > I suspect that it is something that is in the configuration for that > particular application because there are other applications on the server > which are still working fine. > > Has anyone else experienced this before and what was the resolution. > > Thanks > Nii Amon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071211/2ff306e0/attachment.html From alexey.verkhovsky at gmail.com Tue Dec 11 17:47:50 2007 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Tue, 11 Dec 2007 15:47:50 -0700 Subject: [Mongrel] Mongrel and http 1.1 OPTIONS keyword In-Reply-To: References: <475D879B.1080200@intertrade.com> Message-ID: <3945c4270712111447r6f4c54e9m94703ec600496e60@mail.gmail.com> On Dec 11, 2007 10:50 AM, Kirk Haines wrote: > And if your Rails app really needs to handle OPTIONS, can't you just do that? I've heard of using OPTIONS requests to monitor HTTP servers, on the assumption that it's a really cheap operation with no side effects. But never saw it firsthand. > I think that the value in changing the standard Mongrel handlers, like DirHandler, to deal with OPTIONS is meager, at best, though. +1 -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From wyhaines at gmail.com Tue Dec 11 18:11:34 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Tue, 11 Dec 2007 16:11:34 -0700 Subject: [Mongrel] Mongrel and http 1.1 OPTIONS keyword In-Reply-To: <3945c4270712111447r6f4c54e9m94703ec600496e60@mail.gmail.com> References: <475D879B.1080200@intertrade.com> <3945c4270712111447r6f4c54e9m94703ec600496e60@mail.gmail.com> Message-ID: On Dec 11, 2007 3:47 PM, Alexey Verkhovsky wrote: > On Dec 11, 2007 10:50 AM, Kirk Haines wrote: > > And if your Rails app really needs to handle OPTIONS, can't you just do that? > > I've heard of using OPTIONS requests to monitor HTTP servers, on the > assumption that it's a really cheap operation with no side effects. > But never saw it firsthand. Yeah. Using an asterisk as the request uri. That's the only OPTIONS request that I can see an argument for Mongrel directly supporting. Does anyone know of any concrete examples where that use case is necessary or desireable? Kirk Haines From andy.koch at pc-doctor.com Tue Dec 11 20:02:23 2007 From: andy.koch at pc-doctor.com (Andy Koch) Date: Tue, 11 Dec 2007 17:02:23 -0800 Subject: [Mongrel] sendfile and mongrel Message-ID: forgive me if this has been resolved already... I have an app that is using sendfile to return large files to customers. We can't use regular Apache to handle this static content since the files are what the customers are paying for - so it wouldn't be cool for anyone else to get access to them. The issue is that the mongrel mem footprint gets bloated when the files are transferred and this mem does not get returned to the system. I've looked into x-sendfile, but it doesn't appear to be compatible with Apache 2.2. Now the question, does the current mongrel 1.1.1 have this same issue with sendfile and memory bloating? (I'm currently running 1.0.1) Are there any other recommendations for handling this situation? thanks From matte at ruckuswireless.com Tue Dec 11 21:52:51 2007 From: matte at ruckuswireless.com (Matte Edens) Date: Tue, 11 Dec 2007 18:52:51 -0800 Subject: [Mongrel] sendfile and mongrel In-Reply-To: References: Message-ID: <475F4D03.4090700@ruckuswireless.com> I use X_SendFile with Apache 2.2 just fine. FYI. And wouldn't it be possible to intercept all download requests and force use of a cookie/session authorization requirement? I do it on one of my websites. The X_SendFile feature doesn't actually send the server location of the file and if you used a url such as ... http://website/download/[filename] /download/ is an action in one of my controllers and it requires a valid login session. I do a query on the filename and if you're not authorized for the file you don't get to download. All downloads are stored outside the website directory so no direct linking is available. Then I use the x_send_file feature to have apache serve up the file without going through mongrel. There's also a nice x_send_file plugin that replaces "send_file" with an "x_send_file" call, so code updates should be at a minimum. matte Andy Koch wrote: > forgive me if this has been resolved already... > > I have an app that is using sendfile to return large files to customers. > We can't use regular Apache to handle this static content since the > files are what the customers are paying for - so it wouldn't be cool for > anyone else to get access to them. > > The issue is that the mongrel mem footprint gets bloated when the files > are transferred and this mem does not get returned to the system. > > I've looked into x-sendfile, but it doesn't appear to be compatible with > Apache 2.2. > > Now the question, does the current mongrel 1.1.1 have this same issue > with sendfile and memory bloating? (I'm currently running 1.0.1) > > Are there any other recommendations for handling this situation? > > thanks > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From brian.gupta at gmail.com Wed Dec 12 04:13:13 2007 From: brian.gupta at gmail.com (Brian Gupta) Date: Wed, 12 Dec 2007 04:13:13 -0500 Subject: [Mongrel] Upgrading from Mongrel 1.0.1 and Mongrel cluster 0.2.1 Message-ID: <5b5090780712120113w69cc0bf4g44d3cea875aa21ac@mail.gmail.com> I am considering upgrading to either Mongrel 1.1.1 or 1.0.4, and Mongrel-cluster to 1.0.5. Are there any gotchas or issues I need to be aware of? Also where can I find the release notes for the various releases? (The ones I found seem very sparse). Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071212/b4b64f52/attachment.html From roblucas at lucasandblench.com Wed Dec 12 08:24:44 2007 From: roblucas at lucasandblench.com (rob lucas) Date: Wed, 12 Dec 2007 13:24:44 +0000 Subject: [Mongrel] Mongrel-users Digest, Vol 23, Issue 4 In-Reply-To: References: Message-ID: <486be5dc0712120524s572473a7r9ed53bb3cc14f9ff@mail.gmail.com> Thanks for the help Sean. I managed to get the install fixed, but I'm still having problems. When I do mongrel_rails start, the process just gets stuck and never completes. If I interrupt it I get the following... ** Ruby version is not up-to-date; loading cgi_multipart_eof_fix /usr/lib/ruby/1.8/rubygems/source_index.rb:186:in `search': Interrupt from /usr/lib/ruby/1.8/rubygems/source_index.rb:185:in `each' from /usr/lib/ruby/1.8/rubygems/source_index.rb:185:in `search' from /usr/lib/ruby/1.8/rubygems/source_index.rb:165:in `find_name' from /usr/lib/ruby/1.8/rubygems.rb:195:in `activate' from /usr/lib/ruby/1.8/rubygems.rb:65:in `active_gem_with_options' from /usr/lib/ruby/1.8/rubygems.rb:49:in `gem' from /var/lib/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/gems.rb:12:in `require' from /var/lib/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel.rb:13 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require' from /var/lib/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:11 from /usr/bin/mongrel_rails:16:in `load' from /usr/bin/mongrel_rails:16 ... which indicates it is getting stuck in the block of this search method: def search(gem_pattern, version_requirement=Version::Requirement.new(">= 0")) #FIXME - remove duplication between this and RemoteInstaller.search gem_pattern = /^#{ gem_pattern }$/i if String === gem_pattern version_requirement = Gem::Version::Requirement.create(version_requirement) result = [] @gems.each do |full_spec_name, spec| next unless spec.name =~ gem_pattern result << spec if version_requirement.satisfied_by?(spec.version) end result = result.sort result end Any ideas why? Thanks, Rob. > Date: Tue, 11 Dec 2007 09:31:34 -0800 > From: "Sean O'Brien" > Subject: Re: [Mongrel] Mongrel install problem > To: mongrel-users at rubyforge.org > Message-ID: <570BBEFE-51FD-4635-A652-8B1D0FACE930 at yahoo-inc.com> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > I had the same issue on Etch, try adding '/var/lib/gems/1.8/bin/' to > your path - see if that works. > > - sob > > On Dec 11, 2007, at 7:27 AM, rob lucas wrote: > > > Hi, > > > > I'm having difficulties getting mongrel running on my Debian Etch > > machine. It seems to install and is listed with my other gems, but > > things like... > > "mongrel_rails start ..." > > ... are not recognised. > > > > Perhaps this is something to do with the file "lib" not being found in > > the install process: > > > > ruby extconf.rb install mongrel --include-dependencies > > checking for main() in -lc... no > > creating Makefile > > > > make > > > > make install > > > > make clean > > Successfully installed mongrel-1.1.1 > > Successfully installed fastthread-1.0.1 > > Installing ri documentation for mongrel-1.1.1... > > Installing ri documentation for fastthread-1.0.1... > > File not found: lib > > > > I've done the usual Googling for solutions to this, but no luck so > > far. Any help would be appreciated. > > > > Thanks, > > > > Rob. From jgeiger at gmail.com Wed Dec 12 09:33:53 2007 From: jgeiger at gmail.com (Joey Geiger) Date: Wed, 12 Dec 2007 08:33:53 -0600 Subject: [Mongrel] Upgrading from Mongrel 1.0.1 and Mongrel cluster 0.2.1 In-Reply-To: <5b5090780712120113w69cc0bf4g44d3cea875aa21ac@mail.gmail.com> References: <5b5090780712120113w69cc0bf4g44d3cea875aa21ac@mail.gmail.com> Message-ID: <466af3440712120633r40dadebeh56dd842a972d900a@mail.gmail.com> I just did this on a bunch of servers and didn't run into any issues, thought your case may be different. On Dec 12, 2007 3:13 AM, Brian Gupta wrote: > I am considering upgrading to either Mongrel 1.1.1 or 1.0.4, and > Mongrel-cluster to 1.0.5. Are there any gotchas or issues I need to be aware > of? Also where can I find the release notes for the various releases? (The > ones I found seem very sparse). > > Thanks, > Brian > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From robjlucas at googlemail.com Wed Dec 12 09:46:35 2007 From: robjlucas at googlemail.com (rob lucas) Date: Wed, 12 Dec 2007 14:46:35 +0000 Subject: [Mongrel] Mongrel install problem Message-ID: <486be5dc0712120646p23e39e5boa34667ac203bea44@mail.gmail.com> (apologies for double-posting this. I just realised that the original had the digest title, and thus broke the thread.) Thanks for the help Sean. I managed to get the install fixed, but I'm still having problems. When I do mongrel_rails start, the process just gets stuck and never completes. If I interrupt it I get the following... ** Ruby version is not up-to-date; loading cgi_multipart_eof_fix /usr/lib/ruby/1.8/rubygems/source_index.rb:186:in `search': Interrupt from /usr/lib/ruby/1.8/rubygems/source_index.rb:185:in `each' from /usr/lib/ruby/1.8/rubygems/source_index.rb:185:in `search' from /usr/lib/ruby/1.8/rubygems/source_index.rb:165:in `find_name' from /usr/lib/ruby/1.8/rubygems.rb:195:in `activate' from /usr/lib/ruby/1.8/rubygems.rb:65:in `active_gem_with_options' from /usr/lib/ruby/1.8/rubygems.rb:49:in `gem' from /var/lib/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/gems.rb:12:in `require' from /var/lib/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel.rb:13 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require' from /var/lib/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:11 from /usr/bin/mongrel_rails:16:in `load' from /usr/bin/mongrel_rails:16 ... which indicates it is getting stuck in the block of this search method: def search(gem_pattern, version_requirement=Version::Requirement.new(">= 0")) #FIXME - remove duplication between this and RemoteInstaller.search gem_pattern = /^#{ gem_pattern }$/i if String === gem_pattern version_requirement = Gem::Version::Requirement.create(version_requirement) result = [] @gems.each do |full_spec_name, spec| next unless spec.name =~ gem_pattern result << spec if version_requirement.satisfied_by?(spec.version) end result = result.sort result end Any ideas why? Thanks, Rob. > Date: Tue, 11 Dec 2007 09:31:34 -0800 > From: "Sean O'Brien" > Subject: Re: [Mongrel] Mongrel install problem > To: mongrel-users at rubyforge.org > Message-ID: <570BBEFE-51FD-4635-A652-8B1D0FACE930 at yahoo-inc.com> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > I had the same issue on Etch, try adding '/var/lib/gems/1.8/bin/' to > your path - see if that works. > > - sob > > On Dec 11, 2007, at 7:27 AM, rob lucas wrote: > > > Hi, > > > > I'm having difficulties getting mongrel running on my Debian Etch > > machine. It seems to install and is listed with my other gems, but > > things like... > > "mongrel_rails start ..." > > ... are not recognised. > > > > Perhaps this is something to do with the file "lib" not being found in > > the install process: > > > > ruby extconf.rb install mongrel --include-dependencies > > checking for main() in -lc... no > > creating Makefile > > > > make > > > > make install > > > > make clean > > Successfully installed mongrel-1.1.1 > > Successfully installed fastthread-1.0.1 > > Installing ri documentation for mongrel-1.1.1... > > Installing ri documentation for fastthread-1.0.1... > > File not found: lib > > > > I've done the usual Googling for solutions to this, but no luck so > > far. Any help would be appreciated. > > > > Thanks, > > > > Rob. From jgeiger at gmail.com Wed Dec 12 10:12:22 2007 From: jgeiger at gmail.com (Joey Geiger) Date: Wed, 12 Dec 2007 09:12:22 -0600 Subject: [Mongrel] Mongrel install problem In-Reply-To: <486be5dc0712120646p23e39e5boa34667ac203bea44@mail.gmail.com> References: <486be5dc0712120646p23e39e5boa34667ac203bea44@mail.gmail.com> Message-ID: <466af3440712120712n187b85ej8f478d32df3e65f9@mail.gmail.com> >>Ruby version is not up-to-date; loading cgi_multipart_eof_fix It seems the version of ruby you're using needs to be updated. If you're installing from a package, and not from source, you may be at the mercy of the maintainers to update. On Dec 12, 2007 8:46 AM, rob lucas wrote: > (apologies for double-posting this. I just realised that the original > had the digest title, and thus broke the thread.) > > Thanks for the help Sean. I managed to get the install fixed, but I'm > still having problems. When I do mongrel_rails start, the process just > gets stuck and never completes. If I interrupt it I get the > following... > > ** Ruby version is not up-to-date; loading cgi_multipart_eof_fix > /usr/lib/ruby/1.8/rubygems/source_index.rb:186:in `search': Interrupt > from /usr/lib/ruby/1.8/rubygems/source_index.rb:185:in `each' > from /usr/lib/ruby/1.8/rubygems/source_index.rb:185:in `search' > from /usr/lib/ruby/1.8/rubygems/source_index.rb:165:in `find_name' > from /usr/lib/ruby/1.8/rubygems.rb:195:in `activate' > from /usr/lib/ruby/1.8/rubygems.rb:65:in `active_gem_with_options' > from /usr/lib/ruby/1.8/rubygems.rb:49:in `gem' > from /var/lib/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/gems.rb:12:in > `require' > from /var/lib/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel.rb:13 > from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require' > from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require' > from /var/lib/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:11 > from /usr/bin/mongrel_rails:16:in `load' > from /usr/bin/mongrel_rails:16 > > ... which indicates it is getting stuck in the block of this search method: > > def search(gem_pattern, > version_requirement=Version::Requirement.new(">= 0")) > #FIXME - remove duplication between this and RemoteInstaller.search > gem_pattern = /^#{ gem_pattern }$/i if String === gem_pattern > version_requirement = > Gem::Version::Requirement.create(version_requirement) > result = [] > @gems.each do |full_spec_name, spec| > next unless spec.name =~ gem_pattern > result << spec if version_requirement.satisfied_by?(spec.version) > end > result = result.sort > result > end > > Any ideas why? > > Thanks, > > Rob. > > > > > > Date: Tue, 11 Dec 2007 09:31:34 -0800 > > From: "Sean O'Brien" > > Subject: Re: [Mongrel] Mongrel install problem > > To: mongrel-users at rubyforge.org > > Message-ID: <570BBEFE-51FD-4635-A652-8B1D0FACE930 at yahoo-inc.com> > > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > > > I had the same issue on Etch, try adding '/var/lib/gems/1.8/bin/' to > > your path - see if that works. > > > > - sob > > > > On Dec 11, 2007, at 7:27 AM, rob lucas wrote: > > > > > Hi, > > > > > > I'm having difficulties getting mongrel running on my Debian Etch > > > machine. It seems to install and is listed with my other gems, but > > > things like... > > > "mongrel_rails start ..." > > > ... are not recognised. > > > > > > Perhaps this is something to do with the file "lib" not being found in > > > the install process: > > > > > > ruby extconf.rb install mongrel --include-dependencies > > > checking for main() in -lc... no > > > creating Makefile > > > > > > make > > > > > > make install > > > > > > make clean > > > Successfully installed mongrel-1.1.1 > > > Successfully installed fastthread-1.0.1 > > > Installing ri documentation for mongrel-1.1.1... > > > Installing ri documentation for fastthread-1.0.1... > > > File not found: lib > > > > > > I've done the usual Googling for solutions to this, but no luck so > > > far. Any help would be appreciated. > > > > > > Thanks, > > > > > > Rob. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From njvack at wisc.edu Wed Dec 12 10:27:54 2007 From: njvack at wisc.edu (Nathan Vack) Date: Wed, 12 Dec 2007 09:27:54 -0600 Subject: [Mongrel] sendfile and mongrel In-Reply-To: <475F4D03.4090700@ruckuswireless.com> References: <475F4D03.4090700@ruckuswireless.com> Message-ID: <2EF15B1C-DA62-4CF9-8EE8-6E540A01BBA6@wisc.edu> Before I discovered x-sendfile, I used to handle file uploads with PHP -- talking to the same database as my main Rails app. PHP doesn't bloat when dumping files across the wire like Ruby does. Remember: you don't need to use Rails / Mongrel for everything -- sometimes switching to another platform to solve a particular problem can be the easiest, most robust solution. But in this case: x-sendfile FTW. Deny from all in your files directory, and apache will send via x-sendfile but won't allow clients to download them directly. -n On Dec 11, 2007, at 8:52 PM, Matte Edens wrote: > I use X_SendFile with Apache 2.2 just fine. FYI. > > And wouldn't it be possible to intercept all download requests and > force > use of a cookie/session authorization requirement? I do it on one > of my > websites. The X_SendFile feature doesn't actually send the server > location of the file and if you used a url such as ... > > http://website/download/[filename] > > /download/ is an action in one of my controllers and it requires a > valid > login session. I do a query on the filename and if you're not > authorized for the file you don't get to download. All downloads are > stored outside the website directory so no direct linking is > available. > Then I use the x_send_file feature to have apache serve up the file > without going through mongrel. > > There's also a nice x_send_file plugin that replaces "send_file" > with an > "x_send_file" call, so code updates should be at a minimum. > > matte > > Andy Koch wrote: >> forgive me if this has been resolved already... >> >> I have an app that is using sendfile to return large files to >> customers. >> We can't use regular Apache to handle this static content since the >> files are what the customers are paying for - so it wouldn't be >> cool for >> anyone else to get access to them. >> >> The issue is that the mongrel mem footprint gets bloated when the >> files >> are transferred and this mem does not get returned to the system. >> >> I've looked into x-sendfile, but it doesn't appear to be >> compatible with >> Apache 2.2. >> >> Now the question, does the current mongrel 1.1.1 have this same issue >> with sendfile and memory bloating? (I'm currently running 1.0.1) >> >> Are there any other recommendations for handling this situation? >> >> thanks >> >> _______________________________________________ >> 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 wyhaines at gmail.com Wed Dec 12 12:11:47 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 12 Dec 2007 10:11:47 -0700 Subject: [Mongrel] sendfile and mongrel In-Reply-To: <2EF15B1C-DA62-4CF9-8EE8-6E540A01BBA6@wisc.edu> References: <475F4D03.4090700@ruckuswireless.com> <2EF15B1C-DA62-4CF9-8EE8-6E540A01BBA6@wisc.edu> Message-ID: On Dec 12, 2007 8:27 AM, Nathan Vack wrote: > Before I discovered x-sendfile, I used to handle file uploads with > PHP -- talking to the same database as my main Rails app. PHP doesn't > bloat when dumping files across the wire like Ruby does. _Ruby_ doesn't. Observe: swiftiply 1510 0.7 0.2 53300 21136 ? Ss Dec09 27:43 ruby swiftiply -c /etc/swiftiply.cnf Next I retrieve a 470mb file, twice. Then look at ps again swiftiply 1510 0.7 0.2 53300 21136 ? Ss Dec09 27:56 ruby swiftiply -c /etc/swiftiply.cnf No change in the memory footprint, despite running almost a gigabyte of file data through it. One should see essentially the same thing with Mongrel's send_file() method, because it reads the file in Const::CHUNK_SIZE pieces (16k). However...if you are using send_file() from within Rails, then Rails has to read the entire file into the response before it ever goes back to Mongrel, and THAT is what is causing the memory bloat. Not Ruby. Not Mongrel. Rails. I agree with the other pieces of advice that have been given, though. Leverage Apache's x-sendfile since you are on Apache. Alternately, write a dedicated mongrel handler that will deal with authentication & file delivery outside of Rails (which also means outside of the Rails mutex lock, which is a BIG win with regard to scalability of downloads, at least compared to doing it with send_file from inside of Rails). Kirk Haines From lists at ruby-forum.com Wed Dec 12 12:49:34 2007 From: lists at ruby-forum.com (Phil Thompson) Date: Wed, 12 Dec 2007 18:49:34 +0100 Subject: [Mongrel] Mongrel install crash on win32 In-Reply-To: <90a27ccce8cbbdf12ca03a36b69df66e@ruby-forum.com> References: <78de7f038919ce30d788674eee2c3bea@ruby-forum.com> <71166b3b0711270438i3a2320cbx9ba9b31f2ece6278@mail.gmail.com> <7994e5929e93182b0dc518ef1cf5ce4a@ruby-forum.com> <71166b3b0711280816x4241035p5a01cda3ff540761@mail.gmail.com> <90a27ccce8cbbdf12ca03a36b69df66e@ruby-forum.com> Message-ID: <551d364647072b101db261c665347bc5@ruby-forum.com> simply "ruby setup.rb" seems to work too -- Posted via http://www.ruby-forum.com/. From andy.koch at pc-doctor.com Wed Dec 12 12:46:26 2007 From: andy.koch at pc-doctor.com (Andy Koch) Date: Wed, 12 Dec 2007 09:46:26 -0800 Subject: [Mongrel] sendfile and mongrel In-Reply-To: <475F4D03.4090700@ruckuswireless.com> References: <475F4D03.4090700@ruckuswireless.com> Message-ID: Matte Edens wrote: > I use X_SendFile with Apache 2.2 just fine. FYI. > I was hoping I was wrong about that. Where do you get your x-sendfile source from? I got it from "http://tn123.ath.cx/mod_xsendfile/" but I get all kinds of errors when trying to compile it. From john at smokinggun.com Wed Dec 12 12:47:59 2007 From: john at smokinggun.com (John Weir) Date: Wed, 12 Dec 2007 12:47:59 -0500 Subject: [Mongrel] logger & debug level Message-ID: <23E4F900-F5D2-484C-8809-F4C206796B0E@smokinggun.com> greetings, i am getting the below error message in my mongrel log and I want to turn that 22 levels into a full trace. but i am unsure where or how to configure the debug level for mongrel. any advice? thanks - john /usr/lib/ruby/gems/1.8/gems/ruby-debug-0.9.3/cli/ruby-debug/ interface.rb:24:in `join': can't convert nil into String (TypeError) from /usr/lib/ruby/gems/1.8/gems/ruby-debug-0.9.3/cli/ruby- debug/interface.rb:24 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb: 27:in `gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb: 27:in `require' from /var/www/foo/live/vendor/rails/activerecord/lib/../../ activesupport/lib/active_support/dependencies.rb:496:in `require' from /var/www/foo/live/vendor/rails/activerecord/lib/../../ activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in' from /var/www/foo/live/vendor/rails/activerecord/lib/../../ activesupport/lib/active_support/dependencies.rb:496:in `require' from /usr/lib/ruby/gems/1.8/gems/ruby-debug-0.9.3/cli/ruby- debug/processor.rb:1 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb: 27:in `gem_original_require' ... 22 levels... from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ command.rb:211:in `run' from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/ mongrel_rails:243 from /usr/bin/mongrel_rails:16:in `load' from /usr/bin/mongrel_rails:16 From matte at ruckuswireless.com Wed Dec 12 13:08:33 2007 From: matte at ruckuswireless.com (Matte Edens) Date: Wed, 12 Dec 2007 10:08:33 -0800 Subject: [Mongrel] sendfile and mongrel In-Reply-To: References: <475F4D03.4090700@ruckuswireless.com> Message-ID: <476023A1.5090607@ruckuswireless.com> That's also where I got mine. I'm running Apache 2.2.6 on FreeBSD 6.x and compiled it as instructed on that page. apxs -cia mod_xsendfile.c My linux-fu is moderate at best so I was lucky I didn't experience any errors compiling. Otherwise I'd be spending a day in Google finding answers. Good luck. matte Andy Koch wrote: > Matte Edens wrote: > >> I use X_SendFile with Apache 2.2 just fine. FYI. >> >> > > I was hoping I was wrong about that. > > Where do you get your x-sendfile source from? > > I got it from "http://tn123.ath.cx/mod_xsendfile/" > > but I get all kinds of errors when trying to compile it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071212/f8252ec4/attachment.html From wayneeseguin at gmail.com Wed Dec 12 13:27:00 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Wed, 12 Dec 2007 13:27:00 -0500 Subject: [Mongrel] logger & debug level In-Reply-To: <23E4F900-F5D2-484C-8809-F4C206796B0E@smokinggun.com> References: <23E4F900-F5D2-484C-8809-F4C206796B0E@smokinggun.com> Message-ID: -B http://mongrel.rubyforge.org/docs/howto.html ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071212/ac5561af/attachment.html From evan at cloudbur.st Wed Dec 12 13:53:02 2007 From: evan at cloudbur.st (Evan Weaver) Date: Wed, 12 Dec 2007 13:53:02 -0500 Subject: [Mongrel] logger & debug level In-Reply-To: References: <23E4F900-F5D2-484C-8809-F4C206796B0E@smokinggun.com> Message-ID: Actually, the trace snip level is hard-compiled into Ruby. Find the place where the traceback occurs, rescue the exception, and print out e.traceback (or whatever it is) instead. Then you'll see the whole thing. Evan On Dec 12, 2007 1:27 PM, Wayne E. Seguin wrote: > -B > > http://mongrel.rubyforge.org/docs/howto.html > > ~Wayne > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From john at smokinggun.com Wed Dec 12 14:04:19 2007 From: john at smokinggun.com (John Weir) Date: Wed, 12 Dec 2007 14:04:19 -0500 Subject: [Mongrel] logger & debug level In-Reply-To: References: <23E4F900-F5D2-484C-8809-F4C206796B0E@smokinggun.com> Message-ID: <168BCA00-2078-46A8-9927-F2297F285DD1@smokinggun.com> cool, thanks guys On Dec 12, 2007, at 1:53 PM, Evan Weaver wrote: > Actually, the trace snip level is hard-compiled into Ruby. Find the > place where the traceback occurs, rescue the exception, and print out > e.traceback (or whatever it is) instead. Then you'll see the whole > thing. > > Evan > > On Dec 12, 2007 1:27 PM, Wayne E. Seguin > wrote: >> -B >> >> http://mongrel.rubyforge.org/docs/howto.html >> >> ~Wayne >> >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> > > > > -- > Evan Weaver > Cloudburst, LLC > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From alexey.verkhovsky at gmail.com Wed Dec 12 14:10:11 2007 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Wed, 12 Dec 2007 12:10:11 -0700 Subject: [Mongrel] logger & debug level In-Reply-To: References: <23E4F900-F5D2-484C-8809-F4C206796B0E@smokinggun.com> Message-ID: <3945c4270712121110p7308a4fep86284fa97084a4ba@mail.gmail.com> On Dec 12, 2007 11:53 AM, Evan Weaver wrote: > Actually, the trace snip level is hard-compiled into Ruby. Find the > place where the traceback occurs, rescue the exception, and print out > e.traceback (or whatever it is) instead. Then you'll see the whole > thing. e.backtrace The constants that determine length of truncated backtrace are TRACE_HEAD and TRACE_TAIL, #defined in eval.c. Changing them to bigger numbers and recompiling is another way to deal with this issue. -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From andy.koch at pc-doctor.com Wed Dec 12 14:18:16 2007 From: andy.koch at pc-doctor.com (Andy Koch) Date: Wed, 12 Dec 2007 11:18:16 -0800 Subject: [Mongrel] sendfile and mongrel In-Reply-To: <476023A1.5090607@ruckuswireless.com> References: <475F4D03.4090700@ruckuswireless.com> <476023A1.5090607@ruckuswireless.com> Message-ID: ok, after reading the source of mod_xsendfile.c the command should be apxs2 -cia mod_xsendfile.c doing apxs tries to include files from Apache 1.3 - and then fails also, this is on a Debian Etch Matte Edens wrote: > That's also where I got mine. I'm running Apache 2.2.6 on FreeBSD 6.x > and compiled it as instructed on that page. > > apxs -cia mod_xsendfile.c > > My linux-fu is moderate at best so I was lucky I didn't experience any > errors compiling. Otherwise I'd be spending a day in Google finding > answers. Good luck. > > matte > > Andy Koch wrote: >> Matte Edens wrote: >> >>> I use X_SendFile with Apache 2.2 just fine. FYI. >>> >>> >> >> I was hoping I was wrong about that. >> >> Where do you get your x-sendfile source from? >> >> I got it from "http://tn123.ath.cx/mod_xsendfile/" >> >> but I get all kinds of errors when trying to compile it. >> From technoweenie at gmail.com Wed Dec 12 15:38:39 2007 From: technoweenie at gmail.com (Rick Olson) Date: Wed, 12 Dec 2007 12:38:39 -0800 Subject: [Mongrel] sendfile and mongrel In-Reply-To: References: <475F4D03.4090700@ruckuswireless.com> <2EF15B1C-DA62-4CF9-8EE8-6E540A01BBA6@wisc.edu> Message-ID: <48fe25b0712121238t1f4e428frca8631f02ac9dffc@mail.gmail.com> > One should see essentially the same thing with Mongrel's send_file() > method, because it reads the file in Const::CHUNK_SIZE pieces (16k). > However...if you are using send_file() from within Rails, then Rails > has to read the entire file into the response before it ever goes back > to Mongrel, and THAT is what is causing the memory bloat. Not Ruby. > Not Mongrel. Rails. The rails mongrel handler actually. It buffers all the content from rails and sends it after the request is done. Rails supports streaming just fine with FCGI afaik. This is actually something I'd like to fix (and bring the rails handler into rails) actually, but I'm not totally clear why this was done. A thread for another time... +1 for x-send-file or accel-redirect if you're using nginx. -- Rick Olson http://lighthouseapp.com http://weblog.techno-weenie.net http://mephistoblog.com From brian.gupta at gmail.com Wed Dec 12 17:18:50 2007 From: brian.gupta at gmail.com (Brian Gupta) Date: Wed, 12 Dec 2007 17:18:50 -0500 Subject: [Mongrel] Upgrading from Mongrel 1.0.1 and Mongrel cluster 0.2.1 In-Reply-To: <466af3440712120633r40dadebeh56dd842a972d900a@mail.gmail.com> References: <5b5090780712120113w69cc0bf4g44d3cea875aa21ac@mail.gmail.com> <466af3440712120633r40dadebeh56dd842a972d900a@mail.gmail.com> Message-ID: <5b5090780712121418t27e792c1yb5269a54fa0ebae6@mail.gmail.com> Just to confirm you went to 1.1.1 mongrel and 1.0.5 mongrel_cluster? On Dec 12, 2007 9:33 AM, Joey Geiger wrote: > I just did this on a bunch of servers and didn't run into any issues, > thought your case may be different. > > On Dec 12, 2007 3:13 AM, Brian Gupta wrote: > > I am considering upgrading to either Mongrel 1.1.1 or 1.0.4, and > > Mongrel-cluster to 1.0.5. Are there any gotchas or issues I need to be > aware > > of? Also where can I find the release notes for the various releases? > (The > > ones I found seem very sparse). > > > > Thanks, > > Brian > > > > _______________________________________________ > > 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 > -- - Brian Gupta http://opensolaris.org/os/project/nycosug/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071212/337cdc9f/attachment.html From evan at cloudbur.st Wed Dec 12 17:41:16 2007 From: evan at cloudbur.st (Evan Weaver) Date: Wed, 12 Dec 2007 17:41:16 -0500 Subject: [Mongrel] Upgrading from Mongrel 1.0.1 and Mongrel cluster 0.2.1 In-Reply-To: <5b5090780712121418t27e792c1yb5269a54fa0ebae6@mail.gmail.com> References: <5b5090780712120113w69cc0bf4g44d3cea875aa21ac@mail.gmail.com> <466af3440712120633r40dadebeh56dd842a972d900a@mail.gmail.com> <5b5090780712121418t27e792c1yb5269a54fa0ebae6@mail.gmail.com> Message-ID: There is a tiny bug which affects practically nobody in 1.1.1. I'll push out a 1.1.2 release this week just for that. Trunk, however, is unstable; don't use trunk mongrel right now. Evan On Dec 12, 2007 5:18 PM, Brian Gupta wrote: > Just to confirm you went to 1.1.1 mongrel and 1.0.5 mongrel_cluster? > > > > > On Dec 12, 2007 9:33 AM, Joey Geiger wrote: > > I just did this on a bunch of servers and didn't run into any issues, > > thought your case may be different. > > > > > > > > > > On Dec 12, 2007 3:13 AM, Brian Gupta < brian.gupta at gmail.com> wrote: > > > I am considering upgrading to either Mongrel 1.1.1 or 1.0.4, and > > > Mongrel-cluster to 1.0.5. Are there any gotchas or issues I need to be > aware > > > of? Also where can I find the release notes for the various releases? > (The > > > ones I found seem very sparse). > > > > > > Thanks, > > > Brian > > > > > > _______________________________________________ > > > 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 > > > > > > -- > - Brian Gupta > > http://opensolaris.org/os/project/nycosug/ > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From gwolf at gwolf.org Wed Dec 12 20:21:27 2007 From: gwolf at gwolf.org (Gunnar Wolf) Date: Wed, 12 Dec 2007 19:21:27 -0600 Subject: [Mongrel] Mongrel install problem In-Reply-To: <486be5dc0712110727x44e44e78gf484befb4f75c7a4@mail.gmail.com> References: <486be5dc0712110727x44e44e78gf484befb4f75c7a4@mail.gmail.com> Message-ID: <20071213012127.GB22224@cajita.gateway.2wire.net> rob lucas dijo [Tue, Dec 11, 2007 at 03:27:49PM +0000]: > Hi, > > I'm having difficulties getting mongrel running on my Debian Etch > machine. It seems to install and is listed with my other gems, but > things like... > "mongrel_rails start ..." > ... are not recognised. > > Perhaps this is something to do with the file "lib" not being found in > the install process: > (...) Hi, You might be interested in using my (unofficial) apt repository, so you have your Debian installation as clean as possible: deb http://www.iiec.unam.mx/apt/ etch mongrel I'm currently using it in my production server. Greetings, -- Gunnar Wolf - gwolf at gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF From zhubo03 at gmail.com Wed Dec 12 22:57:14 2007 From: zhubo03 at gmail.com (=?GB2312?B?1uyyqQ==?=) Date: Thu, 13 Dec 2007 11:57:14 +0800 Subject: [Mongrel] mod_proxy_balancer mod_rewrite permission issue Message-ID: I started the mongrel_cluster and tried to use the RewriteRule to forward the requests to proxy_balancer just as the http://mongrel.rubyforge.org/docs/apache.html said. When I visited my site from a remote computer, I always got the error messages "Forbidden, You don't have permission to access / on this server." Finally, I added the "Allow from all" property (in the vhost config file), just like this: BalancerMember http://127.0.0.1:8001 BalancerMember http://127.0.0.1:8002 BalancerMember http://127.0.0.1:8003 Order allow,deny Allow from all then the "Forbidden" problem was solved. The "all" could not be changed to "127.0.0.1" or others. I guest this should be related with the implement detail of the mod_rewrite. My question is, could this "Allow from all" be a latent security problem? and is there anybody faced the same issue? Could I miss something through the configuration or did the mongrel-apache document miss something? I am sorry my English is not very good. Best wishes everyone, Alfie ZHU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071213/290993c1/attachment.html From zhubo03 at gmail.com Thu Dec 13 02:33:20 2007 From: zhubo03 at gmail.com (=?GB2312?B?1uyyqQ==?=) Date: Thu, 13 Dec 2007 15:33:20 +0800 Subject: [Mongrel] mod_proxy_balancer mod_rewrite permission issue In-Reply-To: References: Message-ID: I searched and found someone got the same problem 1 year ago: http://rubyforge.org/pipermail/mongrel-users/2006-December/002594.html But it seams he finally used the ProxyPass instead of RewriteRule, and did not actually solve the problem. I hope my solution will give some possibility to fixing the same problem. On Dec 13, 2007 11:57 AM, $B wrote: > I started the mongrel_cluster and tried to use the RewriteRule to forward > the requests to proxy_balancer just as the > http://mongrel.rubyforge.org/docs/apache.html said. > When I visited my site from a remote computer, I always got the error > messages "Forbidden, You don't have permission to access / on this server." > > Finally, I added the "Allow from all" property (in the vhost config file), > just like this: > > BalancerMember http://127.0.0.1:8001 > BalancerMember http://127.0.0.1:8002 > BalancerMember http://127.0.0.1:8003 > > Order allow,deny > Allow from all > > then the "Forbidden" problem was solved. > The "all" could not be changed to "127.0.0.1" or others. I guest this > should be related with the implement detail of the mod_rewrite. > > My question is, could this "Allow from all" be a latent security problem? > and is there anybody faced the same issue? > Could I miss something through the configuration or did the mongrel-apache > document miss something? > > I am sorry my English is not very good. > > Best wishes everyone, > > Alfie ZHU > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071213/e887808d/attachment.html From jazzyy at gmail.com Thu Dec 13 08:24:53 2007 From: jazzyy at gmail.com (Nii Amon Dsane) Date: Thu, 13 Dec 2007 13:24:53 +0000 Subject: [Mongrel] Weird Mongrel error: Not starting. Message-ID: <7cf2a5480712130524j78fc8933md1d1bf782d837aba@mail.gmail.com> Hi list, I have a problem with Mongrel which is really bugging me. I would really appreciate any help that anyone can provide to help me in solving this problem. 1. My setup: Apache front_end with mod_proxy_balancer in front of 4 mongrel/rails instances of my application. Rails 1.2.5 Ruby 1.8.6 Mongrel 1.1.1 2. I noticed that the CPU consumption on my server was 100% being consumed by ruby so I stopped the ruby processes and rebooted the server. 3. After the reboot mongrel_rails fails to load for one particular application though I have other applications running on the same server without any issues. This is the error that I get: ** Starting Mongrel listening at 0.0.0.0:3013 ** Starting Rails with development environment... /usr/lib/ruby/gems/1.8/gems/mongrel- 1.1.1/bin/../lib/mongrel/tcphack.rb:12:in `initialize_without_backlog': Cannot assign requested address - bind(2) (Errno::EADDRNOTAVAIL) from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/tcphack.rb:12:in `initialize' from /usr/lib/ruby/1.8/drb/drb.rb:865:in `open' from /usr/lib/ruby/1.8/drb/drb.rb:865:in `open_server' from /usr/lib/ruby/1.8/drb/drb.rb:759:in `open_server' from /usr/lib/ruby/1.8/drb/drb.rb:757:in `each' from /usr/lib/ruby/1.8/drb/drb.rb:757:in `open_server' from /usr/lib/ruby/1.8/drb/drb.rb:1339:in `initialize' from /usr/lib/ruby/1.8/drb/drb.rb:1627:in `new' ... 31 levels... from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/../lib/mongrel/command.rb:212:in `run' from /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:281 from /usr/bin/mongrel_rails:16:in `load' from /usr/bin/mongrel_rails:16 4. I tried everything that I know of to resolve the issue but no luck: - Did a netstat to check if the port was in use by any other process: No processes were holding onto that port - Checked ifconfig configuration to see if the NICs have been changed in anyway: No changes had been made to the NICs. 5. To isolate the issue, I checked out the same version of the application from svn and deployed on the server. Still no luck. 6. Checked out the same version of the application from svn and deployed on another server with success. Hmm same code different boxes and it is working says to me that there is something wrong with the configuration on the other server which is not playing ball with my code. FYI: I have backgroundrb in vendor/plugins which starts up fine. Any help in the right direction would be appreciated. Thanks Nii Amon. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071213/1fbd18c2/attachment.html From rgo at aspgems.com Thu Dec 13 08:40:59 2007 From: rgo at aspgems.com (Rafael G.) Date: Thu, 13 Dec 2007 14:40:59 +0100 Subject: [Mongrel] Weird Mongrel error: Not starting. In-Reply-To: <7cf2a5480712130524j78fc8933md1d1bf782d837aba@mail.gmail.com> References: <7cf2a5480712130524j78fc8933md1d1bf782d837aba@mail.gmail.com> Message-ID: <4761366B.9040905@aspgems.com> Nii Amon Dsane escribi?: > Hi list, > Hi Nii, > > 3. After the reboot mongrel_rails fails to load for one particular > application though I have other applications running on the same > server without any issues. This is the error that I get: > > ** Starting Mongrel listening at 0.0.0.0:3013 In your config/mongrel_cluster.yml try setting address parameter to 127.0.0.1 and explain results. Regards -- Rafael Garcia Ortega -------------- next part -------------- A non-text attachment was scrubbed... Name: rgo.vcf Type: text/x-vcard Size: 241 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071213/27100c6c/attachment.vcf From lists at ruby-forum.com Thu Dec 13 09:07:09 2007 From: lists at ruby-forum.com (Nii amon Dsane) Date: Thu, 13 Dec 2007 15:07:09 +0100 Subject: [Mongrel] Weird Mongrel error: Not starting. In-Reply-To: <4761366B.9040905@aspgems.com> References: <7cf2a5480712130524j78fc8933md1d1bf782d837aba@mail.gmail.com> <4761366B.9040905@aspgems.com> Message-ID: <02d69306679ed31ad85f664348377b00@ruby-forum.com> Hi Rafael, Thanks for the quick response. I am not using mongrel_cluster yet. I am just starting each mongrel_rails instance manually. The command I use is below: /usr/bin/mongrel_rails start -c /srv/rails/appname -P /srv/rails/appname/log/mongrel.pid -l /srv/rails/appname/log/mongrel.log -e production -d -p 3013. I cd to RAILS_ROOT and then issue that command as root and then the error appears. Thanks Nii Amon Rafael Garc?a wrote: > Nii Amon Dsane escribi?: >> Hi list, >> > Hi Nii, >> >> 3. After the reboot mongrel_rails fails to load for one particular >> application though I have other applications running on the same >> server without any issues. This is the error that I get: >> >> ** Starting Mongrel listening at 0.0.0.0:3013 > > In your config/mongrel_cluster.yml try setting address parameter to > 127.0.0.1 and explain results. > > Regards -- Posted via http://www.ruby-forum.com/. From rgo at aspgems.com Thu Dec 13 09:27:57 2007 From: rgo at aspgems.com (Rafael G.) Date: Thu, 13 Dec 2007 15:27:57 +0100 Subject: [Mongrel] Weird Mongrel error: Not starting. In-Reply-To: <02d69306679ed31ad85f664348377b00@ruby-forum.com> References: <7cf2a5480712130524j78fc8933md1d1bf782d837aba@mail.gmail.com> <4761366B.9040905@aspgems.com> <02d69306679ed31ad85f664348377b00@ruby-forum.com> Message-ID: <4761416D.3090603@aspgems.com> Try adding -a option: /usr/bin/mongrel_rails start -c /srv/rails/appname -P /srv/rails/appname/log/mongrel.pid -l /srv/rails/appname/log/mongrel.log -e production -d -p 3013 -a 127.0.0.1 Only for check if run. Nii amon Dsane escribi?: > Hi Rafael, > > Thanks for the quick response. > > I am not using mongrel_cluster yet. I am just starting each > mongrel_rails instance manually. The command I use is below: > > /usr/bin/mongrel_rails start -c /srv/rails/appname -P > /srv/rails/appname/log/mongrel.pid -l /srv/rails/appname/log/mongrel.log > -e production -d -p 3013. > > I cd to RAILS_ROOT and then issue that command as root and then the > error appears. > > Thanks > Nii Amon > > Rafael Garc?a wrote: > >> Nii Amon Dsane escribi?: >> >>> Hi list, >>> >>> >> Hi Nii, >> >>> 3. After the reboot mongrel_rails fails to load for one particular >>> application though I have other applications running on the same >>> server without any issues. This is the error that I get: >>> >>> ** Starting Mongrel listening at 0.0.0.0:3013 >>> >> In your config/mongrel_cluster.yml try setting address parameter to >> 127.0.0.1 and explain results. >> >> Regards >> > > -- Rafael Garcia Ortega -------------- next part -------------- A non-text attachment was scrubbed... Name: rgo.vcf Type: text/x-vcard Size: 251 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071213/342c7a54/attachment-0001.vcf From lists at ruby-forum.com Thu Dec 13 09:36:11 2007 From: lists at ruby-forum.com (Nii amon Dsane) Date: Thu, 13 Dec 2007 15:36:11 +0100 Subject: [Mongrel] Weird Mongrel error: Not starting. In-Reply-To: <4761416D.3090603@aspgems.com> References: <7cf2a5480712130524j78fc8933md1d1bf782d837aba@mail.gmail.com> <4761366B.9040905@aspgems.com> <02d69306679ed31ad85f664348377b00@ruby-forum.com> <4761416D.3090603@aspgems.com> Message-ID: <214dd366b5f72e0707d6266a45c42319@ruby-forum.com> Hi Rafael, I tried it with the -a switch and still the same error. I tried it against all the IPs that ifconfig reported but it still failed. Thanks Nii Amon Rafael Garc?a wrote: > Try adding -a option: > > /usr/bin/mongrel_rails start -c /srv/rails/appname -P > /srv/rails/appname/log/mongrel.pid -l /srv/rails/appname/log/mongrel.log > -e production -d -p 3013 -a 127.0.0.1 > > Only for check if run. > > Nii amon Dsane escribi?: -- Posted via http://www.ruby-forum.com/. From sobrien at yahoo-inc.com Thu Dec 13 12:13:32 2007 From: sobrien at yahoo-inc.com (Sean O'Brien) Date: Thu, 13 Dec 2007 09:13:32 -0800 Subject: [Mongrel] Mongrel install problem In-Reply-To: <486be5dc0712120646p23e39e5boa34667ac203bea44@mail.gmail.com> References: <486be5dc0712120646p23e39e5boa34667ac203bea44@mail.gmail.com> Message-ID: Rob - Do you have the gem "cgi_multipart_eof_fix" installed? Try the following and see what is returned: gem list --local | grep cgi_multipart Did you install rubygems from apt or did you use something else? - sob On Dec 12, 2007, at 6:46 AM, rob lucas wrote: > (apologies for double-posting this. I just realised that the original > had the digest title, and thus broke the thread.) > > Thanks for the help Sean. I managed to get the install fixed, but I'm > still having problems. When I do mongrel_rails start, the process just > gets stuck and never completes. If I interrupt it I get the > following... > > ** Ruby version is not up-to-date; loading cgi_multipart_eof_fix > /usr/lib/ruby/1.8/rubygems/source_index.rb:186:in `search': Interrupt > from /usr/lib/ruby/1.8/rubygems/source_index.rb:185:in `each' > from /usr/lib/ruby/1.8/rubygems/source_index.rb:185:in > `search' > from /usr/lib/ruby/1.8/rubygems/source_index.rb:165:in > `find_name' > from /usr/lib/ruby/1.8/rubygems.rb:195:in `activate' > from /usr/lib/ruby/1.8/rubygems.rb:65:in > `active_gem_with_options' > from /usr/lib/ruby/1.8/rubygems.rb:49:in `gem' > from /var/lib/gems/1.8/gems/mongrel-1.1.1/bin/../lib/ > mongrel/gems.rb:12:in > `require' > from /var/lib/gems/1.8/gems/mongrel-1.1.1/bin/../lib/ > mongrel.rb:13 > from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require' > from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from /var/lib/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:11 > from /usr/bin/mongrel_rails:16:in `load' > from /usr/bin/mongrel_rails:16 > > ... which indicates it is getting stuck in the block of this search > method: > > def search(gem_pattern, > version_requirement=Version::Requirement.new(">= 0")) > #FIXME - remove duplication between this and > RemoteInstaller.search > gem_pattern = /^#{ gem_pattern }$/i if String === gem_pattern > version_requirement = > Gem::Version::Requirement.create(version_requirement) > result = [] > @gems.each do |full_spec_name, spec| > next unless spec.name =~ gem_pattern > result << spec if version_requirement.satisfied_by? > (spec.version) > end > result = result.sort > result > end > > Any ideas why? > > Thanks, > > Rob. > > > > >> Date: Tue, 11 Dec 2007 09:31:34 -0800 >> From: "Sean O'Brien" >> Subject: Re: [Mongrel] Mongrel install problem >> To: mongrel-users at rubyforge.org >> Message-ID: <570BBEFE-51FD-4635-A652-8B1D0FACE930 at yahoo-inc.com> >> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed >> >> I had the same issue on Etch, try adding '/var/lib/gems/1.8/bin/' to >> your path - see if that works. >> >> - sob >> >> On Dec 11, 2007, at 7:27 AM, rob lucas wrote: >> >>> Hi, >>> >>> I'm having difficulties getting mongrel running on my Debian Etch >>> machine. It seems to install and is listed with my other gems, but >>> things like... >>> "mongrel_rails start ..." >>> ... are not recognised. >>> >>> Perhaps this is something to do with the file "lib" not being >>> found in >>> the install process: >>> >>> ruby extconf.rb install mongrel --include-dependencies >>> checking for main() in -lc... no >>> creating Makefile >>> >>> make >>> >>> make install >>> >>> make clean >>> Successfully installed mongrel-1.1.1 >>> Successfully installed fastthread-1.0.1 >>> Installing ri documentation for mongrel-1.1.1... >>> Installing ri documentation for fastthread-1.0.1... >>> File not found: lib >>> >>> I've done the usual Googling for solutions to this, but no luck so >>> far. Any help would be appreciated. >>> >>> Thanks, >>> >>> Rob. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From lists at ruby-forum.com Fri Dec 14 17:16:17 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Fri, 14 Dec 2007 23:16:17 +0100 Subject: [Mongrel] Mongrel error : EMFILE too many open files Message-ID: I have a periodically_call_remote call in a partial running at 0.20 times a second. <%= periodically_call_remote(:update => 'ack_distance_output', :frequency => 0.2, :url=>{:action => :ackAdjustDistance}) %> the action looks like this def ackAdjustDistance @calMessage = Calibration.getMessage if(@calMessage.Value == "4") # CALVAR_LINE_EVENT render(:inline => %{ <%= image_tag("stop.png", :class => "bevel", :width => "256", :height => "256") %>

}) return else render(:inline => %{ <%= image_tag("arrow_down.png", :class => "bevel", :width => "256", :height => "256") %> }) return end end after a couple minutes I get the following error Errno::EMFILE (Too many open files - script/../config/../tmp/sessions//ruby_sess.3b99572316c49027): Once this happens mongrel can't find anything. the only recovery is the restart the web server. The periodic render has an image_tag which appears to be opening the image file and its not being released emediatly? Anything I can do to fix this? Scott -- Posted via http://www.ruby-forum.com/. From luislavena at gmail.com Fri Dec 14 17:25:08 2007 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 14 Dec 2007 19:25:08 -0300 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: References: Message-ID: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> On Dec 14, 2007 7:16 PM, Scott Derrick wrote: > I have a periodically_call_remote call in a partial running at 0.20 > times a second. > [...] > > after a couple minutes I get the following error > > Errno::EMFILE (Too many open files - > script/../config/../tmp/sessions//ruby_sess.3b99572316c49027): > > Once this happens mongrel can't find anything. the only recovery is the > restart the web server. > First suggestion: move away from pstore for session storage (use activerecord, sqlstore or even memcached one, but no pstore). > The periodic render has an image_tag which appears to be opening the > image file and its not being released emediatly? > image_tag shouldn't be opening any file, just linking it. PStore isn't good when tmp/sessions is full or one ruby process is trying to handle lot of sessions (which will exceed 1024 file limit). -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From lists at ruby-forum.com Fri Dec 14 20:03:42 2007 From: lists at ruby-forum.com (Collins Few) Date: Sat, 15 Dec 2007 02:03:42 +0100 Subject: [Mongrel] mongrel_upload_progress and attachment_fu In-Reply-To: References: Message-ID: Jochen Kaechelin wrote: > Can one use mongrel_upload_progress in combination with attachment_fu > (db_file)? > I wan't to store uploaded files directly in a mysql-database - not in > the filesystem. > Is there a way to use mongrel_upload_progress to do this, or do I have > to store > files in the filesystem and copy them to the database? > > Thanx I have been able to get the two working together -- but currently have it configured to store to the file system. I can't think of any reason that it wouldn't work if you want to store into the database. It's be easy to switch and try it out -- I'll do that and get back to you. Collins -- Posted via http://www.ruby-forum.com/. From wayneeseguin at gmail.com Sat Dec 15 08:20:19 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Sat, 15 Dec 2007 08:20:19 -0500 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: References: Message-ID: On Dec 14, 2007 5:16 PM, Scott Derrick wrote: > after a couple minutes I get the following error > > Errno::EMFILE (Too many open files - > script/../config/../tmp/sessions//ruby_sess.3b99572316c49027): > > Once this happens mongrel can't find anything. the only recovery is the > restart the web server. > > The periodic render has an image_tag which appears to be opening the > image file and its not being released emediatly? > > Anything I can do to fix this? > > Scott > First, if it's creating a session for every hit something is not correct with the Rails code, investigate this. If you cannot track it down try using either cookie or database sessions. That said, if you need to have more open files you can adjust you're open file limit: See the file limit: $ ulimit Adjust the file limit: $ ulimit 2048 ^ ^ allows up to 2048 open files. ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071215/679f2095/attachment.html From lists at ruby-forum.com Sat Dec 15 10:45:07 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Sat, 15 Dec 2007 16:45:07 +0100 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> Message-ID: <5cb8f79d580a83fb71eee3de8ec375a4@ruby-forum.com> Thanks, Luis Lavena wrote: > First suggestion: move away from pstore for session storage (use > activerecord, sqlstore or even memcached one, but no pstore). I will try this immediately. Scott -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Sat Dec 15 10:46:59 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Sat, 15 Dec 2007 16:46:59 +0100 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: References: Message-ID: Wayne E. Seguin wrote: > First, if it's creating a session for every hit something is not correct > with the Rails code, investigate this. > If you cannot track it down try using either cookie or database > sessions. If changing the sessions store method doesn't fix this I will dig deeper.. > Adjust the file limit: > > $ ulimit 2048 tried that and it just delayed the failure.. thanks, Scott -- Posted via http://www.ruby-forum.com/. From matt at zivity.com Sat Dec 15 12:23:11 2007 From: matt at zivity.com (Matt Carr) Date: Sat, 15 Dec 2007 09:23:11 -0800 Subject: [Mongrel] tmp file copy on upload Message-ID: <9ee7df2c0712150923g19fc893ev1f7c51673fecdae@mail.gmail.com> I have an upload progress bar that runs fine, except when the tmp file is being copied locally. Can someone explain why the file is copied from mongrel1626-0 to CGI1626-0 ? It results in a progress bar that hangs at about 90% .. Reminds me of burning a CD. -matt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071215/eb87f197/attachment.html From lists at ruby-forum.com Sun Dec 16 14:24:33 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Sun, 16 Dec 2007 20:24:33 +0100 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> Message-ID: <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> Well I changed the session store to memory_store and it still crashes.. I don't get the EMFIle error, mongrel just stops responding to any request. I would try database store but I can't put the session store in my default database for concurrency reasons. I tried to find instructions on how to set it up to use a separate database file but haven't found that yet.. I also wonder about why mongrel was still using pstore after I upgraded to rails 2.0.1? I thought the default for 2.0 was to store it in the cookie file on the client? Mine was still creating pstore files in tmp? Shouldn't it use cookie by default? Really a drag having my web server crash just because somebody sits on a page for more than 10 minutes. Scott -- Posted via http://www.ruby-forum.com/. From wyhaines at gmail.com Sun Dec 16 21:39:45 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Sun, 16 Dec 2007 19:39:45 -0700 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> Message-ID: On Dec 16, 2007 12:24 PM, Scott Derrick wrote: > Well I changed the session store to memory_store and it still crashes.. > I don't get the EMFIle error, mongrel just stops responding to any > request. > > I would try database store but I can't put the session store in my > default database for concurrency reasons. I tried to find instructions > on how to set it up to use a separate database file but haven't found > that yet.. > > I also wonder about why mongrel was still using pstore after I upgraded > to rails 2.0.1? I thought the default for 2.0 was to store it in the > cookie file on the client? Mine was still creating pstore files in tmp? > Shouldn't it use cookie by default? Nobody else has said it, so I will. This is not a Mongrel problem. It's a problem related to the web framework that you are using, and/or how you are using that framework. Mongrel doesn't have anything whatsoever to do with your application session management details. I imagine that you will find better, more specific advice by asking your question in a Rails specific forum. Kirk Haines From lists at ruby-forum.com Mon Dec 17 04:15:58 2007 From: lists at ruby-forum.com (Paolo Capriotti) Date: Mon, 17 Dec 2007 10:15:58 +0100 Subject: [Mongrel] Fresh install on Debian Etch - Mongrel immediately hangs In-Reply-To: References: Message-ID: <400507f5e01b232f42e8151da8e6ea1d@ruby-forum.com> Benny Beesnus wrote: > Hi, > > I just did a clean install of > > Ruby 1.8.5 > Rubygems 0.9.0 > > and the Mongrel and Mongrel_Cluster gems. > > I used only the Debian Etch package manager, nothing compiled myself. > > Now, on a testapp when I do a script/server, I get the: > > ** Ruby version is not up-to-date; loading cgi_multipart_eof_fix > > warning. But it's not serving my app. Ruby is immediately on 100% CPU > load (and 0.7% memory) and stays there. > > When I press CTRL-C on the console I started the server from, I get > > => Booting Mongrel (use 'script/server webrick' to force WEBrick) > => Rails application starting on http://0.0.0.0:3000 > => Call with -d to detach > => Ctrl-C to shutdown server > > but still, nothing is served and Ruby process at 100% CPU. > > Trying to do a mongrel_rails -B to debug it produces no debug log. The > hang is very immediate. I've found that mongrel tries to require some library repeatedly, because it gets an unrelated exception while trying to load it. For me, the missing library was actually fastthread, and installing it solved the problem. To find out what is the actual error, add a print statement after line 8 in lib/mongrel/gems.rb. Hope that helps, Paolo Capriotti -- Posted via http://www.ruby-forum.com/. From luislavena at gmail.com Mon Dec 17 04:26:08 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 17 Dec 2007 06:26:08 -0300 Subject: [Mongrel] Fresh install on Debian Etch - Mongrel immediately hangs In-Reply-To: <400507f5e01b232f42e8151da8e6ea1d@ruby-forum.com> References: <400507f5e01b232f42e8151da8e6ea1d@ruby-forum.com> Message-ID: <71166b3b0712170126y4b02484bldce7249770b6e35e@mail.gmail.com> On Dec 17, 2007 6:15 AM, Paolo Capriotti wrote: [...] > > I've found that mongrel tries to require some library repeatedly, > because it gets an unrelated exception while trying to load it. For me, > the missing library was actually fastthread, and installing it solved > the problem. > To find out what is the actual error, add a print statement after line 8 > in lib/mongrel/gems.rb. > > Hope that helps, > Paolo, you can confirm this behavior happens also with "mongrel_rails" and not just script/server? -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From lists at ruby-forum.com Mon Dec 17 04:43:12 2007 From: lists at ruby-forum.com (Paolo Capriotti) Date: Mon, 17 Dec 2007 10:43:12 +0100 Subject: [Mongrel] Fresh install on Debian Etch - Mongrel immediately hangs In-Reply-To: <71166b3b0712170126y4b02484bldce7249770b6e35e@mail.gmail.com> References: <400507f5e01b232f42e8151da8e6ea1d@ruby-forum.com> <71166b3b0712170126y4b02484bldce7249770b6e35e@mail.gmail.com> Message-ID: <4ea46f9997d961b0d989f36548cc916c@ruby-forum.com> Luis Lavena wrote: > On Dec 17, 2007 6:15 AM, Paolo Capriotti wrote: > [...] >> >> I've found that mongrel tries to require some library repeatedly, >> because it gets an unrelated exception while trying to load it. For me, >> the missing library was actually fastthread, and installing it solved >> the problem. >> To find out what is the actual error, add a print statement after line 8 >> in lib/mongrel/gems.rb. >> >> Hope that helps, >> > > Paolo, you can confirm this behavior happens also with "mongrel_rails" > and not just script/server? Yes, it did happen. After installing fastthread, I can't reproduce it anymore if I uninstall it. mongrel_rails now exits with a clean backtrace when started without fastthread installed, and script/server runs webrick instead. I don't know what exactly was causing the problem... maybe a wrong installed version of fastthread? The exception caught in lib/mongrel/gems.rb:8 was: 'no such file to load -- fastthread' - sorry, I didn't save the backtrace. Paolo Capriotti -- Posted via http://www.ruby-forum.com/. From roblucas at lucasandblench.com Mon Dec 17 05:36:02 2007 From: roblucas at lucasandblench.com (rob lucas) Date: Mon, 17 Dec 2007 10:36:02 +0000 Subject: [Mongrel] Mongrel install problem Message-ID: <486be5dc0712170236y45c59f70k2753558b032f8a01@mail.gmail.com> Hi Sean, Its fixed now. I think the main problem was that I just did a bunch of simple installs through apt, and then "gem install whatever" and the versions of different things ended up not tallying properly: the latest Debian ruby package was 1.8.5 and I was trying to run the latest Mongrel and Mongrel Cluster, which weren't happy. A simple mistake really I guess, though it isn't always immediately obvious which versions go with which. I now have it working with mongrel (1.0.1) and mongrel_cluster (1.0.2) on ruby 1.8.5 . Also, I didn't have Make installed at the beginning, which I think the Gem install process needed. Glad its all working now. Thanks for your help. Rob. > Date: Thu, 13 Dec 2007 09:13:32 -0800 > From: "Sean O'Brien" > Subject: Re: [Mongrel] Mongrel install problem > To: mongrel-users at rubyforge.org > Message-ID: > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Rob - > > Do you have the gem "cgi_multipart_eof_fix" installed? Try the > following and see what is returned: > > gem list --local | grep cgi_multipart > > Did you install rubygems from apt or did you use something else? > > - sob > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071217/ec233d10/attachment.html From lists at ruby-forum.com Mon Dec 17 10:16:22 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Mon, 17 Dec 2007 16:16:22 +0100 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> Message-ID: <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> Kirk Haines wrote: > Nobody else has said it, so I will. > This is not a Mongrel problem. Kirk, thats certainly possible thats its not a problem specific to Mongrel. I think its more likely related to my upgrade to Ruby 2.0.1. Its also possible its a CGI problem as CGi is used for session store to memory or pstore. It is odd that what ever the problem, Mongrel crashes.. It won't respond to any http request from any client. Its dead in the water. That makes it a Mongrel problem in my eyes, at least to anybody who cares if Mongrel is reliable or not. Scott -- Posted via http://www.ruby-forum.com/. From wyhaines at gmail.com Mon Dec 17 11:35:50 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 17 Dec 2007 09:35:50 -0700 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> Message-ID: On Dec 17, 2007 8:16 AM, Scott Derrick wrote: > thats certainly possible thats its not a problem specific to Mongrel. I > think its more likely related to my upgrade to Ruby 2.0.1. Its also > possible its a CGI problem as CGi is used for session store to memory or > pstore. Not Ruby 2.0.1. It doesn't exist. Rails 2.0.1? Ruby != Rails. http://rubyisnotrails.com/ > It is odd that what ever the problem, Mongrel crashes.. It won't > respond to any http request from any client. Its dead in the water. > > That makes it a Mongrel problem in my eyes, at least to anybody who > cares if Mongrel is reliable or not. No, it doesn't, because it doesn't have anything to do with _mongrel_ reliability. The problem is related to Rails deadlocking. When that happens, control never returns to Mongrel; it is out of Mongrel's control. It's something happening inside of either the Rails code or your application's code. It is not happening in Mongrel's code. Mongrel is a software component that is responsible for a narrow range of tasks. 1) It receives HTTP requests, and parses them. 2) It determines, based on the request uri, which of it's registered handlers should handle the request. 3) It calls the handler, handing it request and response objects. 4) There are some differences in how the handlers for various frameworks actually work, but in the end they all do one thing that is the same -- they pass control from the handler into the framework's code. 5) Session handling occurs here, inside of the framework's code, which includes the code for your application. As does the rest of whatever your application does to construct it's response. 6) When the framework/app code finishes constructing the response, control flows out of the handler and back to Mongrel. 7) Mongrel sends the response. That's the basic cycle of operation. Your problem is almost certainly inside #5. Kirk Haines From lists at ruby-forum.com Mon Dec 17 12:05:14 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Mon, 17 Dec 2007 18:05:14 +0100 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> Message-ID: <6dd8fccdae1126c7944a20f4f67daed3@ruby-forum.com> Kirk Haines wrote: >> It is odd that what ever the problem, Mongrel crashes.. It won't >> respond to any http request from any client. Its dead in the water. >> That makes it a Mongrel problem in my eyes, at least to anybody who >> cares if Mongrel is reliable or not. > > No, it doesn't, because it doesn't have anything to do with _mongrel_ > reliability. I appreciate your responses and am looking at everything to find the problem. Believe me I'm not looking for a scapegoat, I'm looking for a solution. The reason why I think this is a mongrel reliability issue is that when my mongrel server stops responding, its stops responding to everybody! Any browser from any client machine that trys to access any page on the website gets "nada", no response.. I can't even get a page not found 404 error if I feed it a bad address, the mongrel server is locked up and not responding, to anybody. Maybe I don't understand the linkage between my web app and the web server, I didn't think my application by running a periodic update could cause the server to refuse any new connections? Its not like its really busy with a couple hundred requests a second, its 5 requests a second, on a fast server? Scott Scott -- Posted via http://www.ruby-forum.com/. From wyhaines at gmail.com Mon Dec 17 12:17:37 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 17 Dec 2007 10:17:37 -0700 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: <6dd8fccdae1126c7944a20f4f67daed3@ruby-forum.com> References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> <6dd8fccdae1126c7944a20f4f67daed3@ruby-forum.com> Message-ID: On Dec 17, 2007 10:05 AM, Scott Derrick wrote: > The reason why I think this is a mongrel reliability issue is that when > my mongrel server stops responding, its stops responding to everybody! > Any browser from any client machine that trys to access any page on the > website gets "nada", no response.. > > I can't even get a page not found 404 error if I feed it a bad address, > the mongrel server is locked up and not responding, to anybody. > > Maybe I don't understand the linkage between my web app and the web > server, I didn't think my application by running a periodic update could > cause the server to refuse any new connections? Its not like its really > busy with a couple hundred requests a second, its 5 requests a second, > on a fast server? Yeah. The standard Mongrel is multithreaded using Ruby green threads. When a request comes in, a new ruby thread is created to handle that request. This isn't true concurrency because all of the green threads are handled inside the single process, but it lets Mongrel have multiple things in-process at the same time, which is occasionally useful (though not as big a deal as a lot of people seem to think, though). Rails, however, is unsafe when there is more than one request in-process at the same time. So the handler for Rails has a mutex in it that locks the Rails processing to a single request at a time. In addition, Mongrel is subject to the same limits on file descriptors and open files that your app as a whole is. My suspicion is that your Rails code is eventually deadlocking on an exhausted open files limit, and when it does that, everything else is blocked up and nothing moves anymore. I don't do Rails, so I'm not going to be of much help in suggesting solutions, but it sounds like something about how sessions are being handled is leaving open filehandles laying around. That's why I suggest taking the question to a Rails specific forum, where you can probably find someone who knows the details about the session management option that you are using, and can pinpoint the problem for you. Kirk Haines From bassnode at gmail.com Mon Dec 17 12:20:35 2007 From: bassnode at gmail.com (Ed Hickey) Date: Mon, 17 Dec 2007 11:20:35 -0600 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: <6dd8fccdae1126c7944a20f4f67daed3@ruby-forum.com> References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> <6dd8fccdae1126c7944a20f4f67daed3@ruby-forum.com> Message-ID: <733f56120712170920k41d81343w24cdd8470f7abef7@mail.gmail.com> On Dec 17, 2007 11:05 AM, Scott Derrick wrote: > The reason why I think this is a mongrel reliability issue is that when > my mongrel server stops responding, its stops responding to everybody! > Any browser from any client machine that trys to access any page on the > website gets "nada", no response.. I don't have your original post, so you may have outlined these details, but: Are you running more than 1 mongrel? What are you using to balance: Apache's mod_proxy, hardware load balancer, or something else (nginx, etc)? Last time I checked, Nginx and Apache use round-robin for rotating through your mongrel ports. So, if one mongrel process is taking awhile to respond, the balancer can't tell and could send a new user to that port causing a hanging request. There are alternatives that will allow the hung/slow ports to be skipped after a certain threshold, but nothing that uses apache (to my knowledge). Here's a recent one for Nginx: http://brainspl.at/articles/2007/11/09/a-fair-proxy-balancer-for-nginx-and-mongrel If you're just using one mongrel, then this won't apply. What Kirk is explaining is that it's not mongrel that is hanging on the request, it's the (single-threaded) Rails code. He should know all about that seeing as he wrote Swiftiply (which you might look into as a solution). http://swiftiply.swiftcore.org/ ed > > I can't even get a page not found 404 error if I feed it a bad address, > the mongrel server is locked up and not responding, to anybody. > > Maybe I don't understand the linkage between my web app and the web > server, I didn't think my application by running a periodic update could > cause the server to refuse any new connections? Its not like its really > busy with a couple hundred requests a second, its 5 requests a second, > on a fast server? > > Scott > > Scott > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From lists at ruby-forum.com Mon Dec 17 12:30:39 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Mon, 17 Dec 2007 18:30:39 +0100 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> <6dd8fccdae1126c7944a20f4f67daed3@ruby-forum.com> Message-ID: <130fdf8db4aa244e25a6e38b84e59ded@ruby-forum.com> Kirk Haines wrote: All that makes sense if 1.) sessions is the problem. I upped the file handle limit to 4096 and now I don't get an EMFILE error from mongrel, mongrel just stops responding to requests... 2.) Mongrel and my Rails app share the same file handle limit? I thought they were separate ruby apps? Or do all Ruby apps share the same environment? I've run mongrel with the -D flag and nothing in the log file. other apps on the system are running fine so its certainly not a system wide problem. I have posted this problem on multiple Ruby and Rails forums, no luck in an answer so far. I'm going to remove and reinstall ruby, gems and rails to see if the multiple updates over the last 6 months have left some cruft that is causing the problem. > On Dec 17, 2007 10:05 AM, Scott Derrick wrote: >> cause the server to refuse any new connections? Its not like its really >> busy with a couple hundred requests a second, its 5 requests a second, >> on a fast server? > > Yeah. The standard Mongrel is multithreaded using Ruby green threads. > When a request comes in, a new ruby thread is created to handle that > request. This isn't true concurrency because all of the green threads > are handled inside the single process, but it lets Mongrel have > multiple things in-process at the same time, which is occasionally > useful (though not as big a deal as a lot of people seem to think, > though). > > Rails, however, is unsafe when there is more than one request > in-process at the same time. So the handler for Rails has a mutex in > it that locks the Rails processing to a single request at a time. > > In addition, Mongrel is subject to the same limits on file descriptors > and open files that your app as a whole is. > > My suspicion is that your Rails code is eventually deadlocking on an > exhausted open files limit, and when it does that, everything else is > blocked up and nothing moves anymore. > > I don't do Rails, so I'm not going to be of much help in suggesting > solutions, but it sounds like something about how sessions are being > handled is leaving open filehandles laying around. That's why I > suggest taking the question to a Rails specific forum, where you can > probably find someone who knows the details about the session > management option that you are using, and can pinpoint the problem for > you. > > > Kirk Haines -- Posted via http://www.ruby-forum.com/. From wyhaines at gmail.com Mon Dec 17 12:40:50 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 17 Dec 2007 10:40:50 -0700 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: <130fdf8db4aa244e25a6e38b84e59ded@ruby-forum.com> References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> <6dd8fccdae1126c7944a20f4f67daed3@ruby-forum.com> <130fdf8db4aa244e25a6e38b84e59ded@ruby-forum.com> Message-ID: On Dec 17, 2007 10:30 AM, Scott Derrick wrote: > Kirk Haines wrote: > > All that makes sense if > > 1.) sessions is the problem. I upped the file handle limit to 4096 and > now I don't get an EMFILE error from mongrel, mongrel just stops > responding to requests... > > 2.) Mongrel and my Rails app share the same file handle limit? I > thought they were separate ruby apps? Or do all Ruby apps share the > same environment? Mongrel is an app container. Your Rails app runs inside the same process as Mongrel does. Mongrel wraps around it and provides the facilities to get the request from the client to your app, and the response from the app to the client. When a Mongrel seems to be hanged, have you tried running strace/truss/something-similar on it? If you are on a Linux system, you'd do something like this: strace -s8192 -v -p PID -o OUTFILE Let it go for a few seconds, then break with ctrl-c. In OUTFILE will be a bunch of lines containing the system calls that were being made inside the process. Sometimes this can give one a hint regarding where a piece of code is stuck. Kirk Haines From njvack at wisc.edu Mon Dec 17 12:56:20 2007 From: njvack at wisc.edu (Nathan Vack) Date: Mon, 17 Dec 2007 11:56:20 -0600 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: <6dd8fccdae1126c7944a20f4f67daed3@ruby-forum.com> References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> <6dd8fccdae1126c7944a20f4f67daed3@ruby-forum.com> Message-ID: <074DDA9E-1289-43C3-B46D-615D3EEABD6D@wisc.edu> On Dec 17, 2007, at 11:05 AM, Scott Derrick wrote: > The reason why I think this is a mongrel reliability issue is that > when > my mongrel server stops responding, its stops responding to everybody! > Any browser from any client machine that trys to access any page on > the > website gets "nada", no response.. > > I can't even get a page not found 404 error if I feed it a bad > address, > the mongrel server is locked up and not responding, to anybody. You generally only have one (or a few) Mongrel(s) running for everybody. That's Just How It Works. If Rails hangs in it, it'll hang for everybody. Try setting your app up using Webrick or FastCGI -- you'll very likely see similar behavior there. If Rails hangs, your web server will appear to hang -- as it will be all busy waiting for Rails to finish its job. Mongrel generally handles 404 errors even if you have something like Apache on the front end -- because you don't really have a "page" for /my_controller/ackAdjustDistance -- that URL needs to have Rails behind it. > Maybe I don't understand the linkage between my web app and the web > server, I didn't think my application by running a periodic update > could > cause the server to refuse any new connections? Its not like its > really > busy with a couple hundred requests a second, its 5 requests a second, > on a fast server? Here's a question -- does your app run forever without the periodic updater? Can you make hundreds / thousands of requests and never see a problem? Also -- watch your ajax requests with Firebug -- do they all succeed until, finally, one hangs? The solution is almost certainly gonna be in your application code or in your Rails setup -- there's something in there that's not releasing a limited resource. Increasing resource limits, adding Mongrels, switching app servers... these will all, at best, delay the onset of symptoms. Cheers, -Nate PS - At the risk of going too far off-topic... Calibration.getMessage () looks like an interesting line of code. Is there any chance that function blocks while waiting for something to happen? Or maybe it, say, reads from a file but doesn't properly close it? Or has the possibility of a race condition and Bad Behavior if something updates the message while getMessage() is running? From luislavena at gmail.com Mon Dec 17 14:18:51 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 17 Dec 2007 16:18:51 -0300 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> Message-ID: <71166b3b0712171118i555bb6c3m4d458c46b447527b@mail.gmail.com> On Dec 17, 2007 12:16 PM, Scott Derrick wrote: > Kirk Haines wrote: > > Nobody else has said it, so I will. > > This is not a Mongrel problem. > > Kirk, > > thats certainly possible thats its not a problem specific to Mongrel. I > think its more likely related to my upgrade to Ruby 2.0.1. Its also > possible its a CGI problem as CGi is used for session store to memory or > pstore. > First, sorry If I'm not polite enough, but why you upgrade something if isn't broken? Also, why did you upgrade a production site/application without prior sandboxing/staging test of it? > It is odd that what ever the problem, Mongrel crashes.. It won't > respond to any http request from any client. Its dead in the water. Mongrel isn't crashing, the app that runs on top of it isn't returning control to it to keep serving request. Both Mongrel and Rails share the same process: Rails is a web framework that needs a HTTP server. Mongrel is an HTTP server that parse HTTP request and send them to Rails. Period. Rails (not ruby) is unsafe to handle more than 1 request at the time, that's why you need a cluster of mongrels to server a middle-to-high traffic site. Draw a line between them. Mongrel do not crash your application, your application isn't returning control to Mongrel to keep serving other requests. Also you should start checking your log files to see what was the latests request served by your rails application, if somehow that could help you. > That makes it a Mongrel problem in my eyes, at least to anybody who > cares if Mongrel is reliable or not. Again, you should take as policy test everything in development, then staging and _then_ production. Blaming Mongrel because your rails application hang isn't something will help you get the right answer to fix your problem. To consider it a problem, you should also need to test other scenarios, which you didn't. a plain script/server webrick -e production worked for you? I know that will not be performance wise, but at least, you can see what isn't working. Also you can test the FastCGI scenario and see if that work. The EMFILE limit is because something in Rails side is exhausting file handles: too many render :partial too many orphaned (not garbage collected TempFiles) PStore is a option of session storage of Rails, not Mongrel. PStore uses 1 temp file per session, being a session each individual user requesting a page. You need to look at Rails documentation to properly upgrade your Rails 1.x application to 2.x, and do it on testing before doing on production! -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From daniel at liveoakinteractive.com Mon Dec 17 18:03:36 2007 From: daniel at liveoakinteractive.com (Daniel Lindsley) Date: Mon, 17 Dec 2007 17:03:36 -0600 Subject: [Mongrel] "mongrel_rails start" does absolutely nothing. Message-ID: <1adb06e40712171503h32fbb582pc0b30b00a16c6d8f@mail.gmail.com> I'm having a strange issue with Mongrel. Post-install of Mac OS X 10.5, my Mongrel will not start under any circumstances. I've already removed ("sudo gem uninstall mongrel"), ran "gem cleanup" to remove old versions and then installed the latest gem version (1.1.2). When I run "mongrel_rails start" anywhere (inside a fresh Rails app, random place on the filesystem), I receive no output and eventually have to kill it, at which point I get a backtrace, which is different everytime I run it. I've tried specifying where the log file goes (no output), running with --debug (again, no output) and have searched on Google without success. I've tried running it as both myself and "sudo" without success. There are no other mongrels running on my machine. My Ruby is the Mac OS X 10.5 default (patched 1.8.6) running in the standard location. If anyone could provide some thoughts on what might be wrong and what else to try, I would greatly appreciate and be happy to provide whatever additional information is needed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071217/92eb471d/attachment.html From vanwie at gmail.com Mon Dec 17 19:10:23 2007 From: vanwie at gmail.com (Michael Van Wie) Date: Mon, 17 Dec 2007 16:10:23 -0800 Subject: [Mongrel] Long-running pages cause mongrel time-outs Message-ID: <90e237c10712171610j1ac9f374lfeb963c69493eaca@mail.gmail.com> Hi all, We use mongrel behind apache (using mod_proxy_balancer) to run an internal app for our business. Lately we've been seeing frequent errors from some of our mongrel processes. [Sun Dec 16 08:48:47 2007] [error] [client ] (70007)The timeout specified has expired: proxy: error reading status line from remote server 127.0.0.1, referer: http:// [Sun Dec 16 08:48:47 2007] [error] [client ] proxy: Error reading from remote server returned by /, referer: http:// [Sun Dec 16 08:49:08 2007] [error] [client ] (70007)The timeout specified has expired: proxy: error reading status line from remote server 127.0.0.1 [Sun Dec 16 08:49:08 2007] [error] [client ] proxy: Error reading from remote server returned by / The problem seems to be that the long-running request hogs a mongrel process, and when apache sends the next request to it (after a round-robin tour through the other 9 mongrels), that request times out too. The original action eventually comes back, but sometimes not for several minutes, so we can timeout on many requests in a row. I've seen problems like this mentioned in the context of file uploads (which explain some of our long-running requests), but I've never seen a fix posted. Maybe I haven't looked hard enough? Does anyone know of a config fix that will skip over these blocked processes? Thanks! Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071217/ad763669/attachment.html From ezmobius at gmail.com Mon Dec 17 19:18:30 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Mon, 17 Dec 2007 16:18:30 -0800 Subject: [Mongrel] Long-running pages cause mongrel time-outs In-Reply-To: <90e237c10712171610j1ac9f374lfeb963c69493eaca@mail.gmail.com> References: <90e237c10712171610j1ac9f374lfeb963c69493eaca@mail.gmail.com> Message-ID: <90513727-903F-4BA7-9B04-4076444FDB12@gmail.com> On Dec 17, 2007, at 4:10 PM, Michael Van Wie wrote: > Hi all, > > We use mongrel behind apache (using mod_proxy_balancer) to run an > internal app for our business. Lately we've been seeing frequent > errors from some of our mongrel processes. > > [Sun Dec 16 08:48:47 2007] [error] [client ] (70007)The > timeout specified has expired: proxy: error reading status line from > remote server 127.0.0.1, referer: http:// > [Sun Dec 16 08:48:47 2007] [error] [client ] proxy: Error > reading from remote server returned by /, > referer: http:// > [Sun Dec 16 08:49:08 2007] [error] [client ] (70007)The > timeout specified has expired: proxy: error reading status line from > remote server 127.0.0.1 > [Sun Dec 16 08:49:08 2007] [error] [client ] proxy: Error > reading from remote server returned by / > > The problem seems to be that the long-running request hogs a mongrel > process, and when apache sends the next request to it (after a round- > robin tour through the other 9 mongrels), that request times out > too. The original action eventually comes back, but sometimes not > for several minutes, so we can timeout on many requests in a row. > > I've seen problems like this mentioned in the context of file > uploads (which explain some of our long-running requests), but I've > never seen a fix posted. Maybe I haven't looked hard enough? Does > anyone know of a config fix that will skip over these blocked > processes? > > Thanks! > Mike > The best thing to do is to move any of your long running tasks off into a work queue and out of the mongrel/rails request response cycle. Something like Bj woudl help: http://codeforpeople.rubyforge.org/svn/bj/trunk/README But I think there has been apache mod_proxy_balancer configs posted to this list in the past few months that will only send one request to a mongrel at a time, search the archives. or if you can use nginx instead there is a new fair proxy balancer for nginx that works well. http://brainspl.at/articles/2007/11/09/a-fair-proxy-balancer-for-nginx-and-mongrel Cheers- - Ezra Zygmuntowicz -- Founder & Software Architect -- ezra at engineyard.com -- EngineYard.com From random49k at gmail.com Mon Dec 17 20:54:04 2007 From: random49k at gmail.com (Mike Garey) Date: Mon, 17 Dec 2007 20:54:04 -0500 Subject: [Mongrel] Using mod_xsendfile and x_send_file with Mongrel Message-ID: <16a8b9140712171754i2cf0056cic3dc926cd9cb0d2a@mail.gmail.com> Can anyone tell me how to get x_send_file working with mongrel 1.1.1 and apache 2.2? I've installed the mod_xsendfile apache module from http://tn123.ath.cx/mod_xsendfile/ and it works fine serving content from a PHP script, but I can't get it to work with my single Mongrel instance and ProxyPass. I'm using the following Apache configuration: ServerName myserver.com XSendFile on XSendFileAllowAbove on ProxyPass /images ! ProxyPass /stylesheets ! #continue with other static files that should be served by apache Alias /images /home/user/myserver/public/images Alias /stylesheets /home/user/myserver/public/stylesheets #continue with aliases for static content ProxyPass / http://localhost:8000/ ProxyPassReverse / http://localhost:8000/ ProxyPreserveHost on mongrel.yml: --- :host: 127.0.0.1 :throttle: 0 :includes: :docroot: public :debug: false :mime_map: :port: 8000 :timeout: 60 :num_processors: :config_script: :daemon: true :group: adam :environment: development :pid_file: log/mongrel.pid :cwd: /usr/home/user/myserver :prefix: :user: user :group: user :log_file: log/mongrel.log when I use x_send_file with the following in one of my rails controllers: x_send_file(@order.file_name, :type => 'text/plain; charset=us-ascii', :disposition => 'inline') I get the following error in my apache log: No such file or directory: xsendfile: cannot open file: proxy:http://localhost:8000/admin/orders/send_raw_order_file/1/my_order_file.txt I've tried a few things but I can't seem to get past this error.. I had a feeling it was because Apache was still trying to pass the request through the proxy, which was prepending the http://localhost:8000 to the url, which may have cause dthe error, but I've tried it with a stylesheet file in my public/stylesheets dir (which is _not_ proxied - ie will still be served if Mongrel is shut down) and I still get the same error. I have a feeling I'm missing something pretty simple, since it seems that most other people have managed to get this up and running without too much difficulty. If anyone has any suggestions, please let me know! Thanks, Mke From pete at nextengine.com Mon Dec 17 20:42:51 2007 From: pete at nextengine.com (Pete DeLaurentis) Date: Mon, 17 Dec 2007 17:42:51 -0800 Subject: [Mongrel] Mongrel + Lighttpd Message-ID: Hi guys, I've been chasing a problem in my web-stack: Lighttpd -> Mongrel -> Rails, and found a problem with the interaction of Lighttpd and Mongrel. If a request takes more than 5 seconds, Lighty will retry it - and then the requests / responses get mixed up in Lighty and it returns a bad response to the client. Not good. I'm convinced that the problem is completely on the Lighttpd side. Why I'm posting to the group: 1. I was wondering if anyone has had success using Lighttpd's 1.5.0 mod_proxy_core to talk to pack of Mongrels. (Maybe there is a different setting I need in Mongrel or in Lighty) 2. I'm also considering nginx and wanted to see if anyone recommended using this with Mongrel in a production environment. For me, a crucial capability is X-Sendfile (or something similiar). Thanks for the help, Pete From ezmobius at gmail.com Mon Dec 17 21:21:10 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Mon, 17 Dec 2007 18:21:10 -0800 Subject: [Mongrel] Mongrel + Lighttpd In-Reply-To: References: Message-ID: <18B9DF2B-F860-4058-B4D3-6CEE24E60767@gmail.com> On Dec 17, 2007, at 5:42 PM, Pete DeLaurentis wrote: > Hi guys, > > I've been chasing a problem in my web-stack: Lighttpd -> Mongrel -> > Rails, and found a problem with the interaction of Lighttpd and > Mongrel. > > If a request takes more than 5 seconds, Lighty will retry it - and > then the requests / responses get mixed up in Lighty and it returns a > bad response to the client. Not good. > > I'm convinced that the problem is completely on the Lighttpd side. > > Why I'm posting to the group: > > 1. I was wondering if anyone has had success using Lighttpd's 1.5.0 > mod_proxy_core to talk to pack of Mongrels. (Maybe there is a > different setting I need in Mongrel or in Lighty) > > 2. I'm also considering nginx and wanted to see if anyone recommended > using this with Mongrel in a production environment. For me, a > crucial capability is X-Sendfile (or something similiar). > > Thanks for the help, > Pete Nginx works much better then lighttpd for proxying to mongrels. Nginx has X-Accell-Redirect which is basically same thing as X-Send_file. Cheers- - Ezra Zygmuntowicz -- Founder & Software Architect -- ezra at engineyard.com -- EngineYard.com From dave at cheney.net Mon Dec 17 21:23:22 2007 From: dave at cheney.net (Dave Cheney) Date: Tue, 18 Dec 2007 13:23:22 +1100 Subject: [Mongrel] Mongrel + Lighttpd In-Reply-To: References: Message-ID: <8696075B-F036-40EC-A476-E37878C030AF@cheney.net> We ditched apache for nginx (didn't consider lighttpd as the ruby guys on the team said the rails community had move away from it) and can't recommend it highly enough. nginx has sendfile support, its slightly different to xsendfile, http://blog.kovyrin.net/2006/11/01/nginx-x-accel-redirect-php-rails/ Cheers Dave On 18/12/2007, at 12:42 PM, Pete DeLaurentis wrote: > > 2. I'm also considering nginx and wanted to see if anyone recommended > using this with Mongrel in a production environment. For me, a > crucial capability is X-Sendfile (or something similiar). From pete at nextengine.com Mon Dec 17 22:31:32 2007 From: pete at nextengine.com (Pete DeLaurentis) Date: Mon, 17 Dec 2007 19:31:32 -0800 Subject: [Mongrel] Mongrel + Lighttpd In-Reply-To: <8696075B-F036-40EC-A476-E37878C030AF@cheney.net> References: <8696075B-F036-40EC-A476-E37878C030AF@cheney.net> Message-ID: Hi Dave and Ezra, Thanks for the advice. Time to start reading up on Nginx and X- Accell-Redirect... Cheers, Pete On Dec 17, 2007, at 6:23 PM, Dave Cheney wrote: > We ditched apache for nginx (didn't consider lighttpd as the ruby guys > on the team said the rails community had move away from it) and can't > recommend it highly enough. > > nginx has sendfile support, its slightly different to xsendfile, > > http://blog.kovyrin.net/2006/11/01/nginx-x-accel-redirect-php-rails/ > > Cheers > > Dave > > > Nginx works much better then lighttpd for proxying to mongrels. Nginx > has X-Accell-Redirect which is basically same thing as X-Send_file. > > Cheers- > - Ezra Zygmuntowicz > -- Founder & Software Architect > -- ezra at engineyard.com > -- EngineYard.com > On 18/12/2007, at 12:42 PM, Pete DeLaurentis wrote: > >> >> 2. I'm also considering nginx and wanted to see if anyone recommended >> using this with Mongrel in a production environment. For me, a >> crucial capability is X-Sendfile (or something similiar). > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From masonhale at gmail.com Tue Dec 18 13:34:54 2007 From: masonhale at gmail.com (Mason Hale) Date: Tue, 18 Dec 2007 12:34:54 -0600 Subject: [Mongrel] Long-running pages cause mongrel time-outs In-Reply-To: <90513727-903F-4BA7-9B04-4076444FDB12@gmail.com> References: <90e237c10712171610j1ac9f374lfeb963c69493eaca@mail.gmail.com> <90513727-903F-4BA7-9B04-4076444FDB12@gmail.com> Message-ID: <8bca3aa10712181034m79968dd4he6fa91ea44e3d2d6@mail.gmail.com> Hi Ezra -- I found it interesting that you recommended Bj (backgroundjobs) and not BackgrounDrb. I hadn't heard of Bj before, and I'll check it out. Thanks for the link. Given that you initiated the development BackgrounDrb, I'm curious when and where you would recommend Bj over BackgrounDrb. Mason On Dec 17, 2007 6:18 PM, Ezra Zygmuntowicz wrote: > > The best thing to do is to move any of your long running tasks off > into a work queue and out of the mongrel/rails request response cycle. > Something like Bj woudl help: > > http://codeforpeople.rubyforge.org/svn/bj/trunk/README > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071218/735991e7/attachment.html From evan at cloudbur.st Tue Dec 18 15:36:14 2007 From: evan at cloudbur.st (Evan Weaver) Date: Tue, 18 Dec 2007 15:36:14 -0500 Subject: [Mongrel] Long-running pages cause mongrel time-outs In-Reply-To: <8bca3aa10712181034m79968dd4he6fa91ea44e3d2d6@mail.gmail.com> References: <90e237c10712171610j1ac9f374lfeb963c69493eaca@mail.gmail.com> <90513727-903F-4BA7-9B04-4076444FDB12@gmail.com> <8bca3aa10712181034m79968dd4he6fa91ea44e3d2d6@mail.gmail.com> Message-ID: There's a library called Spawn, too, which is nice for doing asynchronous but still request-triggered background processing. It might get less nice once 1.9 comes around, though, but... bridges when we come to them. Evan On Dec 18, 2007 1:34 PM, Mason Hale wrote: > Hi Ezra -- > > I found it interesting that you recommended Bj (backgroundjobs) and not > BackgrounDrb. I hadn't heard of Bj before, and I'll check it out. Thanks for > the link. Given that you initiated the development BackgrounDrb, I'm curious > when and where you would recommend Bj over BackgrounDrb. > > Mason > > > > > On Dec 17, 2007 6:18 PM, Ezra Zygmuntowicz wrote: > > > > > > > > > > The best thing to do is to move any of your long running tasks off > > into a work queue and out of the mongrel/rails request response cycle. > > Something like Bj woudl help: > > > > http://codeforpeople.rubyforge.org/svn/bj/trunk/README > > > > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From jacob at jacobatzen.dk Tue Dec 18 16:38:28 2007 From: jacob at jacobatzen.dk (Jacob Atzen) Date: Tue, 18 Dec 2007 22:38:28 +0100 Subject: [Mongrel] Long-running pages cause mongrel time-outs In-Reply-To: References: <90e237c10712171610j1ac9f374lfeb963c69493eaca@mail.gmail.com> <90513727-903F-4BA7-9B04-4076444FDB12@gmail.com> <8bca3aa10712181034m79968dd4he6fa91ea44e3d2d6@mail.gmail.com> Message-ID: <47683DD4.3070608@jacobatzen.dk> Evan Weaver wrote: > There's a library called Spawn, too, which is nice for doing > asynchronous but still request-triggered background processing. It > might get less nice once 1.9 comes around, though, but... bridges when > we come to them. My Google-fu is eluding me. Can someone point me to somewhere I can learn more about Spawn? -- Cheers, - Jacob Atzen From evan at cloudbur.st Tue Dec 18 17:49:48 2007 From: evan at cloudbur.st (Evan Weaver) Date: Tue, 18 Dec 2007 17:49:48 -0500 Subject: [Mongrel] Long-running pages cause mongrel time-outs In-Reply-To: <47683DD4.3070608@jacobatzen.dk> References: <90e237c10712171610j1ac9f374lfeb963c69493eaca@mail.gmail.com> <90513727-903F-4BA7-9B04-4076444FDB12@gmail.com> <8bca3aa10712181034m79968dd4he6fa91ea44e3d2d6@mail.gmail.com> <47683DD4.3070608@jacobatzen.dk> Message-ID: http://rubyforge.org/projects/spawn/ On Dec 18, 2007 4:38 PM, Jacob Atzen wrote: > Evan Weaver wrote: > > There's a library called Spawn, too, which is nice for doing > > asynchronous but still request-triggered background processing. It > > might get less nice once 1.9 comes around, though, but... bridges when > > we come to them. > > My Google-fu is eluding me. Can someone point me to somewhere I can > learn more about Spawn? > > -- > Cheers, > - Jacob Atzen > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From jason at joyent.com Tue Dec 18 17:47:57 2007 From: jason at joyent.com (Jason A. Hoffman) Date: Tue, 18 Dec 2007 14:47:57 -0800 Subject: [Mongrel] Long-running pages cause mongrel time-outs In-Reply-To: <47683DD4.3070608@jacobatzen.dk> References: <90e237c10712171610j1ac9f374lfeb963c69493eaca@mail.gmail.com> <90513727-903F-4BA7-9B04-4076444FDB12@gmail.com> <8bca3aa10712181034m79968dd4he6fa91ea44e3d2d6@mail.gmail.com> <47683DD4.3070608@jacobatzen.dk> Message-ID: <7A6AFEF3-76BD-488C-84F8-5B57ECA5A233@joyent.com> On Dec 18, 2007, at 1:38 PM, Jacob Atzen wrote: > Evan Weaver wrote: >> There's a library called Spawn, too, which is nice for doing >> asynchronous but still request-triggered background processing. It >> might get less nice once 1.9 comes around, though, but... bridges >> when >> we come to them. > > My Google-fu is eluding me. Can someone point me to somewhere I can > learn more about Spawn? > > -- > Cheers, > - Jacob Atzen http://rubyforge.org/projects/spawn/ - Jason From lists at ruby-forum.com Wed Dec 19 05:42:43 2007 From: lists at ruby-forum.com (Joerg Diekmann) Date: Wed, 19 Dec 2007 11:42:43 +0100 Subject: [Mongrel] Cluster, upload progress and sessions Message-ID: <96ca34a3bf142612778797e055131cb1@ruby-forum.com> Hi, I have a mongrel cluster with a mongrel_upload_progress ... when I upload a file, my cookie session id changes .... So on the upload form, my Session ID is say: BAh7ByIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%0ASGFzaHsABjoKQHVzZWR7ADoOcmV0dXJuX3RvIj8vdXBsb2FkL25vdz91cGxv%0AYWRfaWQ9M2Q0MzJiN2UtYWUxYy0xMWRjLTgzNDEtMDAxNTE3NGE0NDVj--9a36dd5853f963386ba042995bf66630c0b5734f And when I do my multi-part form POST, after Mongrel's dealt with the whole upload and passes the request on to Rails, my session has changed to: BAh7ByIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%0ASGFzaHsABjoKQHVzZWR7ADoOcmV0dXJuX3RvIj8vdXBsb2FkL25vdz91cGxv%0AYWRfaWQ9M2M4ZmM5YzQtYWUxOS0xMWRjLThlMWItMDAxNTE3NGE0NDVj--13fb2eb052168b2860bac39b2d14839bb9ed6979 Normal requests after that revert back to the initial Session ID ... You can see that just that last portion changes. If I don't run a cluster - ie on my development machine, it works fine. Why is that? The effect is that my user is not logged in for the upload post ... which means the filter chain redirects me to log in. :-( Thanks Joerg -- Posted via http://www.ruby-forum.com/. From public at misuse.org Wed Dec 19 12:01:26 2007 From: public at misuse.org (Steve Midgley) Date: Wed, 19 Dec 2007 09:01:26 -0800 Subject: [Mongrel] Long-running pages cause mongrel time-outs In-Reply-To: References: Message-ID: <20071219170145.3FD2415F8014@rubyforge.org> At 02:42 AM 12/19/2007, mongrel-users-request at rubyforge.org wrote: >Message: 6 >Date: Tue, 18 Dec 2007 12:34:54 -0600 >From: "Mason Hale" >Subject: Re: [Mongrel] Long-running pages cause mongrel time-outs >To: mongrel-users at rubyforge.org >Message-ID: > <8bca3aa10712181034m79968dd4he6fa91ea44e3d2d6 at mail.gmail.com> >Content-Type: text/plain; charset="iso-8859-1" > >Hi Ezra -- > >I found it interesting that you recommended Bj (backgroundjobs) and >not >BackgrounDrb. I hadn't heard of Bj before, and I'll check it out. >Thanks for >the link. Given that you initiated the development BackgrounDrb, I'm >curious >when and where you would recommend Bj over BackgrounDrb. > >Mason Hi Mason, I found this link which clearly illuminates your question. http://groups.google.com/group/ruby-talk-google/browse_frm/thread/144e9b3644ffe88e#38b99ec30098b956 In short: BackgroundRb relies on slave.rb (maintained by Ara T Howard, the author of Bj), and Ara claims only one person (Eric Hodel) understands how to use slave.rb properly: so BackgroundRb is just too complex to maintain (too much flexibility). Bj is specifically designed to address this issue. Erza's company EngineYard is one of the sponsors of Bj - so it's designed to meet some business needs of theirs (I'm a customer so that includes me!). From my analysis, Bj looks good b/c it puts the jobs into a database table so things are both persistent and scalable with very little additional infrastructure. Steve From gethemant at gmail.com Wed Dec 19 14:04:53 2007 From: gethemant at gmail.com (hemant) Date: Thu, 20 Dec 2007 00:34:53 +0530 Subject: [Mongrel] Long-running pages cause mongrel time-outs In-Reply-To: <20071219170145.3FD2415F8014@rubyforge.org> References: <20071219170145.3FD2415F8014@rubyforge.org> Message-ID: On Dec 19, 2007 10:31 PM, Steve Midgley wrote: > At 02:42 AM 12/19/2007, mongrel-users-request at rubyforge.org wrote: > >Message: 6 > >Date: Tue, 18 Dec 2007 12:34:54 -0600 > >From: "Mason Hale" > >Subject: Re: [Mongrel] Long-running pages cause mongrel time-outs > >To: mongrel-users at rubyforge.org > >Message-ID: > > <8bca3aa10712181034m79968dd4he6fa91ea44e3d2d6 at mail.gmail.com> > >Content-Type: text/plain; charset="iso-8859-1" > > > >Hi Ezra -- > > > >I found it interesting that you recommended Bj (backgroundjobs) and > >not > >BackgrounDrb. I hadn't heard of Bj before, and I'll check it out. > >Thanks for > >the link. Given that you initiated the development BackgrounDrb, I'm > >curious > >when and where you would recommend Bj over BackgrounDrb. > > > >Mason > > Hi Mason, > > I found this link which clearly illuminates your question. > > http://groups.google.com/group/ruby-talk-google/browse_frm/thread/144e9b3644ffe88e#38b99ec30098b956 > > In short: BackgroundRb relies on slave.rb (maintained by Ara T Howard, > the author of Bj), and Ara claims only one person (Eric Hodel) > understands how to use slave.rb properly: so BackgroundRb is just too > complex to maintain (too much flexibility). Bj is specifically designed > to address this issue. Thats just one side of the story. BackgrounDRb no longer depends slave.rb. Its stable as hell. There is not a single bug in BackgrounDRb that has been reported and not solved. You can checkout activity on BackgrounDRb mailing list. BackgrounDRb is not Bj however, It can be if you want to use it like that. Please check your facts before making any such claims. > > Erza's company EngineYard is one of the sponsors of Bj - so it's > designed to meet some business needs of theirs (I'm a customer so that > includes me!). > > From my analysis, Bj looks good b/c it puts the jobs into a database > table so things are both persistent and scalable with very little > additional infrastructure. > > Steve > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org From ezmobius at gmail.com Wed Dec 19 16:08:32 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Wed, 19 Dec 2007 13:08:32 -0800 Subject: [Mongrel] Long-running pages cause mongrel time-outs In-Reply-To: <20071219170145.3FD2415F8014@rubyforge.org> References: <20071219170145.3FD2415F8014@rubyforge.org> Message-ID: On Dec 19, 2007, at 9:01 AM, Steve Midgley wrote: > At 02:42 AM 12/19/2007, mongrel-users-request at rubyforge.org wrote: >> Message: 6 >> Date: Tue, 18 Dec 2007 12:34:54 -0600 >> From: "Mason Hale" >> Subject: Re: [Mongrel] Long-running pages cause mongrel time-outs >> To: mongrel-users at rubyforge.org >> Message-ID: >> <8bca3aa10712181034m79968dd4he6fa91ea44e3d2d6 at mail.gmail.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Hi Ezra -- >> >> I found it interesting that you recommended Bj (backgroundjobs) and >> not >> BackgrounDrb. I hadn't heard of Bj before, and I'll check it out. >> Thanks for >> the link. Given that you initiated the development BackgrounDrb, I'm >> curious >> when and where you would recommend Bj over BackgrounDrb. >> >> Mason Backgroundrb and Bj serve different purposes. The new backgroundrb is a complete rewrite by Hemant that throws out drb and uses an event driven styel of programming. It really is very stable now and it's main focus is on doing jobs that require reporting status in your rails app. Like if you want to fetch some news feeds and report a progress bar via ajax polling in your app. Bdrb works very well for this and other more real time background jobs. Bj is a work queue. You just shove jobs into the queue which is a database table and the Bj daemon will run through them and call each job one at a time. But you can also have Bj daemons on each node in a cluster of servers and have them all pulling from the same queue. Bj jobs are just shell commands. So your actual jobs can be ruby scripts, shell scripts, or script/runner calls. The main idea behind Bj is that you could throw 100K jobs at it and it will just do them as fast as it can one at a time without overwhelming the system all at once. So both of these tools are very solid now, they just serve different purposes. Backgroiundrb is more for real time jobs and status reports as well as having a very nice cron like scheduler for jobs. Bj is more of a work queue that is persistent. Hope that clears things up, Both of these tools are great for different circumstances. Cheers- - Ezra Zygmuntowicz -- Founder & Software Architect -- ezra at engineyard.com -- EngineYard.com From lists at ruby-forum.com Wed Dec 19 17:51:55 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Wed, 19 Dec 2007 23:51:55 +0100 Subject: [Mongrel] Segmentation fault in Mongrel when run with --debug Message-ID: I am having a problem with mongrel just stopping inside a periodically_call_remote function so I ran mongrel with debug enabled Mongrel seg faults after a few minutes The mongrel filelog shows 5 files open when this happens. Same log files that are open all the time. Wed Dec 19 15:10:21 -0700 2007 FILES OPEN BEFORE REQUEST /calibration/ackAdjustDistance --- log/mongrel_debug/objects.log: 2 /home/scott/NetBeansProjects/webmonitor/config/../log/development.log: 1 log/mongrel_debug/rails.log: 1 log/mongrel_debug/files.log: 1 log/mongrel_debug/threads.log: 1 log/mongrel_debug/access.log: 1 There are 2 threads running Wed Dec 19 15:10:21 -0700 2007 REQUEST /calibration/ackAdjustDistance 0.0.0.0:3000 -- THREADS: 2 ----- KEYS: -- #: [:started_on] -- #: [:started_on, :__inspect_key__] Mongrel stops with this output to stdout. 127.0.0.1 - [Wed, 19 Dec 2007 22:10:17 GMT] "POST /calibration/ackAdjustDistance HTTP/1.1" 127.0.0.1 - [Wed, 19 Dec 2007 22:10:19 GMT] "POST /calibration/ackAdjustDistance HTTP/1.1" 127.0.0.1 - [Wed, 19 Dec 2007 22:10:21 GMT] "POST /calibration/ackAdjustDistance HTTP/1.1" /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel/debug.rb:128: [BUG] Segmentation fault ruby 1.8.6 (2007-09-24) [i686-linux] the last part of the development log is Processing CalibrationController#ackAdjustDistance (for 127.0.0.1 at 2007-12-19 15:10:23) [POST] Session ID: 5f0b23a7ae94ac5648268113cd3b4560 Parameters: {"action"=>"ackAdjustDistance", "controller"=>"calibration"} Calibration Load (0.000802) SELECT * FROM configurations WHERE (Name = 'CalibrationMessage') LIMIT 1 DEPRECATION WARNING: @session is deprecated! Call session.respond_to? instead of @session.respond_to?. Args: [:length] See http://www.rubyonrails.org/deprecation for details. (called from process at /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel/debug.rb:128) Completed in 0.03658 (27 reqs/sec) | Rendering: 0.00144 (3%) | 200 OK [http://localhost/calibration/ackAdjustDistance] DEPRECATION WARNING: @session is deprecated! Call session.class instead of @session.class. Args: [] See http://www.rubyonrails.org/deprecation for details. (called from process at /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel/debug.rb:136) DEPRECATION WARNING: @response is deprecated! Call response.respond_to? instead of @response.respond_to?. Args: [:length] See http://www.rubyonrails.org/deprecation for details. (called from process at /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/../lib/mongrel/debug.rb:128) both outputs refer to debug.rb line 128 which is # stolen from Robert Klemme class Objects < GemPlugin::Plugin "/handlers" include Mongrel::HttpHandlerPlugin 121 def process(request,response) 122 begin 123 stats = Hash.new(0) 124 lengths = {} 125 begin 126 ObjectSpace.each_object do |o| 127 begin 128 if o.respond_to? :length 129 len = o.length 130 lengths[o.class] ||= Mongrel::Stats.new(o.class) 131 lengths[o.class].sample(len) 132 end 133 rescue Object 134 end anybody else seen this? thanks, Scott -- Posted via http://www.ruby-forum.com/. From zedshaw at zedshaw.com Thu Dec 20 00:41:59 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Thu, 20 Dec 2007 00:41:59 -0500 Subject: [Mongrel] Segmentation fault in Mongrel when run with --debug In-Reply-To: References: Message-ID: <20071220004159.f95435ec.zedshaw@zedshaw.com> On Wed, 19 Dec 2007 23:51:55 +0100 Scott Derrick wrote: > I am having a problem with mongrel just stopping inside a > periodically_call_remote function so I ran mongrel with debug enabled > Mongrel seg faults after a few minutes > > The mongrel filelog shows 5 files open when this happens. Same log files > that are open all the time. No idea what would cause it, since that's a simple respond to, but usually when you get segfaults in weird places it's caused by some other completely unknown library that doesn't do ram properly. What you should do is run your mongrel under gdb, when it blows up, gdb will stop and you can then use the backtrace command to see what was going on. Apart from that, not sure what else. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From paolo.campegiani at gmail.com Thu Dec 20 03:08:55 2007 From: paolo.campegiani at gmail.com (Paolo Campegiani) Date: Thu, 20 Dec 2007 09:08:55 +0100 Subject: [Mongrel] Integration of Mongrel with RHEL, Fedora and derivatives Message-ID: Hi gurus, here at Scuola IaD we have some Rails applications in production, I'm the sysadmin so I made a script for governing mongrel instances via the service command and integrating their management in a RHEL environment. This script, available with more information here: http://bitsandchaos.wordpress.com/2007/12/14/mongrel-integration-for-rhel-fedora-and-derivatives-new-release/ has these features: - it does not use mongrel_cluster; instead, each Rails application is described by a text file, that specifies also on which ports it should listen to; - it spawns a mongrel_rails instance for each port and each application; - it can selectively stop/start one application, or all of them; - it deals with the pid stale file problem, ensuring they are deleted when it's needed; - it allows for a finer grain of security, as each Rails application can be owned by a different user; in fact we are using this script for also governing mongrel instances via monit, and it's totally compatible with RHEL 4/5, Fedora and derivatives. I'm happy if someone will use it, and more happy if someone will take a look at it to suggest improvements and corrections. From lists at ruby-forum.com Thu Dec 20 12:42:20 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Thu, 20 Dec 2007 18:42:20 +0100 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: <71166b3b0712171118i555bb6c3m4d458c46b447527b@mail.gmail.com> References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> <71166b3b0712171118i555bb6c3m4d458c46b447527b@mail.gmail.com> Message-ID: I replaced mongrel with webrick and the problem went away. The offending page has been running for 45 minutes now, using mongrel I always died between 5 and 10 minutes. Guess I'll use lighthttp or something... Scott -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Thu Dec 20 12:42:47 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Thu, 20 Dec 2007 18:42:47 +0100 Subject: [Mongrel] Segmentation fault in Mongrel when run with --debug In-Reply-To: <20071220004159.f95435ec.zedshaw@zedshaw.com> References: <20071220004159.f95435ec.zedshaw@zedshaw.com> Message-ID: <8e19708262be035dd740ed7d3043bf85@ruby-forum.com> I replaced mongrel with webrick and the problem went away. The offending page has been running for 45 minutes now, using mongrel I always died between 5 and 10 minutes. Guess I'll use lighthttp or something... Scott -- Posted via http://www.ruby-forum.com/. From zedshaw at zedshaw.com Thu Dec 20 13:24:56 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Thu, 20 Dec 2007 13:24:56 -0500 Subject: [Mongrel] Segmentation fault in Mongrel when run with --debug In-Reply-To: <8e19708262be035dd740ed7d3043bf85@ruby-forum.com> References: <20071220004159.f95435ec.zedshaw@zedshaw.com> <8e19708262be035dd740ed7d3043bf85@ruby-forum.com> Message-ID: <20071220132456.1deb2c81.zedshaw@zedshaw.com> On Thu, 20 Dec 2007 18:42:47 +0100 Scott Derrick wrote: > I replaced mongrel with webrick and the problem went away. > > The offending page has been running for 45 minutes now, using mongrel I > always died between 5 and 10 minutes. > > Guess I'll use lighthttp or something... Well, webrick might be hiding a problem that's caused by speed like a race condition or similar. When your app starts to get more traffic you'll probably hit it again. Take a look at the extensions you're using. I'm betting one of them has a threading problem or isn't written correctly. And FYI, nginx, apache, and lighttpd will all work with webrick the same way they work with Mongrel. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From lists at ruby-forum.com Thu Dec 20 13:51:51 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Thu, 20 Dec 2007 19:51:51 +0100 Subject: [Mongrel] Segmentation fault in Mongrel when run with --debug In-Reply-To: <20071220132456.1deb2c81.zedshaw@zedshaw.com> References: <20071220004159.f95435ec.zedshaw@zedshaw.com> <8e19708262be035dd740ed7d3043bf85@ruby-forum.com> <20071220132456.1deb2c81.zedshaw@zedshaw.com> Message-ID: <3e0ab0b47982eab527b5f282582f4cc3@ruby-forum.com> Zed, I think your right because webrick finally stopped after about 90 minutes. It was locked up and when I killed it it complained of a deadlock. I'm now thinking it may bein a call to the sqlite3_ruby gem. I tried to run mongrel_rails under gdb but gdb complains its not the correct file type. Scott Zed A. Shaw wrote: > On Thu, 20 Dec 2007 18:42:47 +0100 > Scott Derrick wrote: > >> I replaced mongrel with webrick and the problem went away. >> >> The offending page has been running for 45 minutes now, using mongrel I >> always died between 5 and 10 minutes. >> >> Guess I'll use lighthttp or something... > > Well, webrick might be hiding a problem that's caused by speed like a > race condition or similar. When your app starts to get more traffic > you'll probably hit it again. > > Take a look at the extensions you're using. I'm betting one of them > has a threading problem or isn't written correctly. > > And FYI, nginx, apache, and lighttpd will all work with webrick the > same way they work with Mongrel. > > -- > Zed A. Shaw > - Hate: http://savingtheinternetwithhate.com/ > - Good: http://www.zedshaw.com/ > - Evil: http://yearofevil.com/ -- Posted via http://www.ruby-forum.com/. From luislavena at gmail.com Thu Dec 20 13:58:18 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 20 Dec 2007 15:58:18 -0300 Subject: [Mongrel] Segmentation fault in Mongrel when run with --debug In-Reply-To: <3e0ab0b47982eab527b5f282582f4cc3@ruby-forum.com> References: <20071220004159.f95435ec.zedshaw@zedshaw.com> <8e19708262be035dd740ed7d3043bf85@ruby-forum.com> <20071220132456.1deb2c81.zedshaw@zedshaw.com> <3e0ab0b47982eab527b5f282582f4cc3@ruby-forum.com> Message-ID: <71166b3b0712201058p17c5bde6t50e89297f4a0629a@mail.gmail.com> On Dec 20, 2007 3:51 PM, Scott Derrick wrote: > Zed, > > I think your right because webrick finally stopped after about 90 > minutes. > > It was locked up and when I killed it it complained of a deadlock. > > I'm now thinking it may bein a call to the sqlite3_ruby gem. > Oh, sqlite3 gem! I got a few segfaults with it, like unrolling transactions and other weird stuff. Still waiting for some tickets get fixed, but without luck. > I tried to run mongrel_rails under gdb but gdb complains its not the > correct file type. you need to run gdb on "ruby", not mongrel_rails (since mongrel_rails is a ruby script). gdb /path/to/ruby/ruby.exe /path/to/mongrel_rails param1 param2 param3 -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From lists at ruby-forum.com Fri Dec 21 04:54:25 2007 From: lists at ruby-forum.com (Ashish Chatterjee) Date: Fri, 21 Dec 2007 10:54:25 +0100 Subject: [Mongrel] Mongrel install crash on win32 In-Reply-To: <71166b3b0712110642g5de49e3dwac58e63f905b9ecc@mail.gmail.com> References: <78de7f038919ce30d788674eee2c3bea@ruby-forum.com> <71166b3b0711270438i3a2320cbx9ba9b31f2ece6278@mail.gmail.com> <7994e5929e93182b0dc518ef1cf5ce4a@ruby-forum.com> <71166b3b0711280816x4241035p5a01cda3ff540761@mail.gmail.com> <90a27ccce8cbbdf12ca03a36b69df66e@ruby-forum.com> <71166b3b0712110642g5de49e3dwac58e63f905b9ecc@mail.gmail.com> Message-ID: Hi Guys, I seem to be getting the same error... and I am on /9.4 of gems.. :( Any suggestions? Thanks, Ashish Luis Lavena wrote: > On Dec 11, 2007 10:03 AM, Phil Thompson wrote: >> ... >> >> Before I could do "ruby setup.rb install" I needed to do "ruby setup.rb >> config". 0.9.4 then installed although it seemed to install the docs for >> 0.9.5. >> > > Oh, I always forget about config _before_ install :-P > > The 0.9.5 docs can be removed from lib/ruby/gems/1.8/doc > > I hope Eric and the RubyGems team release a fix soon, removes the joy > of using Ruby... > > -- > Luis Lavena > Multimedia systems > - > A common mistake that people make when trying to design > something completely foolproof is to underestimate > the ingenuity of complete fools. > Douglas Adams Attachments: http://www.ruby-forum.com/attachment/1188/mongrel_install_failure.txt -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Fri Dec 21 06:17:47 2007 From: lists at ruby-forum.com (Phil Thompson) Date: Fri, 21 Dec 2007 12:17:47 +0100 Subject: [Mongrel] Mongrel install crash on win32 In-Reply-To: References: <78de7f038919ce30d788674eee2c3bea@ruby-forum.com> <71166b3b0711270438i3a2320cbx9ba9b31f2ece6278@mail.gmail.com> <7994e5929e93182b0dc518ef1cf5ce4a@ruby-forum.com> <71166b3b0711280816x4241035p5a01cda3ff540761@mail.gmail.com> <90a27ccce8cbbdf12ca03a36b69df66e@ruby-forum.com> <71166b3b0712110642g5de49e3dwac58e63f905b9ecc@mail.gmail.com> Message-ID: <2ba787bb7d3ba80769189d649eef3da6@ruby-forum.com> Mongrel is working with the latest Rails and Rubygems install. Rubygems 1.0 has been released which addresses many of the issues that Windows users have been experiencing. gem uninstall mongrel (select all versions) gem update --system gem install rails gem install mongrel Rubygems should no longer ask for a platform and should install automatically. Anyone using mongrel_service though will still have issues but it's being worked on so hoping to see a fix soon. -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Fri Dec 21 08:39:03 2007 From: lists at ruby-forum.com (Ashish Chatterjee) Date: Fri, 21 Dec 2007 14:39:03 +0100 Subject: [Mongrel] Mongrel install crash on win32 In-Reply-To: <2ba787bb7d3ba80769189d649eef3da6@ruby-forum.com> References: <78de7f038919ce30d788674eee2c3bea@ruby-forum.com> <71166b3b0711270438i3a2320cbx9ba9b31f2ece6278@mail.gmail.com> <7994e5929e93182b0dc518ef1cf5ce4a@ruby-forum.com> <71166b3b0711280816x4241035p5a01cda3ff540761@mail.gmail.com> <90a27ccce8cbbdf12ca03a36b69df66e@ruby-forum.com> <71166b3b0712110642g5de49e3dwac58e63f905b9ecc@mail.gmail.com> <2ba787bb7d3ba80769189d649eef3da6@ruby-forum.com> Message-ID: <3f0637e6320a8835d841949f7a5d73e5@ruby-forum.com> Hi Phil, Worked perfectly.. Thanks Ashish Phil Thompson wrote: > Mongrel is working with the latest Rails and Rubygems install. Rubygems > 1.0 has been released which addresses many of the issues that Windows > users have been experiencing. > > gem uninstall mongrel (select all versions) > gem update --system > gem install rails > gem install mongrel > > Rubygems should no longer ask for a platform and should install > automatically. Anyone using mongrel_service though will still have > issues but it's being worked on so hoping to see a fix soon. -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Fri Dec 21 10:37:05 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Fri, 21 Dec 2007 16:37:05 +0100 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> <71166b3b0712171118i555bb6c3m4d458c46b447527b@mail.gmail.com> Message-ID: Well, at 1 hour 15 minutes webrick froze. I had to kill it and it output two "deadlock" errors. I guess rails just can't handle running periodically_call_remote with an interval shorter than 1 second. eventually two calls are synced up and it deadlocks. the faster I run periodically.. the sooner the deadlock. If I run lighttpd as a load balancer with cluster would that alleviate the problem? If that is the problem? Scott Scott Derrick wrote: > I replaced mongrel with webrick and the problem went away. > > The offending page has been running for 45 minutes now, using mongrel I > always died between 5 and 10 minutes. > > Guess I'll use lighthttp or something... > > Scott -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Fri Dec 21 10:38:01 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Fri, 21 Dec 2007 16:38:01 +0100 Subject: [Mongrel] Segmentation fault in Mongrel when run with --debug In-Reply-To: <71166b3b0712201058p17c5bde6t50e89297f4a0629a@mail.gmail.com> References: <20071220004159.f95435ec.zedshaw@zedshaw.com> <8e19708262be035dd740ed7d3043bf85@ruby-forum.com> <20071220132456.1deb2c81.zedshaw@zedshaw.com> <3e0ab0b47982eab527b5f282582f4cc3@ruby-forum.com> <71166b3b0712201058p17c5bde6t50e89297f4a0629a@mail.gmail.com> Message-ID: <7da7d51c20ad3976712bf13d82b44775@ruby-forum.com> I thinking rails just can't handle running periodically_call_remote with an interval shorter than 1 second. eventually two calls are synced up and it deadlocks. the faster I run periodically.. the sooner the deadlock. If I run lighttpd as a load balancer with cluster would that alleviate the problem? If that is the problem? Scott -- Posted via http://www.ruby-forum.com/. From njvack at wisc.edu Fri Dec 21 12:20:51 2007 From: njvack at wisc.edu (Nathan Vack) Date: Fri, 21 Dec 2007 11:20:51 -0600 Subject: [Mongrel] Segmentation fault in Mongrel when run with --debug In-Reply-To: <7da7d51c20ad3976712bf13d82b44775@ruby-forum.com> References: <20071220004159.f95435ec.zedshaw@zedshaw.com> <8e19708262be035dd740ed7d3043bf85@ruby-forum.com> <20071220132456.1deb2c81.zedshaw@zedshaw.com> <3e0ab0b47982eab527b5f282582f4cc3@ruby-forum.com> <71166b3b0712201058p17c5bde6t50e89297f4a0629a@mail.gmail.com> <7da7d51c20ad3976712bf13d82b44775@ruby-forum.com> Message-ID: On Dec 21, 2007, at 9:38 AM, Scott Derrick wrote: > I thinking rails just can't handle running periodically_call_remote > with > an interval shorter than 1 second. eventually two calls are synced up > and it deadlocks. the faster I run periodically.. the sooner the > deadlock. Rails's code is probably OK in this case -- periodically_call_remote isn't inherently dangerous -- it just writes some javascript that periodically calls (via Prototype's Ajax.Request) a controller / action. If you use Firebug and make the same request in the console (without using p_c_r), you'll see the exact same problem after several (hundred?) requests. The problem is probably (almost certainly) in either code you've written or in a library you're using. gdb will help you out here. Really, though, this is offtopic for Mongrel's list -- either the Rails list or the Ruby list is a better match for these problems. The Rails IRC channel might also be useful. Or contact me off-list, and I'll help if I can... > If I run lighttpd as a load balancer with cluster would that alleviate > the problem? If that is the problem? Nope; it'll just put off the inevitable. You need to find and fix the deadlocking code. This can be challenging; race conditions are one of the least fun parts of programming. Cheers, -Nate From luislavena at gmail.com Fri Dec 21 14:29:51 2007 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 21 Dec 2007 16:29:51 -0300 Subject: [Mongrel] Mongrel error : EMFILE too many open files In-Reply-To: References: <71166b3b0712141425gb291615m52e16329f96100f2@mail.gmail.com> <5740796dd1b7b0be8e826b6cbee13dd8@ruby-forum.com> <5a11e9716f7a53405b50f29c5ea9eb67@ruby-forum.com> <71166b3b0712171118i555bb6c3m4d458c46b447527b@mail.gmail.com> Message-ID: <71166b3b0712211129o6ab6fb99ma96ee4f27c709705@mail.gmail.com> On Dec 21, 2007 12:37 PM, Scott Derrick wrote: > Well, at 1 hour 15 minutes webrick froze. I had to kill it and it > output two "deadlock" errors. > > I guess rails just can't handle running periodically_call_remote with an > interval shorter than 1 second. eventually two calls are synced up and > it deadlocks. the faster I run periodically.. the sooner the deadlock. > You're trying to handle too many things in less than 1 second, and just 1 instance of most of web frameworks in ruby will not handle it properly. I don't know if periodically_call_remote opens a new connection to the server, but that could mean it's exhausting available file handlers and thus, ending in the problem you're getting. Maybe you need a different approach to this problem, why not push server instead of pulling ones? Take a look at comet-like functionality from javascript side to server side. > If I run lighttpd as a load balancer with cluster would that alleviate > the problem? If that is the problem? Alleviate: yes, solve: no- As I said, you need a different strategy of this problem, and not "drop more hardware to the problem" -- this will not solve it, just delay the inevitable end: server crash. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From lists at ruby-forum.com Fri Dec 21 19:26:12 2007 From: lists at ruby-forum.com (Scott Derrick) Date: Sat, 22 Dec 2007 01:26:12 +0100 Subject: [Mongrel] Segmentation fault in Mongrel when run with --debug In-Reply-To: References: <20071220004159.f95435ec.zedshaw@zedshaw.com> <8e19708262be035dd740ed7d3043bf85@ruby-forum.com> <20071220132456.1deb2c81.zedshaw@zedshaw.com> <3e0ab0b47982eab527b5f282582f4cc3@ruby-forum.com> <71166b3b0712201058p17c5bde6t50e89297f4a0629a@mail.gmail.com> <7da7d51c20ad3976712bf13d82b44775@ruby-forum.com> Message-ID: Nathan Vack wrote: > Rails's code is probably OK in this case -- periodically_call_remote > isn't inherently dangerous -- it just writes some javascript that > periodically calls (via Prototype's Ajax.Request) a controller / > action. If you use Firebug and make the same request in the console > (without using p_c_r), you'll see the exact same problem after > several (hundred?) requests. > > The problem is probably (almost certainly) in either code you've > written or in a library you're using. gdb will help you out here. I am making a find(.. call which uses the sqlite3 gem > Really, though, this is offtopic for Mongrel's list -- either the > Rails list or the Ruby list is a better match for these problems. The > Rails IRC channel might also be useful. Or contact me off-list, and > I'll help if I can... thats true if its not a mongrel problem. I am pursuing a solution on other forums. thanks, Scott -- Posted via http://www.ruby-forum.com/. From stephen.bannasch at deanbrook.org Sat Dec 22 10:29:54 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sat, 22 Dec 2007 10:29:54 -0500 Subject: [Mongrel] error when installing on jruby (fastthread dependency) Message-ID: I'm running jruby trunk which has integrated rubygems 1.0.0 and when I try and install mongrel with gem it blows up when the fastthread dependency tries to do a native compilation. I couldn't find a copy of the gemspec in the svn checkout but looking at the one installed when gem installing mongrel didn't show any platform differentiation. There is platform differentiation in the rake file. It looks like the gemspec is derived somehow from the rake task (the rake file is in the gemspec as comments). Here's the error when I try and install mongrel: $ gem install mongrel -V Installing gem fastthread-1.0.1 /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread-1.0.1/test/test_queue.rb /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread-1.0.1/test/test_mutex.rb /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread-1.0.1/test/test_condvar.rb /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread-1.0.1/test/test_all.rb /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread-1.0.1/setup.rb /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread-1.0.1/Manifest /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread-1.0.1/ext/fastthread/fastthread.c /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread-1.0.1/ext/fastthread/extconf.rb /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread-1.0.1/CHANGELOG /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread-1.0.1/fastthread.gemspec Building native extensions. This could take a while... extconf.rb:1:in `require': no such file to load -- mkmf (LoadError) ERROR: Error installing mongrel: ERROR: Failed to build gem native extension. bug report filed: http://rubyforge.org/tracker/index.php?func=detail&aid=16517&group_id=1306&atid=5145 From wayneeseguin at gmail.com Sat Dec 22 10:55:19 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Sat, 22 Dec 2007 10:55:19 -0500 Subject: [Mongrel] error when installing on jruby (fastthread dependency) In-Reply-To: References: Message-ID: On Dec 22, 2007 10:29 AM, Stephen Bannasch wrote: > I'm running jruby trunk which has integrated rubygems 1.0.0 and when > I try and install mongrel with gem it blows up when the fastthread > dependency tries to do a native compilation. > > I couldn't find a copy of the gemspec in the svn checkout but looking > at the one installed when gem installing mongrel didn't show any > platform differentiation. There is platform differentiation in the > rake file. > > It looks like the gemspec is derived somehow from the rake task (the > rake file is in the gemspec as comments). > > Here's the error when I try and install mongrel: > > $ gem install mongrel -V > Installing gem fastthread-1.0.1 > /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread- > 1.0.1/test/test_queue.rb > /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread- > 1.0.1/test/test_mutex.rb > /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread- > 1.0.1/test/test_condvar.rb > /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread- > 1.0.1/test/test_all.rb > /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread- > 1.0.1/setup.rb > /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread- > 1.0.1/Manifest > /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread- > 1.0.1/ext/fastthread/fastthread.c > /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread- > 1.0.1/ext/fastthread/extconf.rb > /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread- > 1.0.1/CHANGELOG > /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/gems/1.8/gems/fastthread- > 1.0.1/fastthread.gemspec > Building native extensions. This could take a while... > extconf.rb:1:in `require': no such file to load -- mkmf (LoadError) > ERROR: Error installing mongrel: > ERROR: Failed to build gem native extension. > > Stephen, Could you please verify that this issue has not been fixed on Mongrel trunk? Thank you! ~Wayne (use rake install to install from trunk) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071222/bcef6cc1/attachment-0001.html From stephen.bannasch at deanbrook.org Sat Dec 22 17:48:13 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sat, 22 Dec 2007 17:48:13 -0500 Subject: [Mongrel] error when installing on jruby (fastthread dependency) In-Reply-To: References: Message-ID: At 10:55 AM -0500 12/22/07, Wayne E. Seguin wrote: >Stephen, > >Could you please verify that this issue has not been fixed on Mongrel trunk? > >Thank you! Hi Wayne, Testing with JRuby trunk and r922 (trunk) of Mongrel. After installing the echoe gem rake install compiled the ragel code, tarred up an archive and died here: mongrel-1.1.1/test/test_ws.rb mongrel-1.1.1/test/testhelp.rb mongrel-1.1.1/TODO mongrel-1.1.1/tools/ mongrel-1.1.1/tools/trickletest.rb cd - WARNING: no email specified WARNING: no homepage specified WARNING: bin/mongrel_rails is missing #! line rake aborted! can't convert YAML::JvYAML::Map into String And indeed bin/mongrel_rails Has no #! line. It should have: #!/usr/bin/env jruby From luislavena at gmail.com Sat Dec 22 17:53:53 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 22 Dec 2007 19:53:53 -0300 Subject: [Mongrel] error when installing on jruby (fastthread dependency) In-Reply-To: References: Message-ID: <71166b3b0712221453y27c62f7era55d4b4e0f1ee9f7@mail.gmail.com> On Dec 22, 2007 7:48 PM, Stephen Bannasch wrote: > At 10:55 AM -0500 12/22/07, Wayne E. Seguin wrote: > >Stephen, > > > >Could you please verify that this issue has not been fixed on Mongrel trunk? > > > >Thank you! > > Hi Wayne, > > Testing with JRuby trunk and r922 (trunk) of Mongrel. > > After installing the echoe gem rake install compiled the ragel code, tarred up an archive and died here: > > mongrel-1.1.1/test/test_ws.rb > mongrel-1.1.1/test/testhelp.rb > mongrel-1.1.1/TODO > mongrel-1.1.1/tools/ > mongrel-1.1.1/tools/trickletest.rb > cd - > WARNING: no email specified > WARNING: no homepage specified > WARNING: bin/mongrel_rails is missing #! line > rake aborted! > can't convert YAML::JvYAML::Map into String > > And indeed > > bin/mongrel_rails > > Has no #! line. It should have: > > #!/usr/bin/env jruby > The she_bang warning is just that, a warning, I have tested the same here with latest rubygems and even these warnings, the gem get built. could you try running the gem build based on the generated gemspec file? (it should be inside pkg/mongrel-1.1.1) Maybe is failing in the Gem::Specification#to_yaml (I don't have jruby to test it). Regards, -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From evan at cloudbur.st Sat Dec 22 21:45:55 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 22 Dec 2007 21:45:55 -0500 Subject: [Mongrel] error when installing on jruby (fastthread dependency) In-Reply-To: <71166b3b0712221453y27c62f7era55d4b4e0f1ee9f7@mail.gmail.com> References: <71166b3b0712221453y27c62f7era55d4b4e0f1ee9f7@mail.gmail.com> Message-ID: You have to cross package. Regular JRuby still has problems with signed gems and other gem-related things. rake java package Also, please follow the bug here: http://rubyforge.org/tracker/index.php?func=detail&aid=16517&group_id=1306&atid=5145 Evan On Dec 22, 2007 5:53 PM, Luis Lavena wrote: > On Dec 22, 2007 7:48 PM, Stephen Bannasch > wrote: > > At 10:55 AM -0500 12/22/07, Wayne E. Seguin wrote: > > >Stephen, > > > > > >Could you please verify that this issue has not been fixed on Mongrel trunk? > > > > > >Thank you! > > > > Hi Wayne, > > > > Testing with JRuby trunk and r922 (trunk) of Mongrel. > > > > After installing the echoe gem rake install compiled the ragel code, tarred up an archive and died here: > > > > mongrel-1.1.1/test/test_ws.rb > > mongrel-1.1.1/test/testhelp.rb > > mongrel-1.1.1/TODO > > mongrel-1.1.1/tools/ > > mongrel-1.1.1/tools/trickletest.rb > > cd - > > WARNING: no email specified > > WARNING: no homepage specified > > WARNING: bin/mongrel_rails is missing #! line > > rake aborted! > > can't convert YAML::JvYAML::Map into String > > > > And indeed > > > > bin/mongrel_rails > > > > Has no #! line. It should have: > > > > #!/usr/bin/env jruby > > > > The she_bang warning is just that, a warning, I have tested the same > here with latest rubygems and even these warnings, the gem get built. > > could you try running the gem build based on the generated gemspec file? > (it should be inside pkg/mongrel-1.1.1) > > Maybe is failing in the Gem::Specification#to_yaml > (I don't have jruby to test it). > > Regards, > > -- > Luis Lavena > Multimedia systems > - > A common mistake that people make when trying to design > something completely foolproof is to underestimate > the ingenuity of complete fools. > Douglas Adams > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From stephen.bannasch at deanbrook.org Sat Dec 22 22:29:15 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sat, 22 Dec 2007 22:29:15 -0500 Subject: [Mongrel] error when installing on jruby (fastthread dependency) In-Reply-To: References: <71166b3b0712221453y27c62f7era55d4b4e0f1ee9f7@mail.gmail.com> Message-ID: At 9:45 PM -0500 12/22/07, Evan Weaver wrote: >You have to cross package. Regular JRuby still has problems with >signed gems and other gem-related things. > > rake java package I tried that with the latest svn co from jruby (5341) and mongrel (925) and still get the error: can't convert YAML::JvYAML::Map into String /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:738:in `add_file' Should I file a new bug report? The original name: "error when installing on jruby (fastthread dependency)" doesn't describe the problem I am reporting now. >Also, please follow the bug here: > >http://rubyforge.org/tracker/index.php?func=detail&aid=16517&group_id=1306&atid=5145 See more details in the bug report. >On Dec 22, 2007 5:53 PM, Luis Lavena wrote: > > > could you try running the gem build based on the generated gemspec file? >> (it should be inside pkg/mongrel-1.1.1) >> >> Maybe is failing in the Gem::Specification#to_yaml > > (I don't have jruby to test it). It's failing in the gempackage task: Here's a truncated copy of the stack trace: rubygems/package.rb:738:in `add_file' rubygems/package.rb:738:in `open_from_io' rubygems/package.rb:738:in `open' rubygems/package.rb:790:in `open' rubygems/builder.rb:68:in `write_package' rubygems/builder.rb:68:in `build' rake/gempackagetask.rb:86:in `define' rake/gempackagetask.rb:85:in `when_writing' rake/gempackagetask.rb:85:in `define' From stephen.bannasch at deanbrook.org Sat Dec 22 23:01:29 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sat, 22 Dec 2007 23:01:29 -0500 Subject: [Mongrel] error when installing on jruby (fastthread dependency) In-Reply-To: <71166b3b0712221453y27c62f7era55d4b4e0f1ee9f7@mail.gmail.com> References: <71166b3b0712221453y27c62f7era55d4b4e0f1ee9f7@mail.gmail.com> Message-ID: At 7:53 PM -0300 12/22/07, Luis Lavena wrote: >could you try running the gem build based on the generated gemspec file? >(it should be inside pkg/mongrel-1.1.1) I get the same yaml error: [~/dev/rails/external/mongrel/pkg/mongrel-1.1.2]$ gem build mongrel.gemspec WARNING: no email specified WARNING: no homepage specified WARNING: bin/mongrel_rails is missing #! line ERROR: While executing gem ... (TypeError) can't convert YAML::JvYAML::Map into String Here's the gemspec file: file: pkg/mongrel-1.1.2/mongrel.gemspec # Gem::Specification for Mongrel-1.1.2 # Originally generated by Echoe Gem::Specification.new do |s| s.name = %q{mongrel} s.version = "1.1.2" s.platform = %q{java} s.specification_version = 2 if s.respond_to? :specification_version= s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version= s.authors = ["Zed A. Shaw"] s.date = %q{2007-12-22} s.default_executable = %q{mongrel_rails} s.description = %q{A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps.} s.email = %q{} s.executables = ["mongrel_rails"] s.has_rdoc = true s.homepage = %q{} s.require_paths = ["lib", "ext"] s.required_ruby_version = Gem::Requirement.new(">= 1.8.4") s.rubyforge_project = %q{mongrel} s.rubygems_version = %q{1.0.0} s.summary = %q{A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps.} s.test_files = ["test/test_cgi_wrapper.rb", "test/test_command.rb", "test/test_conditional.rb", "test/test_configurator.rb", "test/test_debug.rb", "test/test_handlers.rb", "test/test_http11.rb", "test/test_redirect_handler.rb", "test/test_request_progress.rb", "test/test_response.rb", "test/test_stats.rb", "test/test_uriclassifier.rb", "test/test_ws.rb"] s.add_dependency(%q, [">= 0.2.3"]) end >Maybe is failing in the Gem::Specification#to_yaml >(I don't have jruby to test it). > >Regards, > >-- >Luis Lavena >Multimedia systems >- >A common mistake that people make when trying to design >something completely foolproof is to underestimate >the ingenuity of complete fools. >Douglas Adams >_______________________________________________ >Mongrel-users mailing list >Mongrel-users at rubyforge.org >http://rubyforge.org/mailman/listinfo/mongrel-users From evan at cloudbur.st Sat Dec 22 23:39:15 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 22 Dec 2007 23:39:15 -0500 Subject: [Mongrel] error when installing on jruby (fastthread dependency) In-Reply-To: References: <71166b3b0712221453y27c62f7era55d4b4e0f1ee9f7@mail.gmail.com> Message-ID: Can we move all discussion to the bug report? This is hard to keep track of. Thanks Evan On Dec 22, 2007 11:01 PM, Stephen Bannasch wrote: > At 7:53 PM -0300 12/22/07, Luis Lavena wrote: > >could you try running the gem build based on the generated gemspec file? > >(it should be inside pkg/mongrel-1.1.1) > > I get the same yaml error: > > [~/dev/rails/external/mongrel/pkg/mongrel-1.1.2]$ gem build mongrel.gemspec > WARNING: no email specified > WARNING: no homepage specified > WARNING: bin/mongrel_rails is missing #! line > ERROR: While executing gem ... (TypeError) > can't convert YAML::JvYAML::Map into String > > Here's the gemspec file: > > file: pkg/mongrel-1.1.2/mongrel.gemspec > > # Gem::Specification for Mongrel-1.1.2 > # Originally generated by Echoe > > Gem::Specification.new do |s| > s.name = %q{mongrel} > s.version = "1.1.2" > s.platform = %q{java} > > s.specification_version = 2 if s.respond_to? :specification_version= > > s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version= > s.authors = ["Zed A. Shaw"] > s.date = %q{2007-12-22} > s.default_executable = %q{mongrel_rails} > s.description = %q{A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps.} > s.email = %q{} > s.executables = ["mongrel_rails"] > s.has_rdoc = true > s.homepage = %q{} > s.require_paths = ["lib", "ext"] > s.required_ruby_version = Gem::Requirement.new(">= 1.8.4") > s.rubyforge_project = %q{mongrel} > s.rubygems_version = %q{1.0.0} > s.summary = %q{A small fast HTTP library and server that runs Rails, Camping, Nitro and Iowa apps.} > s.test_files = ["test/test_cgi_wrapper.rb", "test/test_command.rb", "test/test_conditional.rb", "test/test_configurator.rb", "test/test_debug.rb", "test/test_handlers.rb", "test/test_http11.rb", "test/test_redirect_handler.rb", "test/test_request_progress.rb", "test/test_response.rb", "test/test_stats.rb", "test/test_uriclassifier.rb", "test/test_ws.rb"] > > s.add_dependency(%q, [">= 0.2.3"]) > end > > > > > >Maybe is failing in the Gem::Specification#to_yaml > >(I don't have jruby to test it). > > > >Regards, > > > >-- > >Luis Lavena > >Multimedia systems > >- > >A common mistake that people make when trying to design > >something completely foolproof is to underestimate > >the ingenuity of complete fools. > >Douglas Adams > >_______________________________________________ > >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 > -- Evan Weaver Cloudburst, LLC From stephen.bannasch at deanbrook.org Sat Dec 22 23:57:06 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sat, 22 Dec 2007 23:57:06 -0500 Subject: [Mongrel] error when installing on jruby (fastthread dependency) In-Reply-To: References: <71166b3b0712221453y27c62f7era55d4b4e0f1ee9f7@mail.gmail.com> Message-ID: I was able to get the mongrel gem installed in JRuby by first compiling it with MRI but specifying java: $ svn co http://mongrel.rubyforge.org/svn/trunk mongrel $ cd mongrel $ rake package java then in JRuby $ cd mongrel/pkg $ gem install mongrel-1.1.2-java.gem Successfully installed mongrel-1.1.2 1 gem installed Installing ri documentation for mongrel-1.1.2... Installing RDoc documentation for mongrel-1.1.2... From evan at cloudbur.st Sun Dec 23 00:23:55 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sun, 23 Dec 2007 00:23:55 -0500 Subject: [Mongrel] error when installing on jruby (fastthread dependency) In-Reply-To: References: <71166b3b0712221453y27c62f7era55d4b4e0f1ee9f7@mail.gmail.com> Message-ID: The remaining issue is why JRuby didn't find that build in the gem index and installed 1.0.2 instead. Seems like a JRuby problem to me? Evan On Dec 22, 2007 11:57 PM, Stephen Bannasch wrote: > I was able to get the mongrel gem installed in JRuby by first > compiling it with MRI but specifying java: > > $ svn co http://mongrel.rubyforge.org/svn/trunk mongrel > $ cd mongrel > $ rake package java > > then in JRuby > > $ cd mongrel/pkg > $ gem install mongrel-1.1.2-java.gem > Successfully installed mongrel-1.1.2 > 1 gem installed > Installing ri documentation for mongrel-1.1.2... > Installing RDoc documentation for mongrel-1.1.2... > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From evan at cloudbur.st Sun Dec 23 00:31:04 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sun, 23 Dec 2007 00:31:04 -0500 Subject: [Mongrel] error when installing on jruby (fastthread dependency) In-Reply-To: References: <71166b3b0712221453y27c62f7era55d4b4e0f1ee9f7@mail.gmail.com> Message-ID: On second thought, it's probably a gems/RubyForge problem. JRuby gems used to be named -jruby.gem so we had continued this naming scheme. But gems 1.0 changed the way the architecture/platform distinction is handled, and now builds gems that end in -java.gem. RubyForge probably updated to the gems 1.0 indexer and stopped indexing -jruby gems. I dunno whether JRuby can install -jruby, or -java, or both. I uploaded a gem ending in -java so we will see. Evan On Dec 23, 2007 12:23 AM, Evan Weaver wrote: > The remaining issue is why JRuby didn't find that build in the gem > index and installed 1.0.2 instead. Seems like a JRuby problem to me? > > Evan > > On Dec 22, 2007 11:57 PM, Stephen Bannasch > wrote: > > > I was able to get the mongrel gem installed in JRuby by first > > compiling it with MRI but specifying java: > > > > $ svn co http://mongrel.rubyforge.org/svn/trunk mongrel > > $ cd mongrel > > $ rake package java > > > > then in JRuby > > > > $ cd mongrel/pkg > > $ gem install mongrel-1.1.2-java.gem > > Successfully installed mongrel-1.1.2 > > 1 gem installed > > Installing ri documentation for mongrel-1.1.2... > > Installing RDoc documentation for mongrel-1.1.2... > > > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > -- > Evan Weaver > Cloudburst, LLC > -- Evan Weaver Cloudburst, LLC From stephen.bannasch at deanbrook.org Sun Dec 23 01:25:14 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sun, 23 Dec 2007 01:25:14 -0500 Subject: [Mongrel] error when installing on jruby (fastthread dependency) In-Reply-To: References: <71166b3b0712221453y27c62f7era55d4b4e0f1ee9f7@mail.gmail.com> Message-ID: At 12:23 AM -0500 12/23/07, Evan Weaver wrote: >The remaining issue is why JRuby didn't find that build in the gem >index and installed 1.0.2 instead. Seems like a JRuby problem to me? > >Evan I don't think it was ever trying to install mongrel 1.0.2. This comment and more is in the bug tracker. From luislavena at gmail.com Sun Dec 23 09:59:39 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 23 Dec 2007 11:59:39 -0300 Subject: [Mongrel] error when installing on jruby (fastthread dependency) In-Reply-To: References: <71166b3b0712221453y27c62f7era55d4b4e0f1ee9f7@mail.gmail.com> Message-ID: <71166b3b0712230659l5fb589a3q5b26de7a976d6db6@mail.gmail.com> On Dec 23, 2007 1:01 AM, Stephen Bannasch wrote: > At 7:53 PM -0300 12/22/07, Luis Lavena wrote: > >could you try running the gem build based on the generated gemspec file? > >(it should be inside pkg/mongrel-1.1.1) > > I get the same yaml error: > Ok, even you got it solved (at this time), will be good if you can submit this gemspec build issues to RubyGems Tracker, so they can have something to work with ;-) > [~/dev/rails/external/mongrel/pkg/mongrel-1.1.2]$ gem build mongrel.gemspec > WARNING: no email specified > WARNING: no homepage specified > WARNING: bin/mongrel_rails is missing #! line > ERROR: While executing gem ... (TypeError) > can't convert YAML::JvYAML::Map into String > Regards, -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From lists at ruby-forum.com Tue Dec 25 05:55:24 2007 From: lists at ruby-forum.com (Abir B.) Date: Tue, 25 Dec 2007 11:55:24 +0100 Subject: [Mongrel] mongrel not finding correct ruby path In-Reply-To: <83e853830711082221u2481448dl5e32847b3b59515a@mail.gmail.com> References: <83e853830711050300o22dd05b6n75c8521e58633015@mail.gmail.com> <83e853830711082221u2481448dl5e32847b3b59515a@mail.gmail.com> Message-ID: <32f4abe622e300d97a45df68a959e69b@ruby-forum.com> Barun Singh wrote: > Forgot to reply back earlier, but I hadn't installed rubygems in the new > ruby installation. I forgot that I would need to do so. Thank you both > for > the quick responses! Hello, I've the same problem (after updating Ruby it doesn't see the installed gems) So can you detail how did you resolve this roblem thanks -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Fri Dec 28 17:01:53 2007 From: lists at ruby-forum.com (Eric Mason) Date: Fri, 28 Dec 2007 23:01:53 +0100 Subject: [Mongrel] Arbitrary system files readable in 1.0.4 - 1.1.2 Message-ID: I just found a vulnerability in one of my web apps that was running Mongrel 1.1.2 where I could go to URIs like /.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/etc/passwd and it would serve the actual /etc/passwd file. The issue seems to be in lib/mongrel/handlers.rb in the change from 1.0.3 to 1.0.4 req_path = HttpRequest.unescape(path_info) - if @path - req_path = File.expand_path(File.join(@path, path_info), @path) - else - req_path = File.expand_path(req_path) - end - - if req_path.index(@path) == 0 and File.exist? req_path - # it exists and it's in the right location + # Add the drive letter or root path + req_path = File.join(@path, req_path) if @path + req_path = File.expand_path req_path + + if File.exist? req_path + # It exists and it's in the right location if File.directory? req_path The main difference is that "req_path.index(@path) == 0" is removed, which seems to be the cause of the vulnerability. Adding that check back in fixes it in 1.1.2, but may cause issues on Windows (I haven't checked) Also, downgrading to 1.0.3 fixes it. -- Posted via http://www.ruby-forum.com/. From evan at cloudbur.st Fri Dec 28 19:28:25 2007 From: evan at cloudbur.st (Evan Weaver) Date: Fri, 28 Dec 2007 19:28:25 -0500 Subject: [Mongrel] Arbitrary system files readable in 1.0.4 - 1.1.2 In-Reply-To: References: Message-ID: I guess expand_path doesn't interact well with HTTP escaping. This is pretty critical, can you file a ticket against it? Evan On Dec 28, 2007 5:01 PM, Eric Mason wrote: > I just found a vulnerability in one of my web apps that was running > Mongrel 1.1.2 where I could go to URIs like > /.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/etc/passwd and it > would serve the actual /etc/passwd file. > > The issue seems to be in lib/mongrel/handlers.rb in the change from > 1.0.3 to 1.0.4 > > > req_path = HttpRequest.unescape(path_info) > - if @path > - req_path = File.expand_path(File.join(@path, path_info), @path) > - else > - req_path = File.expand_path(req_path) > - end > - > - if req_path.index(@path) == 0 and File.exist? req_path > - # it exists and it's in the right location > + # Add the drive letter or root path > + req_path = File.join(@path, req_path) if @path > + req_path = File.expand_path req_path > + > + if File.exist? req_path > + # It exists and it's in the right location > if File.directory? req_path > > The main difference is that "req_path.index(@path) == 0" is removed, > which seems to be the cause of the vulnerability. > > Adding that check back in fixes it in 1.1.2, but may cause issues on > Windows (I haven't checked) > > Also, downgrading to 1.0.3 fixes it. > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From evan at cloudbur.st Fri Dec 28 19:29:16 2007 From: evan at cloudbur.st (Evan Weaver) Date: Fri, 28 Dec 2007 19:29:16 -0500 Subject: [Mongrel] Arbitrary system files readable in 1.0.4 - 1.1.2 In-Reply-To: References: Message-ID: Also, attaching a diff with a failing test would totally rock. Evan On Dec 28, 2007 7:28 PM, Evan Weaver wrote: > I guess expand_path doesn't interact well with HTTP escaping. > > This is pretty critical, can you file a ticket against it? > > Evan > > > On Dec 28, 2007 5:01 PM, Eric Mason wrote: > > I just found a vulnerability in one of my web apps that was running > > Mongrel 1.1.2 where I could go to URIs like > > /.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/etc/passwd and it > > would serve the actual /etc/passwd file. > > > > The issue seems to be in lib/mongrel/handlers.rb in the change from > > 1.0.3 to 1.0.4 > > > > > > req_path = HttpRequest.unescape(path_info) > > - if @path > > - req_path = File.expand_path(File.join(@path, path_info), @path) > > - else > > - req_path = File.expand_path(req_path) > > - end > > - > > - if req_path.index(@path) == 0 and File.exist? req_path > > - # it exists and it's in the right location > > + # Add the drive letter or root path > > + req_path = File.join(@path, req_path) if @path > > + req_path = File.expand_path req_path > > + > > + if File.exist? req_path > > + # It exists and it's in the right location > > if File.directory? req_path > > > > The main difference is that "req_path.index(@path) == 0" is removed, > > which seems to be the cause of the vulnerability. > > > > Adding that check back in fixes it in 1.1.2, but may cause issues on > > Windows (I haven't checked) > > > > Also, downgrading to 1.0.3 fixes it. > > -- > > Posted via http://www.ruby-forum.com/. > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > -- > Evan Weaver > Cloudburst, LLC > -- Evan Weaver Cloudburst, LLC From zedshaw at zedshaw.com Fri Dec 28 21:22:23 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Fri, 28 Dec 2007 21:22:23 -0500 Subject: [Mongrel] [SECURITY] Must Fix This Now! (Re: Arbitrary system files readable in 1.0.4 - 1.1.2) In-Reply-To: References: Message-ID: <20071228212223.9fb2c104.zedshaw@zedshaw.com> On Fri, 28 Dec 2007 19:28:25 -0500 "Evan Weaver" wrote: > I guess expand_path doesn't interact well with HTTP escaping. > > This is pretty critical, can you file a ticket against it? No, you're miss-reading the change set. The 1.0.4 change *removed* the expand path on one of the conditions, so now it's using a relative path on one of the if branches, AND removed the check that ensured the expanded_path began with the expanded web root. Notice mine has expand_path on the if and the else so it's always done, and then makes sure that the expanded path begins with the web root. No matter what you do, you *must* expand path all paths before you do any comparisons or reads and never use an indirect path. It might be better to setup any paths you're doing, and then the very last thing is always expand path. Here's the change again: - req_path = HttpRequest.unescape(path_info) - if @path - req_path = File.expand_path(File.join(@path, path_info), @path) - else - req_path = File.expand_path(req_path) - end - - if req_path.index(@path) == 0 and File.exist? req_path - # it exists and it's in the right location + # Add the drive letter or root path + req_path = File.join(@path, req_path) if @path + req_path = File.expand_path req_path + + if File.exist? req_path + # It exists and it's in the right location if File.directory? req_path Notice the - lines have "if req_path.index(@path) == 0..." that's the part that ensures that the given path (after expansion) begins with the path being used by the web server as the root. If you don't have the required expand path before this, AND make sure that the beginning of the expanded path is always the root path, then you have this bug. I haven't looked at the real code yet, but don't wait for a patch, fix this and I'd say remove the gem so it doesn't go out more since it's a *huge* vulnerability. In fact, pushing out a 1.0.5 that reverts this change to fix it and doing it now is probably the best. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From luislavena at gmail.com Fri Dec 28 23:20:33 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 29 Dec 2007 01:20:33 -0300 Subject: [Mongrel] Arbitrary system files readable in 1.0.4 - 1.1.2 In-Reply-To: References: Message-ID: <71166b3b0712282020pb002ec1l1f2dfe1c66966b28@mail.gmail.com> On Dec 28, 2007 7:01 PM, Eric Mason wrote: > I just found a vulnerability in one of my web apps that was running > Mongrel 1.1.2 where I could go to URIs like > /.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/etc/passwd and it > would serve the actual /etc/passwd file. > > The issue seems to be in lib/mongrel/handlers.rb in the change from > 1.0.3 to 1.0.4 > can you download and install the 1.1.3 gem I put online from here: http://mmediasys.com/mongrel/mongrel-1.1.3.gem and let me know if it worked before we put it on rubyforge. also, knowing the Dir.pwd of your public doc root will be good, or a test case showing the problem, since I couldn't reproduce the behavior you described under Windows. (I know there isn't /etc/passwd on windows, tried other file) :-D Please let me know ASAP. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From tom at infoether.com Sat Dec 29 00:35:15 2007 From: tom at infoether.com (Tom Copeland) Date: Sat, 29 Dec 2007 00:35:15 -0500 Subject: [Mongrel] Regarding the 1.1.3 security release Message-ID: <1198906515.21649.10.camel@bugs.hal> * Apologies for starting a new thread; I just subscribed. Has anyone been able to make this exploit happen if requests are being proxied to Mongrel through Apache? I've been trying variations on the double-encoding thing and can't trigger the exploit through Apache. Hitting Mongrel directly does expose the problem. I'll still upgrade my servers, of course, but I don't want to send an unnecessary "upgrade now" note to other folks... Thanks, Tom From luislavena at gmail.com Sat Dec 29 01:12:33 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 29 Dec 2007 03:12:33 -0300 Subject: [Mongrel] Regarding the 1.1.3 security release In-Reply-To: <1198906515.21649.10.camel@bugs.hal> References: <1198906515.21649.10.camel@bugs.hal> Message-ID: <71166b3b0712282212s31aaf191g93f4bebe766ca889@mail.gmail.com> On Dec 29, 2007 2:35 AM, Tom Copeland wrote: > * Apologies for starting a new thread; I just subscribed. > > Has anyone been able to make this exploit happen if requests are being > proxied to Mongrel through Apache? I've been trying variations on the > double-encoding thing and can't trigger the exploit through Apache. > Hitting Mongrel directly does expose the problem. > Yeah Tom, using a proxy/balancer like apache and nginx will filter this, but some folks serve mongrel directly, or using not-so-clever balancers that didn't filter this kind of exploits. > I'll still upgrade my servers, of course, but I don't want to send an > unnecessary "upgrade now" note to other folks... Most common use of mongrel is "behind a proxy or balancer", so I only see development servers is being affected by this. Or, maybe I'm wrong (which happens quite often). -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From ezmobius at gmail.com Sat Dec 29 01:26:26 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Fri, 28 Dec 2007 22:26:26 -0800 Subject: [Mongrel] Regarding the 1.1.3 security release In-Reply-To: <1198906515.21649.10.camel@bugs.hal> References: <1198906515.21649.10.camel@bugs.hal> Message-ID: <34A76179-9A7F-4442-B98D-4F4B3AF04922@gmail.com> On Dec 28, 2007, at 9:35 PM, Tom Copeland wrote: > * Apologies for starting a new thread; I just subscribed. > > Has anyone been able to make this exploit happen if requests are being > proxied to Mongrel through Apache? I've been trying variations on the > double-encoding thing and can't trigger the exploit through Apache. > Hitting Mongrel directly does expose the problem. > > I'll still upgrade my servers, of course, but I don't want to send an > unnecessary "upgrade now" note to other folks... > > Thanks, > > Tom > As far as I can tell this is only exploitable on direct mongrel hits. I cannot make it happen on mongrels behind nginx or apache. Cheers- - Ezra Zygmuntowicz -- Founder & Software Architect -- ezra at engineyard.com -- EngineYard.com From evan at cloudbur.st Sat Dec 29 02:16:53 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 29 Dec 2007 02:16:53 -0500 Subject: [Mongrel] Regarding the 1.1.3 security release In-Reply-To: <71166b3b0712282212s31aaf191g93f4bebe766ca889@mail.gmail.com> References: <1198906515.21649.10.camel@bugs.hal> <71166b3b0712282212s31aaf191g93f4bebe766ca889@mail.gmail.com> Message-ID: I think 'pen' is vulnerable. I don't think mod_proxy_balancer is. You will need to check your own site. The new gems will be out in a few hours for all platforms. Evan On Dec 29, 2007 1:12 AM, Luis Lavena wrote: > On Dec 29, 2007 2:35 AM, Tom Copeland wrote: > > * Apologies for starting a new thread; I just subscribed. > > > > Has anyone been able to make this exploit happen if requests are being > > proxied to Mongrel through Apache? I've been trying variations on the > > double-encoding thing and can't trigger the exploit through Apache. > > Hitting Mongrel directly does expose the problem. > > > > Yeah Tom, using a proxy/balancer like apache and nginx will filter > this, but some folks serve mongrel directly, or using not-so-clever > balancers that didn't filter this kind of exploits. > > > I'll still upgrade my servers, of course, but I don't want to send an > > unnecessary "upgrade now" note to other folks... > > Most common use of mongrel is "behind a proxy or balancer", so I only > see development servers is being affected by this. > > Or, maybe I'm wrong (which happens quite often). > > -- > Luis Lavena > Multimedia systems > - > A common mistake that people make when trying to design > something completely foolproof is to underestimate > the ingenuity of complete fools. > Douglas Adams > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From zedshaw at zedshaw.com Sat Dec 29 03:32:37 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Sat, 29 Dec 2007 03:32:37 -0500 Subject: [Mongrel] Regarding the 1.1.3 security release In-Reply-To: <1198906515.21649.10.camel@bugs.hal> References: <1198906515.21649.10.camel@bugs.hal> Message-ID: <20071229033237.cf6a17bd.zedshaw@zedshaw.com> On Sat, 29 Dec 2007 00:35:15 -0500 Tom Copeland wrote: > * Apologies for starting a new thread; I just subscribed. > > Has anyone been able to make this exploit happen if requests are being > proxied to Mongrel through Apache? I've been trying variations on the > double-encoding thing and can't trigger the exploit through Apache. > Hitting Mongrel directly does expose the problem. > > I'll still upgrade my servers, of course, but I don't want to send an > unnecessary "upgrade now" note to other folks... I think others said it, but I'll lay out the conditions for what is the most likely upgrade requirement: 1) If you use nginx or apache (and maybe other full web servers with a proxy module) then you can wait to upgrade, but probably not very long. This is because these servers do their own checking as well, and are handling your files. That means a request for the file will be dropped, and blocked. 2) If you use a pure TCP/IP based proxy balancer (balance, pen, swiftiply?) then you must upgrade as these do no checks on the incoming TCP packets. 3) If you use mongrel directly to serve content then you must upgrade. If you cannot upgrade, see the list earlier for the one line fix. You don't need the comments :-) Hope that helps. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From evan at cloudbur.st Sat Dec 29 03:31:21 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 29 Dec 2007 03:31:21 -0500 Subject: [Mongrel] [SECURITY] Must Fix This Now! (Re: Arbitrary system files readable in 1.0.4 - 1.1.2) In-Reply-To: <20071228212223.9fb2c104.zedshaw@zedshaw.com> References: <20071228212223.9fb2c104.zedshaw@zedshaw.com> Message-ID: New gems are out. You can downgrade to 1.0.3 or you can upgrade to 1.0.5 or 1.1.3. Versions prior to 1.0.4 are not affected. Thanks, Evan On Dec 28, 2007 9:22 PM, Zed A. Shaw wrote: > On Fri, 28 Dec 2007 19:28:25 -0500 > "Evan Weaver" wrote: > > > I guess expand_path doesn't interact well with HTTP escaping. > > > > This is pretty critical, can you file a ticket against it? > > No, you're miss-reading the change set. The 1.0.4 change *removed* the > expand path on one of the conditions, so now it's using a relative > path on one of the if branches, AND removed the check that ensured the > expanded_path began with the expanded web root. Notice mine has > expand_path on the if and the else so it's always done, and then makes > sure that the expanded path begins with the web root. > > No matter what you do, you *must* expand path all paths before you do > any comparisons or reads and never use an indirect path. It might be > better to setup any paths you're doing, and then the very last thing is > always expand path. > > Here's the change again: > > - req_path = HttpRequest.unescape(path_info) > - if @path > - req_path = File.expand_path(File.join(@path, path_info), @path) > - else > - req_path = File.expand_path(req_path) > - end > - > - if req_path.index(@path) == 0 and File.exist? req_path > - # it exists and it's in the right location > + # Add the drive letter or root path > + req_path = File.join(@path, req_path) if @path > + req_path = File.expand_path req_path > + > + if File.exist? req_path > + # It exists and it's in the right location > if File.directory? req_path > > Notice the - lines have "if req_path.index(@path) == 0..." that's the > part that ensures that the given path (after expansion) begins with the > path being used by the web server as the root. If you don't have the > required expand path before this, AND make sure that the beginning of > the expanded path is always the root path, then you have this bug. > > I haven't looked at the real code yet, but don't wait for a patch, fix > this and I'd say remove the gem so it doesn't go out more since it's a > *huge* vulnerability. > > In fact, pushing out a 1.0.5 that reverts this change to fix it and > doing it now is probably the best. > > -- > Zed A. Shaw > - Hate: http://savingtheinternetwithhate.com/ > - Good: http://www.zedshaw.com/ > - Evil: http://yearofevil.com/ > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From evan at cloudbur.st Sat Dec 29 03:58:01 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 29 Dec 2007 03:58:01 -0500 Subject: [Mongrel] [SECURITY] Must Fix This Now! (Re: Arbitrary system files readable in 1.0.4 - 1.1.2) In-Reply-To: References: <20071228212223.9fb2c104.zedshaw@zedshaw.com> Message-ID: Also, I want to reiterate that people should subscribe to the RSS feed, where handy release announcements come directly to you. http://mongrel.rubyforge.org/rss.xml Evan On Dec 29, 2007 3:31 AM, Evan Weaver wrote: > New gems are out. You can downgrade to 1.0.3 or you can upgrade to > 1.0.5 or 1.1.3. Versions prior to 1.0.4 are not affected. > > Thanks, > > Evan > > > On Dec 28, 2007 9:22 PM, Zed A. Shaw wrote: > > On Fri, 28 Dec 2007 19:28:25 -0500 > > "Evan Weaver" wrote: > > > > > I guess expand_path doesn't interact well with HTTP escaping. > > > > > > This is pretty critical, can you file a ticket against it? > > > > No, you're miss-reading the change set. The 1.0.4 change *removed* the > > expand path on one of the conditions, so now it's using a relative > > path on one of the if branches, AND removed the check that ensured the > > expanded_path began with the expanded web root. Notice mine has > > expand_path on the if and the else so it's always done, and then makes > > sure that the expanded path begins with the web root. > > > > No matter what you do, you *must* expand path all paths before you do > > any comparisons or reads and never use an indirect path. It might be > > better to setup any paths you're doing, and then the very last thing is > > always expand path. > > > > Here's the change again: > > > > - req_path = HttpRequest.unescape(path_info) > > - if @path > > - req_path = File.expand_path(File.join(@path, path_info), @path) > > - else > > - req_path = File.expand_path(req_path) > > - end > > - > > - if req_path.index(@path) == 0 and File.exist? req_path > > - # it exists and it's in the right location > > + # Add the drive letter or root path > > + req_path = File.join(@path, req_path) if @path > > + req_path = File.expand_path req_path > > + > > + if File.exist? req_path > > + # It exists and it's in the right location > > if File.directory? req_path > > > > Notice the - lines have "if req_path.index(@path) == 0..." that's the > > part that ensures that the given path (after expansion) begins with the > > path being used by the web server as the root. If you don't have the > > required expand path before this, AND make sure that the beginning of > > the expanded path is always the root path, then you have this bug. > > > > I haven't looked at the real code yet, but don't wait for a patch, fix > > this and I'd say remove the gem so it doesn't go out more since it's a > > *huge* vulnerability. > > > > In fact, pushing out a 1.0.5 that reverts this change to fix it and > > doing it now is probably the best. > > > > -- > > Zed A. Shaw > > - Hate: http://savingtheinternetwithhate.com/ > > - Good: http://www.zedshaw.com/ > > - Evil: http://yearofevil.com/ > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > -- > Evan Weaver > Cloudburst, LLC > -- Evan Weaver Cloudburst, LLC From paolo.campegiani at gmail.com Sat Dec 29 06:05:48 2007 From: paolo.campegiani at gmail.com (Paolo Campegiani) Date: Sat, 29 Dec 2007 12:05:48 +0100 Subject: [Mongrel] Regarding the 1.1.3 security release In-Reply-To: <20071229033237.cf6a17bd.zedshaw@zedshaw.com> References: <1198906515.21649.10.camel@bugs.hal> <20071229033237.cf6a17bd.zedshaw@zedshaw.com> Message-ID: 2007/12/29, Zed A. Shaw : > 1) If you use nginx or apache (and maybe other full web servers with a > proxy module) then you can wait to upgrade, but probably not very > long. This is because these servers do their own checking as well, and > are handling your files. That means a request for the file will be > dropped, and blocked. I have an Apache 2.0 protected by modsecurity (with standard configuration), and the result of GETting http://host.domain.it//.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/etc/passwd is HTTP 501: Method Not Implemented GET to //.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/etc/passwd not supported. Apache/2.0.x (RHEL) Server at host.domain.it Port 80 that means that modsecurity stops the request before it hits Apache. Don't know if Apache would stop it by itself, just to suggest that this extra layer of security could be added for free and it does not interfere with Rails application we've here. From zewerson at gmail.com Sat Dec 29 06:44:24 2007 From: zewerson at gmail.com (frank zewerson) Date: Sat, 29 Dec 2007 12:44:24 +0100 Subject: [Mongrel] difference between mongrel 1.0 and 1.1 Message-ID: <920b4d4a0712290344h636ec465nae60b5b842d16af3@mail.gmail.com> i was searching the mongrel site and also this list, but didnt find any answer. maybe somebody can describe to me, what the differences are from mongrel 1.0 to 1.1 and which i should use in a production environment. regards, mz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071229/f3948be3/attachment.html From wayneeseguin at gmail.com Sat Dec 29 08:30:56 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Sat, 29 Dec 2007 08:30:56 -0500 Subject: [Mongrel] difference between mongrel 1.0 and 1.1 In-Reply-To: <920b4d4a0712290344h636ec465nae60b5b842d16af3@mail.gmail.com> References: <920b4d4a0712290344h636ec465nae60b5b842d16af3@mail.gmail.com> Message-ID: On Dec 29, 2007 6:44 AM, frank zewerson wrote: > i was searching the mongrel site and also this list, but didnt find any > answer. maybe somebody can describe to me, what the differences are from > mongrel 1.0 to 1.1 and which i should use in a production environment. > regards, > mz > To view the difference read the CHANGELOG. It is advised to use 1.0.5 in production. ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071229/df1b7961/attachment.html From tom at infoether.com Sat Dec 29 09:23:20 2007 From: tom at infoether.com (Tom Copeland) Date: Sat, 29 Dec 2007 09:23:20 -0500 Subject: [Mongrel] Regarding the 1.1.3 security release In-Reply-To: <20071229033237.cf6a17bd.zedshaw@zedshaw.com> References: <1198906515.21649.10.camel@bugs.hal> <20071229033237.cf6a17bd.zedshaw@zedshaw.com> Message-ID: <1198938200.21649.41.camel@bugs.hal> On Sat, 2007-12-29 at 03:32 -0500, Zed A. Shaw wrote: > I think others said it, but I'll lay out the conditions for what is the > most likely upgrade requirement: > > 1) If you use nginx or apache (and maybe other full web servers with a > proxy module) then you can wait to upgrade, but probably not very > long. This is because these servers do their own checking as well, and > are handling your files. That means a request for the file will be > dropped, and blocked. > 2) If you use a pure TCP/IP based proxy balancer (balance, pen, > swiftiply?) then you must upgrade as these do no checks on the incoming > TCP packets. > 3) If you use mongrel directly to serve content then you must upgrade. > > If you cannot upgrade, see the list earlier for the one line fix. You > don't need the comments :-) Cool, thanks much for the summary and also for the quick fix! Yours, tom From evan at cloudbur.st Sat Dec 29 10:09:43 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 29 Dec 2007 10:09:43 -0500 Subject: [Mongrel] difference between mongrel 1.0 and 1.1 In-Reply-To: References: <920b4d4a0712290344h636ec465nae60b5b842d16af3@mail.gmail.com> Message-ID: > It is advised to use 1.0.5 in production. I think a better way to say that is, it's advised to use whatever you are already using that works, and don't upgrade unless you need something specific in the new versions. 1.1.3 is stable but there's no reason to change a working system. Evan On Dec 29, 2007 8:30 AM, Wayne E. Seguin wrote: > > On Dec 29, 2007 6:44 AM, frank zewerson wrote: > > > > i was searching the mongrel site and also this list, but didnt find any > answer. maybe somebody can describe to me, what the differences are from > mongrel 1.0 to 1.1 and which i should use in a production environment. > > > > > > regards, > > mz > > To view the difference read the CHANGELOG. > It is advised to use 1.0.5 in production. > > ~Wayne > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From wayneeseguin at gmail.com Sat Dec 29 11:03:48 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Sat, 29 Dec 2007 11:03:48 -0500 Subject: [Mongrel] difference between mongrel 1.0 and 1.1 In-Reply-To: References: <920b4d4a0712290344h636ec465nae60b5b842d16af3@mail.gmail.com> Message-ID: That's what I mean to say :) We're using 1.1.3 in prod now. ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071229/2da6ed22/attachment-0001.html From brian.gupta at gmail.com Sun Dec 30 01:21:38 2007 From: brian.gupta at gmail.com (Brian Gupta) Date: Sun, 30 Dec 2007 01:21:38 -0500 Subject: [Mongrel] Moving towards a unified version number for mongrel and mongrel_cluster? Message-ID: <5b5090780712292221t6cca7f3fk2201645c4a4d9f65@mail.gmail.com> Are there any plans to do so? It seems that it would make things simpler if the mongrel version number matched the mongrel_cluster version number. (I realize this is completely arbitrary). Thoughts? -Brian -- - Brian Gupta http://opensolaris.org/os/project/nycosug/ From wayneeseguin at gmail.com Sun Dec 30 12:47:50 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Sun, 30 Dec 2007 12:47:50 -0500 Subject: [Mongrel] Moving towards a unified version number for mongrel and mongrel_cluster? In-Reply-To: <5b5090780712292221t6cca7f3fk2201645c4a4d9f65@mail.gmail.com> References: <5b5090780712292221t6cca7f3fk2201645c4a4d9f65@mail.gmail.com> Message-ID: On Dec 30, 2007 1:21 AM, Brian Gupta wrote: > Are there any plans to do so? It seems that it would make things > simpler if the mongrel version number matched the mongrel_cluster > version number. (I realize this is completely arbitrary). > > Thoughts? > True, that is completely arbitrary :-p Our last discussion was that would create a couple of utilities, including merging a modified version of cluster into the mongrel gem. We currently have no timeline for such things. ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071230/522c81e7/attachment.html From brian.gupta at gmail.com Mon Dec 31 18:43:13 2007 From: brian.gupta at gmail.com (Brian Gupta) Date: Mon, 31 Dec 2007 18:43:13 -0500 Subject: [Mongrel] "mongrel_rails --version" reporting 1.1.2 instead of 1.1.3 Message-ID: <5b5090780712311543qf190722v6daad385b313eeea@mail.gmail.com> FYI. -- - Brian Gupta http://opensolaris.org/os/project/nycosug/ From luislavena at gmail.com Mon Dec 31 22:35:01 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 1 Jan 2008 00:35:01 -0300 Subject: [Mongrel] "mongrel_rails --version" reporting 1.1.2 instead of 1.1.3 In-Reply-To: <5b5090780712311543qf190722v6daad385b313eeea@mail.gmail.com> References: <5b5090780712311543qf190722v6daad385b313eeea@mail.gmail.com> Message-ID: <71166b3b0712311935p6f220d63we8de1a148acfaf8b@mail.gmail.com> On Dec 31, 2007 8:43 PM, Brian Gupta wrote: > FYI. > >From your signature I guess is OpenSolaris. - Did you install it from rubygems or downloaded the tgz package? The http11 set the platform correctly, so I honestly don't know why are you getting it (the tgz, the mongrel-1.1.1.gem and the mongrel-1.1.3-i386-mswin32.gem display it correctly). Could I just answer to this: "Works for me"? :-D Happy New Year! -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams