Rails wirklich seltsames Problem beim Starten von Rails-Server

Question

Ich habe gerade eine neue Rails-App mit Rails neu initiiert, die Standard-Datenbankeinstellungen in PostgresSQL geändert. Ich starte den Server mit bin/Schienen s und ich diese seltsame

2016-04-21 05:00:33] INFO WEBrick 1.3.1 
[2016-04-21 05:00:33] INFO ruby 2.1.3 (2014-09-19) [i686-linux] 
[2016-04-21 05:00:33] INFO WEBrick::HTTPServer#start: pid=12160 port=3000 


Started GET "/socket.io/?EIO=3&transport=polling&t=LGtCFqz" for 10.0.2.2 at 2016-04-21 05:00:38 +0000 

ActionController::RoutingError (No route matches [GET] "/socket.io"): 
    actionpack (4.1.6) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call' 
    actionpack (4.1.6) 

lib/action_dispatch/middleware/show_exceptions.rb:30:in `call' 
    railties (4.1.6) lib/rails/rack/logger.rb:38:in `call_app' 
    railties (4.1.6) lib/rails/rack/logger.rb:20:in `block in call' 
    activesupport (4.1.6) lib/active_support/tagged_logging.rb:68:in `block in tagged' 
    activesupport (4.1.6) lib/active_support/tagged_logging.rb:26:in `tagged' 
    activesupport (4.1.6) lib/active_support/tagged_logging.rb:68:in `tagged' 
    railties (4.1.6) lib/rails/rack/logger.rb:20:in `call' 
    actionpack (4.1.6) lib/action_dispatch/middleware/request_id.rb:21:in `call' 
    rack (1.5.5) lib/rack/methodoverride.rb:21:in `call' 
    rack (1.5.5) lib/rack/runtime.rb:17:in `call' 
    activesupport (4.1.6) lib/active_support/cache/strategy/local_cache_middleware.rb:26:in `call' 
    rack (1.5.5) lib/rack/lock.rb:17:in `call' 
    actionpack (4.1.6) lib/action_dispatch/middleware/static.rb:64:in `call' 
    rack (1.5.5) lib/rack/sendfile.rb:112:in `call' 
    railties (4.1.6) lib/rails/engine.rb:514:in `call' 
    railties (4.1.6) lib/rails/application.rb:144:in `call' 
    rack (1.5.5) lib/rack/lock.rb:17:in `call' 
    rack (1.5.5) lib/rack/content_length.rb:14:in `call' 
    rack (1.5.5) lib/rack/handler/webrick.rb:60:in `service' 
    /usr/local/rvm/rubies/ruby-2.1.3/lib/ruby/2.1.0/webrick/httpserver.rb:138:in `service' 
    /usr/local/rvm/rubies/ruby-2.1.3/lib/ruby/2.1.0/webrick/httpserver.rb:94:in `run' 
    /usr/local/rvm/rubies/ruby-2.1.3/lib/ruby/2.1.0/webrick/server.rb:295:in `block in start_thread' 

Diese Zeile in der Stack-Trace wirklich beunruhigt mich:

Started GET "/socket.io/?EIO=3&transport=polling&t=LGtCFqz" for 10.0.2.2 at 2016-04-21 05:00:38 +0000 

ich ein websocket Juwel auch genannt em-WebSockets installiert hatte als der dünne Edelstein. Ich habe beide von Ruby deinstalliert, aber ich bekomme immer noch diesen Fehler.

source 'https://rubygems.org' 

# Bundle edge Rails instead: gem 'rails', github: 'rails/rails' 
gem 'rails', '4.1.6' 
# postgres db 
gem 'pg' 
# Use SCSS for stylesheets 
gem 'sass-rails', '~> 4.0.3' 
# Use Uglifier as compressor for JavaScript assets 
gem 'uglifier', '>= 1.3.0' 
# Use CoffeeScript for .js.coffee assets and views 
gem 'coffee-rails', '~> 4.0.0' 
# See https://github.com/sstephenson/execjs#readme for more supported runtimes 
# gem 'therubyracer', platforms: :ruby 

# Use jquery as the JavaScript library 
gem 'jquery-rails' 
# Turbolinks makes following links in your web application faster. Read more: https://github.com/rails/turbolinks 
gem 'turbolinks' 
# Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder 
gem 'jbuilder', '~> 2.0' 
# bundle exec rake doc:rails generates the API under doc/api. 
gem 'sdoc', '~> 0.4.0',   group: :doc 

# Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring 
gem 'spring',  group: :development 

# Use ActiveModel has_secure_password 
# gem 'bcrypt', '~> 3.1.7' 

# Use unicorn as the app server 
# gem 'unicorn' 

# Use Capistrano for deployment 
# gem 'capistrano-rails', group: :development 

# Use debugger 
# gem 'debugger', group: [:development, :test] 

Dies ist meine gemfile. Es hat nichts mit Websockets, soweit ich das beurteilen kann. Hat jemand dazu einen Einblick?

Vielen Dank.

Answer 1

Ich neu gestartet und den Server in Standardschienen (0.0.0.0: 3000) neu gestartet. Es hat sich selbst behoben.

Vielen Dank für die Hilfe.