Update I tried catching this exception in my application controller, but to no avail. I've also updated Passenger to 3.0.7 and submitted an issue to their tracker.
I have a Rails 3.0.4 application running on FreeBSD 8.2 with Apache 2.2.17, Passenger 3.0.2 and Ruby 1.9.2-p180 that's been dying every other day. Here's the backtrace from the error log:
[ pid=85853 thr=17189069660 file=utils.rb:176 time=2011-05-04 12:08:13.022 ]:
*** Exception ActionController::UnknownHttpMethod in application
(U<F9>i<CA>,fs<C8>6<F6><C0>b<F2><C5>hVj<BE><D9>#<F5><80><99><EA>=n,
accepted HTTP methods are OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT,
PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, VERSION-CONTROL, REPORT, CHECKOUT,
CHECKIN, UNCHECKOUT, MKWORKSPACE, UPDATE, LABEL, MERGE, BASELINE-CONTROL, MKACTIVITY,
ORDERPATCH, ACL, SEARCH, and PATCH) (process 85853, thread #<Thread:0x0000080118c6b8>):
from /usr/local/docs/arc/shared/bundle/ruby/1.9.1/gems/actionpack-3.0.4/lib/action_dispatch/http/request.rb:76:in `request_method'
from /usr/local/docs/arc/shared/bundle/ruby/1.9.1/gems/railties-3.0.4/lib/rails/rack/logger.rb:24:in `before_dispatch'
from /usr/local/docs/arc/shared/bundle/ruby/1.9.1/gems/railties-3.0.4/lib/rails/rack/logger.rb:12:in `call'
from /usr/local/docs/arc/shared/bundle/ruby/1.9.1/gems/rack-1.2.1/lib/rack/runtime.rb:17:in `call'
from /usr/local/docs/arc/shared/bundle/ruby/1.9.1/gems/rack-1.2.1/lib/rack/lock.rb:11:in `block in call'
from <internal:prelude>:10:in `synchronize'
from /usr/local/docs/arc/shared/bundle/ruby/1.9.1/gems/rack-1.2.1/lib/rack/lock.rb:11:in `call'
from /usr/local/docs/arc/shared/bundle/ruby/1.9.1/gems/railties-3.0.4/lib/rails/application.rb:168:in `call'
from /usr/local/docs/arc/shared/bundle/ruby/1.9.1/gems/railties-3.0.4/lib/rails/application.rb:77:in `method_missing'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/rack/request_handler.rb:96:in `process_request'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/abstract_request_handler.rb:513:in `accept_and_process_next_request'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/abstract_request_handler.rb:274:in `main_loop'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/rack/application_spawner.rb:205:in `start_request_handler'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/rack/application_spawner.rb:170:in `block in handle_spawn_application'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/utils.rb:479:in `safe_fork'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/rack/application_spawner.rb:165:in `handle_spawn_application'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/abstract_server.rb:357:in `server_main_loop'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/abstract_server.rb:206:in `start_synchronously'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/abstract_server.rb:180:in `start'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/rack/application_spawner.rb:128:in `start'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/spawn_manager.rb:253:in `block (2 levels) in spawn_rack_application'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/abstract_server_collection.rb:132:in `lookup_or_add'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/spawn_manager.rb:246:in `block in spawn_rack_application'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/abstract_server_collection.rb:82:in `block in synchronize'
from <internal:prelude>:10:in `synchronize'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/abstract_server_collection.rb:79:in `synchronize'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/spawn_manager.rb:244:in `spawn_rack_application'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/spawn_manager.rb:137:in `spawn_application'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/spawn_manager.rb:275:in `handle_spawn_application'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/abstract_server.rb:357:in `server_main_loop'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/lib/phusion_passenger/abstract_server.rb:206:in `start_synchronously'
from /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.2/helper-scripts/passenger-spawn-server:99:in `<main>'
[Wed May 04 12:08:13 2011] [notice] child pid 1567 exit signal Bus error (10)
[Wed May 04 12:08:16 2011] [notice] child pid 1195 exit signal Bus error (10)
[Wed May 04 12:08:20 2011] [notice] child pid 1600 exit signal Bus error (10)
[Wed May 04 12:08:20 2011] [notice] child pid 1590 exit signal Bus error (10)
[Wed May 04 12:08:21 2011] [notice] child pid 1199 exit signal Bus error (10)
[Wed May 04 12:08:21 2011] [notice] child pid 726 exit signal Bus error (10)...etc...
Once this happens, the application goes down. Apache still serves up static files in the public directory, but no application. Of course the gobbledygook where the http verb should be concerns me (and makes it impossible to track down via google), but will rescuing this exception in the application_controller actually prevent passenger from dying? Anyone seen this before?
To be perfectly honest, it looks like your application server (fastcgi or apache moduel?) is dieing quite ungracefully when an illegal HTTP verb is received.
I fully expect that you can filter this in the apache config for the site (be it /etc/apache2/site-available/... or .htaccess in your virtual folder (mod_access)
However, I think it is sane to just report the trace to the Passenger devs as a bug. The info is right there in the trace
U<F9>i<CA>,fs<C8>6<F6><C0>b<F2><C5>hVj<BE><D9>#<F5><80><99><EA>=n
is not a valid verb. It could be trivial to reproduce using netcat on port 80 of your webserver (remember the Host header)
Related
Can't start Puma for some reason. Getting this error
ArgumentError: couldn't find login name -- expanding `~'
With the below back trace
Feb 03 15:44:21 shopify-shipping-refactor puma[3061]: Done in 1.33s.
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: rake aborted!
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: ArgumentError: couldn't find login name -- expanding `~'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/pry-0.12.2/lib/pry/pry_class.rb:5:in `expand_path'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/pry-0.12.2/lib/pry/pry_class.rb:5:in `<class:Pry>'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/pry-0.12.2/lib/pry/pry_class.rb:1:in `<top (required)>'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/pry-0.12.2/lib/pry.rb:119:in `require'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/pry-0.12.2/lib/pry.rb:119:in `<top (required)>'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/bundler-2.1.4/lib/bundler/runtime.rb:74:in `require'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/bundler-2.1.4/lib/bundler/runtime.rb:74:in `block (2 levels) in require'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/bundler-2.1.4/lib/bundler/runtime.rb:69:in `each'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/bundler-2.1.4/lib/bundler/runtime.rb:69:in `block in require'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/bundler-2.1.4/lib/bundler/runtime.rb:58:in `each'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/bundler-2.1.4/lib/bundler/runtime.rb:58:in `require'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/bundler-2.1.4/lib/bundler.rb:174:in `require'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /opt/shopify_shipping_refactor/config/application.rb:7:in `<top (required)>'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /opt/shopify_shipping_refactor/Rakefile:4:in `require'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /opt/shopify_shipping_refactor/Rakefile:4:in `<top (required)>'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/gems/rake-13.0.1/exe/rake:27:in `<top (required)>'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/bin/ruby_executable_hooks:24:in `eval'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: /usr/local/rvm/gems/ruby-2.6.5/bin/ruby_executable_hooks:24:in `<main>'
Feb 03 15:44:25 shopify-shipping-refactor puma[3061]: (See full trace by running task with --trace)
Feb 03 15:44:25 shopify-shipping-refactor systemd[1]: puma.service: Control process exited, code=exited status=1
Feb 03 15:44:25 shopify-shipping-refactor systemd[1]: Failed to start puma.service.
Feb 03 15:44:25 shopify-shipping-refactor systemd[1]: puma.service: Unit entered failed state.
Feb 03 15:44:25 shopify-shipping-refactor systemd[1]: puma.service: Failed with result 'exit-code'.
Analysis: Ruby's expand_path calls into the C-based runtime (obscuring the stack trace), but eventually ends up in rb_default_home_dir to figure out what '~' is. This method relies on the $HOME environment variable to figure this out and falls back to getlogin() (getlogin(3)) and getpwnam() if it's not available.
Cause: The error message you're seeing is from that fallback failing, since (presumably) your process is not registered with a controlling tty and login user.
Solution: Set $HOME when running puma. Use a directory that you want the Puma to use as a home directory when '~' is specified.
I get the following error in apache log on puppet master:
Any ideas what could be wrong here:
[ E 2018-03-11 07:50:58.9057 10913/T8 age/Cor/Con/CheckoutSession.cpp:285 ]: [Client 1-1] Cannot checkout session because a spawning error occurred. The identifier of the error is cd3585fe. Please see earlier logs for details about the error.
App 10950 stdout:
App 10950 stdout:
[ E 2018-03-11 07:51:03.0922 10913/Te age/Cor/App/Implementation.cpp:304 ]: Could not spawn process for application /usr/share/puppet/rack/puppetmasterd: An error occurred while starting up the preloader.
Error ID: 01cd04d1
Error details saved to: /tmp/passenger-error-sAcbhg.html
Message from application: cannot load such file -- puppet/util/command_line (LoadError)
/usr/local/rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
config.ru:32:in `block in <main>'
/usr/local/rvm/gems/ruby-2.4.1/gems/rack-2.0.4/lib/rack/builder.rb:55:in `instance_eval'
/usr/local/rvm/gems/ruby-2.4.1/gems/rack-2.0.4/lib/rack/builder.rb:55:in `initialize'
config.ru:1:in `new'
config.ru:1:in `<main>'
/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.2.1/src/helper-scripts/rack-preloader.rb:110:in `eval'
/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.2.1/src/helper-scripts/rack-preloader.rb:110:in `preload_app'
/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.2.1/src/helper-scripts/rack-preloader.rb:156:in `<module:App>'
/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.2.1/src/helper-scripts/rack-preloader.rb:30:in `<module:PhusionPassenger>'
/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.2.1/src/helper-scripts/rack-preloader.rb:29:in `<main>'
My config:
Centos 6.5,
Puppet 3.8.7,
Apache/2.2.15,
Phusion Passenger 5.2.1
We have UI automation test framework based on cucumber. Recently we have moved from Ruby 1.9.x to 2.2.0 and after that we are facing problem in login to our application via test framework. It says SSL connect reset problem.
Error Trace:
07:01:26 An existing connection was forcibly closed by the remote host. - SSL_connect (Errno::ECONNRESET)
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient/ssl_socket.rb:46:in `connect'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient/ssl_socket.rb:46:in `ssl_connect'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient/ssl_socket.rb:24:in `create_socket'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient/session.rb:739:in `block in connect'
07:01:26 D:/Ruby223/lib/ruby/2.2.0/timeout.rb:88:in `block in timeout'
07:01:26 D:/Ruby223/lib/ruby/2.2.0/timeout.rb:98:in `call'
07:01:26 D:/Ruby223/lib/ruby/2.2.0/timeout.rb:98:in `timeout'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient/session.rb:735:in `connect'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient/session.rb:497:in `query'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient/session.rb:170:in `query'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient.rb:1238:in `do_get_block'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient.rb:1021:in `block in do_request'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient.rb:1129:in `protect_keep_alive_disconnected'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient.rb:1016:in `do_request'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient.rb:858:in `request'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/httpclient-2.7.1/lib/httpclient.rb:761:in `post'
<-- our Code for login kick in to call httpclient --->
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/cucumber-2.3.2/lib/cucumber/rb_support/rb_language.rb:96:in `load'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/cucumber-2.3.2/lib/cucumber/rb_support/rb_language.rb:96:in `load_code_file'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/cucumber-2.3.2/lib/cucumber/runtime/support_code.rb:142:in `load_file'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/cucumber-2.3.2/lib/cucumber/runtime/support_code.rb:84:in `block in load_files!'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/cucumber-2.3.2/lib/cucumber/runtime/support_code.rb:83:in `each'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/cucumber-2.3.2/lib/cucumber/runtime/support_code.rb:83:in `load_files!'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/cucumber-2.3.2/lib/cucumber/runtime.rb:254:in `load_step_definitions'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/cucumber-2.3.2/lib/cucumber/runtime.rb:62:in `run!'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/cucumber-2.3.2/lib/cucumber/cli/main.rb:32:in `execute!'
07:01:26 D:/Ruby223/lib/ruby/gems/2.2.0/gems/cucumber-2.3.2/bin/cucumber:8:in `<top (required)>'
I had the same issue a while back after moving to ruby 2.0.0
Follow the following steps to solve it
1)Visit the url http://curl.haxx.se/ca/cacert.pem save the contents as a .pem file(Do not save it as a text file.Make sure the extension is .pem)
2)Copy the file to any path in your local eg: C:\ruby200\ca_cert.pem (in my case)
3)Now add an Environment variable with Variable SSL_CERT_FILE and value "C:\ruby200\ca_cert.pem"(without quotes)(path is in my case.Replace with appropriate path)
(Environment variables can be added by navigating to Computer -> Advanced Settings -> Environment Variables)
4)Close all your command prompts and restart them.Things should work fine now
I think your gem is updated.Add these lines in your code to solve the problem
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
before http.use_ssl = true
I hope this might solve the problem.
I am attempting to use the deck.js backend with asciidoctor. I followed the instructions at http://asciidoctor.org/docs/install-and-use-deckjs-backend/. I get the following error:
$ asciidoctor --trace -T asciidoctor-backends/haml deckjs-example.asciidoc
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- asciidoctor/stylesheets (LoadError)
from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from /home/worldwidewilly/Dropbox/presentations/adoc-deck/asciidoctor-backends/haml/deckjs/helpers.rb:1:in `<top (required)>'
from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from /var/lib/gems/1.9.1/gems/asciidoctor-0.1.4/lib/asciidoctor/renderer.rb:121:in `block in initialize'
from /var/lib/gems/1.9.1/gems/asciidoctor-0.1.4/lib/asciidoctor/renderer.rb:69:in `each'
from /var/lib/gems/1.9.1/gems/asciidoctor-0.1.4/lib/asciidoctor/renderer.rb:69:in `initialize'
from /var/lib/gems/1.9.1/gems/asciidoctor-0.1.4/lib/asciidoctor/document.rb:743:in `new'
from /var/lib/gems/1.9.1/gems/asciidoctor-0.1.4/lib/asciidoctor/document.rb:743:in `renderer'
from /var/lib/gems/1.9.1/gems/asciidoctor-0.1.4/lib/asciidoctor/document.rb:752:in `render'
from /var/lib/gems/1.9.1/gems/asciidoctor-0.1.4/lib/asciidoctor.rb:915:in `render'
from /var/lib/gems/1.9.1/gems/asciidoctor-0.1.4/lib/asciidoctor/cli/invoker.rb:86:in `block in invoke!'
from /var/lib/gems/1.9.1/gems/asciidoctor-0.1.4/lib/asciidoctor/cli/invoker.rb:79:in `each'
from /var/lib/gems/1.9.1/gems/asciidoctor-0.1.4/lib/asciidoctor/cli/invoker.rb:79:in `invoke!'
from /var/lib/gems/1.9.1/gems/asciidoctor-0.1.4/bin/asciidoctor:13:in `<top (required)>'
from /usr/local/bin/asciidoctor:23:in `load'
from /usr/local/bin/asciidoctor:23:in `<main>'
My document - deckjs-example - looks like:
= Asciidoctor Deckjs Example
Bill Turner
:backend: deckjs
:deckjs_theme: web-2.0
:deckjs_transition: horizontal-slide
:navigation:
:blank:
:goto:
:menu:
:status:
:split:
:toc:
== Title of Slide One
Hello World!
[canvas-image="images/groovy.jpg"]
== Slide Two's Title will not be displayed
[role="canvas-caption", position="center-up"]
This text is displayed on top of the example.jpg image.
My directory contains all the things that I seem to need to have installed:
$ ls
total 32K
22021551 drwxr-xr-x 7 worldwidewilly worldwidewilly 4.0K Apr 27 13:38 asciidoctor-backends
24910534 drwxr-xr-x 8 worldwidewilly worldwidewilly 4.0K Apr 21 20:30 deck.js
527971 -rw-r--r-- 1 worldwidewilly worldwidewilly 394 Apr 27 14:01 deckjs-example.asciidoc
26740079 drwxr-xr-x 2 worldwidewilly worldwidewilly 4.0K Apr 27 14:00 images
I presume a configuration problem. Searching has yet to reveal a solution, though I did find a similar problem on the AsciiDoctor discussion group which, unfortunately, did not seem to provide a solution, at least not one I understood.
I am running on Linux Mint 17. It turns out that the asciidoctor package available in the package manager was hopelessly out of date. Note the version used above: asciidoctor-0.1.4. When I updated to the latest version, 1.5.2, all worked fine.
What does Heroku mean by app[web.1] and by <main>:48?
I have a crash that happens only on Heroku and not on my computer, I'm trying to identify the precise line causing the crash. These are the logs
2012-10-08T21:31:49+00:00 app[web.1]: <main>:48:in `method_missing': wrong number of arguments (1 for 2) (ArgumentError)
2012-10-08T21:31:49+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/server.rb:265:in `start'
2012-10-08T21:31:49+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/server.rb:137:in `start'
2012-10-08T21:31:49+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/thin-1.5.0/lib/thin/server.rb:104:in `block in initialize'
2012-10-08T21:31:49+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/bin/rackup:4:in `<top (required)>'
2012-10-08T21:31:49+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/bin/rackup:19:in `load'
2012-10-08T21:31:49+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/thin-1.5.0/lib/thin/server.rb:104:in `==='
2012-10-08T21:31:49+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/bin/rackup:19:in `<main>'
2012-10-08T21:31:49+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/thin-1.5.0/lib/thin/server.rb:102:in `initialize'
2012-10-08T21:31:49+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/handler/thin.rb:9:in `new'
2012-10-08T21:31:49+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/handler/thin.rb:9:in `run'
2012-10-08T21:31:49+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/thin-1.5.0/lib/thin/server.rb:102:in `each'
2012-10-08T21:31:50+00:00 heroku[web.1]: Process exited with status 1
2012-10-08T21:31:50+00:00 heroku[web.1]: State changed from starting to crashed
2012-10-08T21:31:52+00:00 heroku[router]: Error H10 (App crashed) -> GET placeboxy.herokuapp.com/ dyno= queue= wait= service= status=503 bytes=
Is the crash in my code or in the web server Thin or elsewhere?
Edit I changed the Procfile to run the server unicorn on Heroku and the crashed stopped. No error with puma either. Any ideas? Is Thin to fault?
The app[web.1] is a tag that heroku adds to your log to mark which process is emitting the log, as all the logs are collected in a central place, you can still filter a single process and parse the process log.
The <main>:48: part means the file/line where the execution has been stopped because of the exception. In this case (<main>) it's the main script that's being run. You won't find your error there, probably. You have to search in the backtrace for the part of your code that is failing, look for something that's not an external library, nor core ruby. The backtrace you show is of no help, normally the error is much lower in the stack trace.