Server web sottile: `start_tcp_server ': nessun accettore (RuntimeError) dopo il checkout di git branch


110

Un'app Rails 3.2.0, che funziona bene con il server web Thin, sia localmente che sullo stack di cedro Heroku.

Dopo:

$ git branch work
$ git checkout work
$ rails server

Ottengo:

=> Booting Thin
=> Rails 3.2.0 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
>> Thin web server (v1.3.1 codename Triple Espresso)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:3000, CTRL+C to stop
Exiting
/Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/eventmachine-0.12.10/lib/eventmachine.rb:572:in `start_tcp_server': no acceptor (RuntimeError)
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/eventmachine-0.12.10/lib/eventmachine.rb:572:in `start_server'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/thin-1.3.1/lib/thin/backends/tcp_server.rb:16:in `connect'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/thin-1.3.1/lib/thin/backends/base.rb:53:in `block in start'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `call'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/thin-1.3.1/lib/thin/backends/base.rb:61:in `start'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/thin-1.3.1/lib/thin/server.rb:159:in `start'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/rack-1.4.1/lib/rack/handler/thin.rb:13:in `run'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/rack-1.4.1/lib/rack/server.rb:265:in `start'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/railties-3.2.0/lib/rails/commands/server.rb:70:in `start'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/railties-3.2.0/lib/rails/commands.rb:55:in `block in <top (required)>'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/railties-3.2.0/lib/rails/commands.rb:50:in `tap'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/railties-3.2.0/lib/rails/commands.rb:50:in `<top (required)>'
from script/rails:6:in `require'
from script/rails:6:in `<main>'

Inoltre, quando lo faccio:

sudo bundle exec rails server thin -p 3000

Ottengo:

/Users/peter/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:247:in `to_specs': Could not find bundler (>= 0) amongst [bigdecimal-1.1.0, io-console-0.3, json-1.5.4, minitest-2.5.1, rake-0.9.2.2, rdoc-3.9.4] (Gem::LoadError)
from /Users/peter/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:256:in `to_spec'
from /Users/peter/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/site_ruby/1.9.1/rubygems.rb:1210:in `gem'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/bin/bundle:18:in `<main>'

Ho installato il bundler 1.0.22. Aggiornato e installato. Niente sembra funzionare. Qualche idea?


1
Hai già un server in esecuzione altrove sulla macchina? Forse in cetriolo o qualcosa del genere?
Josh Leitzel

1
No, non l'ho fatto. In realtà, il riavvio del computer aveva risolto il mio problema. Oggi è successo di nuovo. Sembra accadere quando passo da un ramo git a un altro.
maeseele

2
Grazie! Il mio messaggio di errore su MacOSX era ... eventmachine-1.0.0/lib/eventmachine.rb:526:in `start_tcp_server': no acceptor (port is in use or requires root privileges) (RuntimeError).
JJD

Lo stesso per me quando ho provato a utilizzare la stessa porta per eseguire due applicazioni diverse. Questo argomento mi ha fatto pensare all'altra applicazione in esecuzione.
Vadorequest

Risposte:


226

Questo funziona per me. Trova il server (zombie?) (Può accadere quando si esce dal terminale con il server in esecuzione):

$ ps ax | grep rails

Se restituisce qualcosa di simile:

33467 s002 S+ 0:00.00 grep rails
33240 s003 S+ 0:15.05 /Users/Arta/.rbenv/versions/1.9.2-p290/bin/ruby script/rails s -p 3000

uccidilo e corri di nuovo:

$ kill -9 33240
$ rails s

17
Se ps ax | grep railsnon viene fuori nulla, prova ps ax | grep ruby.
Kevin

3
Sicuramente accade su OSX se esci direttamente dalla finestra del terminale mentre il server rails è in esecuzione. +1
notaceo


48

Se c'è qualche altro processo che blocca la porta, puoi scoprire quale PID ha in questo modo:

$ lsof -i :3000
COMMAND     PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
Passenger 40466 josh    5u  IPv4 0x7cae9332073ed4df      0t0  TCP *:hbci (LISTEN)
Passenger 40467 josh    5u  IPv4 0x7cae9332073ed4df      0t0  TCP *:hbci (LISTEN)

Quindi uccidilo semplicemente:

$ kill -9 40466
$ kill -9 40467

ntopstava usando la porta 3000 sulla mia macchina. La risposta è perfetta.
Tass

47

pgrep ruby per vedere quali server sono in esecuzione e poi

kill -9 serverNumber

;)



6

Ho questo errore perché stavo eseguendo rails-dev-box con Rails al suo interno.

Port 3000 in the host computer is forwarded to port 3000 in the virtual machine. 
Thus, applications running in the virtual machine can be accessed via 
localhost:3000 in the host computer.

Quindi viene disconnesso da Vagrant e disattivato:

vagrant@rails-dev-box:/vagrant/rails$ exit
$ vagrant halt

Questo mi ha aiutato.


Ho avuto lo stesso problema. Avevo vagabondo che correva da un progetto separato. Probabilmente non comune, ma mi ha aiutato. Grazie! +1
jake

5

Ho riscontrato questo errore perché stavo già eseguendo rails in un altro terminale. La chiusura del mio altro progetto ha risolto questo problema.


1
Se desideri eseguire entrambi i programmi contemporaneamente, puoi avviare il secondo server su una porta diversa.
Kevin

@ Kevin ottimo punto. Non stavo cercando di fare, ho solo dimenticato che l'altro progetto era in corso.
aarona

@ DJ Questo ha senso. Stavo postando il mio commento per i futuri lettori :)
Kevin

2

Ho riscontrato un problema simile dopo essere tornato in ufficio dalle vacanze. Corro il mio server sull'IP locale come:

rails s thin -b <my_ip>

Il problema era che il mio IP era cambiato, dovevo solo usare quello nuovo.


2

Eseguilo nel terminale

sudo netstat -lpn |grep rails

E poi

sudo kill <job id>

Questo è stato l'unico modo in cui sono stato in grado di trovare i miei processi, anche se ho dovuto cercare sottili invece di binari.
ladro di

Sì, funziona nella maggior parte dei casi. Se ti è piaciuto vota per favore.
Sam

Trovare e terminare l'ID di processo ha funzionato. Anche se il primo comando non ha funzionato per me, ma ps aux | grep rails.
Francisco Quintero
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.