I was playing around with my rails app (puma server, deployed on heroku) in production, and got the authenticity error when submitted a long form (when I render the form auth token seems to be okay, the value is visible).
Usually the form works well. It was only the second time this has happened. In both cases a long time (~1hour) passed between rendering and submitting the form.
I couldn't find any answer to this problem. Is there a time limit for submitting the form based on when the form was rendered? Or is this a browser issue? It would be important to have this form open for a while since it's pretty long and users may want to think before they fill out the and submit the form.
Mar 01 07:36:32 appfaskyn app/web.1: Started POST "/products" for 141.101.96.195 at 2016-03-01 15:36:31 +0000
Mar 01 07:36:32 appfaskyn app/web.1: Processing by ProductsController#create as HTML
Mar 01 07:36:32 appfaskyn app/web.1: Can't verify CSRF token authenticity
Mar 01 07:36:32 appfaskyn app/web.1: ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
Mar 01 07:36:32 appfaskyn app/web.1: vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.4/lib/action_controller/metal/request_forgery_protection.rb:181:in `handle_unverified_request'
Mar 01 07:36:32 appfaskyn app/web.1: vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.4/lib/action_controller/metal/request_forgery_protection.rb:209:in `handle_unverified_request'
Mar 01 07:36:32 appfaskyn app/web.1: vendor/bundle/ruby/2.2.0/gems/devise-3.5.6/lib/devise/controllers/helpers.rb:257:in `handle_unverified_request'
Mar 01 07:36:32 appfaskyn app/web.1: vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.4/lib/action_controller/metal/request_forgery_protection.rb:204:in `verify_authenticity_token'
Related
I hosted my Rails application last week. Today I was going through our log file and noticed lots of request like this.
I, [2016-03-14T00:42:18.501703 #21223] INFO -- : Started GET "/testproxy.php" for 185.49.14.190 at 2016-03-14 00:42:18 -0400
F, [2016-03-14T00:42:18.510616 #21223] FATAL -- :
ActionController::RoutingError (No route matches [GET] "/testproxy.php"):
Someone is trying to go to testproxy.php from different ip address. Some ip are from poland and others from hongkong. Am I getting attacked by someone. What are my options to protect myself.
Here are other outputs from log file:
I, [2016-03-14T03:09:24.945467 #15399] INFO -- : Started GET "/clientaccesspolicy.xml" for 107.22.223.242 at 2016-03-14 03:09:24 -0400
F, [2016-03-14T03:09:24.949328 #15399] FATAL -- :
ActionController::RoutingError (No route matches [GET] "/clientaccesspolicy.xml"):
Different ip address:
I, [2016-03-14T16:03:47.793731 #15399] INFO -- : Started GET "/testproxy.php" for 178.216.200.48 at 2016-03-14 16:03:47 -0400
F, [2016-03-14T16:03:47.818519 #15399] FATAL -- :
ActionController::RoutingError (No route matches [GET] "/testproxy.php"):
search.php
I, [2016-03-14T19:41:14.261843 #15399] INFO -- : Started GET "/forum/search.php" for 164.132.161.67 at 2016-03-14 19:41:14 -0400
F, [2016-03-14T19:41:14.266563 #15399] FATAL -- :
ActionController::RoutingError (No route matches [GET] "/forum/search.php"):
forum/index.php
I, [2016-03-15T10:54:55.254785 #26469] INFO -- : Started GET "/forum/index.php" for 164.132.161.56 at 2016-03-15 10:54:55 -0400
F, [2016-03-15T10:54:55.266456 #26469] FATAL -- :
ActionController::RoutingError (No route matches [GET] "/forum/index.php"):
phpmyadim/scripts/setup.php
I, [2016-03-15T13:21:36.862918 #26469] INFO -- : Started GET "/phpMyAdmin/scripts/setup.php" for 103.25.73.234 at 2016-03-15 13:21:36 -0400
F, [2016-03-15T13:21:36.867050 #26469] FATAL -- :
ActionController::RoutingError (No route matches [GET] "/phpMyAdmin/scripts/setup.php"):
another setup.php
I, [2016-03-15T13:21:37.452097 #26469] INFO -- : Started GET "/pma/scripts/setup.php" for 103.25.73.234 at 2016-03-15 13:21:37 -0400
F, [2016-03-15T13:21:37.453647 #26469] FATAL -- :
ActionController::RoutingError (No route matches [GET] "/pma/scripts/setup.php"):
myadmin/scripts/setup.php
I, [2016-03-15T13:21:38.034283 #26469] INFO -- : Started GET "/myadmin/scripts/setup.php" for 103.25.73.234 at 2016-03-15 13:21:38 -0400
F, [2016-03-15T13:21:38.041563 #26469] FATAL -- :
ActionController::RoutingError (No route matches [GET] "/myadmin/scripts/setup.php"):
and lots of other stuff. Please tell me how can I protect myself from those attacks.
This is commonplace when you are running a public server. Here is an excerpt of my home server's auth.log:
Mar 14 19:22:36 hotdog sshd[65937]: Received disconnect from 181.214.92.11: 11: Bye Bye [preauth]
Mar 14 19:22:37 hotdog sshd[65939]: Invalid user ubnt from 181.214.92.11
Mar 14 19:22:37 hotdog sshd[65939]: input_userauth_request: invalid user ubnt [preauth]
Mar 14 19:22:37 hotdog sshd[65939]: Received disconnect from 181.214.92.11: 11: Bye Bye [preauth]
Mar 14 19:22:38 hotdog sshd[65941]: Invalid user support from 181.214.92.11
Mar 14 19:22:38 hotdog sshd[65941]: input_userauth_request: invalid user support [preauth]
Mar 14 19:22:38 hotdog sshd[65941]: Received disconnect from 181.214.92.11: 11: Bye Bye [preauth]
Mar 14 19:22:39 hotdog sshd[65943]: Invalid user oracle from 181.214.92.11
Mar 14 19:22:39 hotdog sshd[65943]: input_userauth_request: invalid user oracle [preauth]
Mar 14 19:22:39 hotdog sshd[65943]: Received disconnect from 181.214.92.11: 11: Bye Bye [preauth]
Mar 14 19:22:40 hotdog sshd[65945]: Received disconnect from 181.214.92.11: 11: Bye Bye [preauth]
Mar 14 19:24:04 hotdog sshd[65947]: fatal: Read from socket failed: Operation timed out [preauth]
Mar 14 20:01:19 hotdog sshd[66032]: Received disconnect from 183.3.202.102: 11: [preauth]
Mar 14 20:40:17 hotdog sshd[66092]: Invalid user cacti from 199.217.117.71
Mar 14 20:40:17 hotdog sshd[66092]: input_userauth_request: invalid user cacti [preauth]
Mar 14 20:40:17 hotdog sshd[66092]: Connection closed by 199.217.117.71 [preauth]
Mar 14 21:32:09 hotdog sshd[66188]: Received disconnect from 183.3.202.102: 11: [preauth]
Mar 14 22:01:59 hotdog sshd[66256]: Invalid user user1 from 199.217.117.71
Mar 14 22:01:59 hotdog sshd[66256]: input_userauth_request: invalid user user1 [preauth]
Mar 14 22:02:00 hotdog sshd[66256]: Connection closed by 199.217.117.71 [preauth]
Mar 14 22:17:57 hotdog sshd[66280]: Did not receive identification string from 14.182.117.161
As you can see people are constantly trying to break into my server, by guessing a username. Since the server only accepts publickey login, not password, I believe myself to be fairly secure from these particular attacks.
The same applies to your PHP files. They are trying to find a php endpoint which they can run some canned exploit on. You can use tools like fail2ban which help with rate-limiting. But really these attacks will always be present on a public server. The only way is to ensure your software can resist attacks.
Some general common-sense tips:
Don't run more services than you need, as any one service could open your server to attack. Check which ports you have open with nmap.
Check that your apache/nginx config doesn't allow execute of more (PHP) files than necessary.
Update your software continuously. Most of these attacks are automated and thus rely on published exploits in common packages.
I have the IP address 183.3.202.102 and some others from the same subnet quite frequently appear in the log of one of my honeypots.
It suddenly stopped though. I guess someone finally submitted an abuse report and had them banned.
For some reason, a script of some sort makes a repeated request to my site every second or faster to a URL that doesn't exist. It's painful because it clogs up the logs (and is an unnecessary (although small) consumption of resources). Just wondering if there's a good way to deal with this for a site hosted on Heroku. The requests come from a different IP address each time.
Edit: As a note, the requests are always to the exact same URL.
Here's an example, which repeats every second or so, except from a different IP:
Feb 22 08:37:28 myApp app/web.1: ActionController::RoutingError (Not Found):
Feb 22 08:37:28 myApp app/web.1: app/controllers/application_controller.rb:31:in `not_found'
Feb 22 08:37:28 myApp app/web.1: app/controllers/my_controller.rb:141:in `my_method'
Feb 22 08:37:28 myApp app/web.1: [Exceptiontrap] Raised Exceptiontrap::Rack::Exception
Feb 22 08:37:28 myApp app/web.1: [Exceptiontrap] Catched Exception: ActionController::RoutingError
Feb 22 08:37:28 myApp app/web.1: Started GET "/aSpecificURL" for 109.242.56.44 at 2014-02-22 13:37:28 +0000
Feb 22 08:37:28 myApp heroku/router: at=info method=GET path=/aSpecificURL host=www.myApp.com request_id=9caeabcf-adcc-417f-940d-0458a81d9c32 fwd="109.242.56.44" dyno=web.1 connect=2ms service=24ms status=404 bytes=1632
You can't block specific requests through heroku. It sounds to me like someone is scanning your app for security vulnerabilities.
You could setup cloudflare to help block some of the requests. But overall, this is pretty common and not something to worry about.
I believe the default behavior of rails logging on production is to not output the rendering of all partials. This should log in development but not on production.
However, I'm seeing this in production and I'm not sure how to remove it. My logs are too noisy. My production environment is Heroku running Unicorn and using Papertrail to view my logs. I know Unicorn does some wonky stuff with logs and to get them working properly in the first place I had to add this to my production.rb:
config.logger = Logger.new(STDOUT)
config.logger.level = Logger.const_get('INFO')
( Explained here: http://help.papertrailapp.com/kb/configuration/unicorn )
But even with log_level INFO I'm seeing huge blocks of these in all my logs:
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_caption.html.erb (0.7ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_rights.html.erb (2.1ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_category.html.erb (4.8ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_caption.html.erb (0.3ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_rights.html.erb (0.4ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_category.html.erb (4.4ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_caption.html.erb (0.3ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_rights.html.erb (0.3ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_category.html.erb (1.8ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_caption.html.erb (0.4ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_rights.html.erb (4.6ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_category.html.erb (2.1ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_caption.html.erb (0.3ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_rights.html.erb (0.4ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_category.html.erb (4.1ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_caption.html.erb (0.2ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_rights.html.erb (1.8ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_category.html.erb (6.0ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_caption.html.erb (0.5ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_rights.html.erb (0.8ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_category.html.erb (1.9ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_caption.html.erb (0.3ms)
Jun 25 22:15:15 tacktile app/web.1: Rendered photos/pieces/_rights.html.erb (0.7ms)
For Rails 4 (at least):
Try this in your config/environments/development.rb
config.action_view.logger = nil
Use Lograge, it removes rendering times for partials
I got the following answer from a papertrail:
I think the quickest way to deal with this is to use our log filtering
functionality. That'll let you drop anything that matches a regex and
will save you from having to make any app configuration changes.
In the longer term, you'll probably want to silence these messages at
source. Lograge is probably your best bet for that. You may find it
also removes a few other bits but give it a go and let me know what
you think.
I know this is probably irrelevant to you at the moment, but for
future use you might also find some other useful tips here. It covers
lograge, removing static asset requests and unnecessary actions,
Let me know if you need help with anything mentioned above.
Instead of completely disabling actionview logging (as described in another answer), I opted to change the logging level for rendering to DEBUG. This way, it can be easily omitted from production logs by setting the log level to INFO or higher.
Note, this is for rails 5.2. I'm unsure if it would work on other versions.
module ViewLoggingOverride
def info(progname = nil, &block)
logger.debug(progname, &block) if logger
end
end
ActionView::LogSubscriber.include(ViewLoggingOverride)
Relevant rails code:
https://github.com/rails/rails/blob/5-2-stable/actionview/lib/action_view/log_subscriber.rb
https://github.com/rails/rails/blob/5-2-stable/activesupport/lib/active_support/log_subscriber.rb#L93-L99
This is so common that, in Papertrail emails notifying you of a logging spike, there is a link with this exact example.
This is the link.
I tweaked the regex a bit:
/\A\s{3}Rendered \w+\/_.+\.erb \(\d+\.\d+ms\)\z/
PS: I always found it odd they are printed at info level in the first place.
I have completed my testing and all notifications are going through nicely using php apns. Now as soon as I switch to production I get this result
Tue, 16 Oct 2012 16:40:48 +0200 ApnsPHP[5709]: INFO: Trying ssl://gateway.push.apple.com:2195...
Tue, 16 Oct 2012 16:40:51 +0200 ApnsPHP[5709]: INFO: Connected to ssl://gateway.push.apple.com:2195.
Tue, 16 Oct 2012 16:40:51 +0200 ApnsPHP[5709]: INFO: Sending messages queue, run #1: 1 message(s) left in queue.
Tue, 16 Oct 2012 16:40:51 +0200 ApnsPHP[5709]: STATUS: Sending message ID 1 [custom identifier: Message-Badge-3] (1/3): 119 bytes.
Tue, 16 Oct 2012 16:40:51 +0200 ApnsPHP[5709]: INFO: Disconnected.
This looks fine to me however my device does not receive the notification.
Please Help
Ensure your DeviceToken is the production one. DeviceTokens for dev are different then production for the same device.
From Apple:
Take note that the device token in the production environment and the device token in the development environment are not the same value.
Source
I'm upgrading an app to Rails 3.1. Quote often, Firebug will complain about some assets. Here are some errors pasted from Firebug:
"NetworkError: 500 Internal Server Error - http://unstilted.dev/assets/jquery-ui.js?body=1"
jquery...?body=1
"NetworkError: 500 Internal Server Error - http://unstilted.dev/assets/admin/pages/file_attachments.js"
file_a...ents.js
"NetworkError: 500 Internal Server Error - http://unstilted.dev/assets/admin/file_attachments/sortable.js?body=1"
sortab...?body=1
"NetworkError: 500 Internal Server Error - http://unstilted.dev/assets/jquery.js?body=1"
Refreshing the page would yield different assets showing the same error. When I copy and paste the URL I see the files just fine.
I'm using:
Ubuntu 11.04
Apache+Passenger 3.0.9
How do I fix this?
UPDATE: Log file
In this particular instance, jquery-ui.js was showing an error in Firebug. My log file looked like this:
Started GET "/assets/jquery.js?body=1" for 127.0.0.1 at Tue Sep 06 22:24:39 +0800 2011
Served asset /jquery.js - 304 Not Modified (0ms)
Started GET "/assets/jquery_ujs.js?body=1" for 127.0.0.1 at Tue Sep 06 22:24:39 +0800 2011
Started GET "/admin/site/sites/storage.js" for 127.0.0.1 at Tue Sep 06 22:24:39 +0800 2011
Served asset /jquery_ujs.js - 304 Not Modified (0ms)
Started GET "/assets/application.js?body=1" for 127.0.0.1 at Tue Sep 06 22:24:39 +0800 2011
Processing by Admin::Site::SitesController#storage as JS
Served asset /application.js - 304 Not Modified (3ms)
...
Rendered admin/site/sites/storage.js.erb (0.1ms)
Completed 200 OK in 58ms (Views: 5.1ms | ActiveRecord: 21.1ms)
Started GET "/assets/admin/logo.png" for 127.0.0.1 at Tue Sep 06 22:24:39 +0800 2011
Served asset /admin/logo.png - 304 Not Modified (0ms)
It seems to have skipped jquery-ui.js!
UPDATE Oct 1, 2011:
I tried it out with the standalone passenger (passenger start) as it seems to give a more descriptive error. This is what happens when I try to load just the jquery.js file and press CTRL-R repeatedly to refresh my browser and load that asset repeatedly.
Started GET "/assets/jquery.js?body=1" for 127.0.0.1 at 2011-10-01 21:40:18 +0800
[ pid=29485 thr=3066030960 file=ext/nginx/HelperAgent.cpp:931 time=2011-10-01 21:40:18.691 ]: Uncaught exception in PassengerServer client thread:
exception: Cannot read response from backend process: Connection reset by peer (104)
backtrace:
in 'void Client::forwardResponse(Passenger::SessionPtr&, Passenger::FileDescriptor&, const Passenger::AnalyticsLogPtr&)' (HelperAgent.cpp:603)
in 'void Client::handleRequest(Passenger::FileDescriptor&)' (HelperAgent.cpp:857)
in 'void Client::threadMain()' (HelperAgent.cpp:950)
2011/10/01 21:40:18 [error] 29522#0: *16 upstream prematurely closed connection while reading response header from upstream, client: 127.0.0.1, server: _, request: "GET /assets/jquery.js?body=1 HTTP/1.1", upstream: "passenger:unix:/passenger_helper_server:", host: "get.unstilted.dev:3000"
[ pid=29674 thr=78131090 file=utils.rb:176 time=2011-10-01 21:40:18.699 ]: *** Exception PGError in application (server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
) (process 29674, thread #<Thread:0x9505f24>):
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activerecord-3.1.0/lib/active_record/connection_adapters/postgresql_adapter.rb:276:in `exec'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activerecord-3.1.0/lib/active_record/connection_adapters/postgresql_adapter.rb:276:in `block in clear_cache!'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activerecord-3.1.0/lib/active_record/connection_adapters/postgresql_adapter.rb:275:in `each_value'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activerecord-3.1.0/lib/active_record/connection_adapters/postgresql_adapter.rb:275:in `clear_cache!'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activerecord-3.1.0/lib/active_record/connection_adapters/postgresql_adapter.rb:303:in `disconnect!'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/connection_pool.rb:202:in `block in disconnect!'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/connection_pool.rb:201:in `each'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/connection_pool.rb:201:in `disconnect!'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activesupport-3.1.0/lib/active_support/core_ext/module/synchronization.rb:35:in `block in disconnect_with_synchronization!'
from /home/ramon/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activesupport-3.1.0/lib/active_support/core_ext/module/synchronization.rb:34:in `disconnect_with_synchronization!'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/connection_pool.rb:395:in `block in clear_all_connections!'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/connection_pool.rb:395:in `each_value'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/connection_pool.rb:395:in `clear_all_connections!'
from /home/ramon/.rvm/gems/ruby-1.9.2-p290#unstilted/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/connection_specification.rb:123:in `clear_all_connections!'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/utils.rb:398:in `before_handling_requests'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/rack/application_spawner.rb:204:in `start_request_handler'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/rack/application_spawner.rb:170:in `block in handle_spawn_application'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/utils.rb:479:in `safe_fork'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/rack/application_spawner.rb:165:in `handle_spawn_application'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/abstract_server.rb:357:in `server_main_loop'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/abstract_server.rb:206:in `start_synchronously'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/abstract_server.rb:180:in `start'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/rack/application_spawner.rb:128:in `start'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/spawn_manager.rb:253:in `block (2 levels) in spawn_rack_application'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/abstract_server_collection.rb:132:in `lookup_or_add'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/spawn_manager.rb:246:in `block in spawn_rack_application'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/abstract_server_collection.rb:82:in `block in synchronize'
from <internal:prelude>:10:in `synchronize'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/abstract_server_collection.rb:79:in `synchronize'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/spawn_manager.rb:244:in `spawn_rack_application'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/spawn_manager.rb:137:in `spawn_application'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/spawn_manager.rb:275:in `handle_spawn_application'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/abstract_server.rb:357:in `server_main_loop'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/lib/phusion_passenger/abstract_server.rb:206:in `start_synchronously'
from /home/ramon/.passenger/standalone/3.0.9-x86-ruby1.9.2-linux-gcc4.5.2-1002/support/helper-scripts/passenger-spawn-server:99:in `<main>'
Served asset /jquery.js - 304 Not Modified (0ms)
cache: [GET /assets/jquery.js?body=1] stale, valid, store
[ pid=29485 thr=3064224624 file=ext/nginx/HelperAgent.cpp:921 time=2011-10-01 21:40:18.734 ]: Couldn't forward the HTTP response back to the HTTP client: It seems the user clicked on the 'Stop' button in his browser.
The problem is in the middle of Passenger and Rails 3.1 PostgreSQL adapter.
According to this issue https://github.com/rails/rails/issues/1339
Rails 3.1.1.rc1 should have this issue fixed.
Also stop using PassengerSpawnMethod conservative because it makes Passenger & eventually REE performance optimizations useless - it spawns separate Rails instances - no sharing of common code.
I had the same issue. For me I think it was some cached assets or something.
I ran
rake assets:clean
and then requested the page again. This generated real error messages I could use to debug.
It turned out that one of my JS files still had the old require syntax with <>s.
Hope this solves your problem too, I know it was frustrating!
The quick fix is to tell passenger to use the 'conservative' spawn method.
in your apache2.conf
PassengerSpawnMethod conservative