2017-01-12 1 views
-1

Ich kann nicht herausfinden, wie dieser Prozess zu beenden ist.Kann den Prozess an Port 3000 nicht beenden

Ich weiß bereits, dass ich kann und habe, nur den Server auf einem anderen Port laufen, aber es nervt mich nur, dass ich das nicht herausfinden kann.

Unten sehen Sie zuerst den Fehler, den ich bekomme, wenn ich versuche, Schienen s dann alle meine Versuche, die PID zu finden und zu töten.

// ♥ rails s 
=> Booting Puma 
=> Rails 5.0.0.1 application starting in development on http://localhost:3000 
=> Run `rails server -h` for more startup options 
Puma starting in single mode... 
* Version 3.6.2 (ruby 2.2.3-p173), codename: Sleepy Sunday Serenity 
* Min threads: 5, max threads: 5 
* Environment: development 
* Listening on tcp://localhost:3000 
Exiting 
/Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/puma/binder.rb:266:in `initialize': Address already in use - bind(2) for "::1" port 3000 (Errno::EADDRINUSE) 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/puma/binder.rb:266:in `new' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/puma/binder.rb:266:in `add_tcp_listener' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/puma/binder.rb:260:in `block in add_tcp_listener' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/puma/binder.rb:259:in `each' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/puma/binder.rb:259:in `add_tcp_listener' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/puma/binder.rb:102:in `block in parse' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/puma/binder.rb:85:in `each' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/puma/binder.rb:85:in `parse' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/puma/runner.rb:133:in `load_and_bind' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/puma/single.rb:85:in `run' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/puma/launcher.rb:172:in `run' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/puma-3.6.2/lib/rack/handler/puma.rb:51:in `run' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/rack-2.0.1/lib/rack/server.rb:296:in `start' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/railties-5.0.0.1/lib/rails/commands/server.rb:79:in `start' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/railties-5.0.0.1/lib/rails/commands/commands_tasks.rb:90:in `block in server' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/railties-5.0.0.1/lib/rails/commands/commands_tasks.rb:85:in `tap' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/railties-5.0.0.1/lib/rails/commands/commands_tasks.rb:85:in `server' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/railties-5.0.0.1/lib/rails/commands/commands_tasks.rb:49:in `run_command!' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/railties-5.0.0.1/lib/rails/commands.rb:18:in `<top (required)>' 
    from /Users/jrogers2/Development/code/presently/bin/rails:9:in `require' 
    from /Users/jrogers2/Development/code/presently/bin/rails:9:in `<top (required)>' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/spring-2.0.0/lib/spring/client/rails.rb:28:in `load' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/spring-2.0.0/lib/spring/client/rails.rb:28:in `call' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/spring-2.0.0/lib/spring/client/command.rb:7:in `call' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/spring-2.0.0/lib/spring/client.rb:30:in `run' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/spring-2.0.0/bin/spring:49:in `<top (required)>' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/spring-2.0.0/lib/spring/binstub.rb:31:in `load' 
    from /Users/jrogers2/.rvm/gems/ruby-2.2.3/gems/spring-2.0.0/lib/spring/binstub.rb:31:in `<top (required)>' 
    from /Users/jrogers2/Development/code/presently/bin/spring:14:in `require' 
    from /Users/jrogers2/Development/code/presently/bin/spring:14:in `<top (required)>' 
    from bin/rails:3:in `load' 
    from bin/rails:3:in `<main>' 
[09:28:36] (master) presently 
// ♥ sudo lsof -n -i4TCP:3000 | grep LISTEN 
postgres 101 postgres 5u IPv4 0x97a8cfe190b174f1  0t0 TCP *:hbci (LISTEN) 
[09:28:43] (master) presently 
// ♥ kill -9 101 
-bash: kill: (101) - Operation not permitted 
[09:28:45] (master) presently 
// ♥ ps aux | grep puma 
jrogers2   27960 0.0 0.0 2432804 1972 s000 S+ 9:28AM 0:00.00 grep puma 
[09:28:58] (master) presently 
// ♥ kill -9 27960 
-bash: kill: (27960) - No such process 
[09:29:14] (master) presently 
// ♥ ps aux | grep 3000 
jrogers2   27971 0.0 0.0 2442612 1196 s000 R+ 9:29AM 0:00.00 grep 3000 
[09:29:28] (master) presently 
// ♥ kill -9 27971 
-bash: kill: (27971) - No such process 
// ♥ lsof -wni tcp:3000 
[09:32:03] (master) presently 
// ♥ lsof -i tcp:3000 
[09:32:41] (master) presently 
// ♥ ps aux | grep rails 
jrogers2   28035 0.0 0.0 2442612 1172 s000 R+ 9:34AM 0:00.00 grep rails 
[09:34:14] (master) presently 
// ♥ kill -9 28035 
-bash: kill: (28035) - No such process 
+0

nicht sicher, ob es in Ihrer Situation funktioniert, aber versuchen Sie: 'sudo fuser -k 3000/tcp' – Nrzonline

+0

Es kann einfacher sein, den Server nur neu zu starten, wenn nichts anderes funktioniert. –

Antwort

0
tmp/pids $ kill -9 $(cat server.pid) 
+0

Obwohl dieser Code zur Lösung des Problems beitragen kann, erklärt er nicht, warum und/oder wie er die Frage beantwortet. Die Bereitstellung dieses zusätzlichen Kontexts würde seinen langfristigen Wert erheblich verbessern. Bitte [bearbeiten] Sie Ihre Antwort, um eine Erläuterung hinzuzufügen, einschließlich der Einschränkungen und Annahmen. Zum Beispiel ist es in der Regel eine gute Idee, auf PID-Wiederverwendung zu prüfen, z. wie 'Start-Stop-Daemon' tut. –

5

Ihre rails s Prozess PID finden und töten

$ ps aux | grep -v grep | grep rails 
$ sudo kill -9 <pid_of_rails_s_from_above> 

oder Sie können diesen Einzeiler

$ sudo kill -9 $(lsof -i tcp:3000 -t) 
+0

@ user3775217 Hallo allerseits, kein Glück. Der Befehl ps aux in der obigen Antwort hat nichts zurückgegeben. noch ein paar Informationen für euch alle Ich habe versucht, meinen Computer vollständig neu zu starten und es ist immer noch da, gleich nach dem Neustart Befehl. Eine Sache ist mir aufgefallen, ich habe eine Web-App, die auf Heroku läuft, könnte das irgendetwas damit zu tun haben? – jd2rogers2

+1

Ihr Schienenprozess muss nach dem Neustart eine andere PID haben. Sie müssen den Autostart-Rails-Prozess bei jedem Neustart eingerichtet haben. – sa77

+0

klingt das vielversprechend, irgendwelche Fragen oder Artikel, die Sie hier lassen können, um mir zu helfen, zu beheben? – jd2rogers2

-1

ps aux versuchen | 3000 grep

sudo kill -9 Welche Prozesskraft vollständig töten

0

Während ich Schienen laufen, ich die folgende Ausgabe für lsof erhalten:

$ sudo lsof -n -i4TCP:3000 | grep LISTEN ruby 23582 username 14u IPv4 0x2c5fd1f36e3c475f 0t0 TCP *:hbci (LISTEN)

So bereits Sie scheinen gedacht zu haben heraus Welcher Prozess wird auf Port 3000 ausgeführt, ein postgres Prozess, der dem postgres Benutzer gehört und wahrscheinlich nicht mit Relationen verbunden ist. Da es auf einer sehr niedrigen PID 101 läuft, wurde es sehr wahrscheinlich innerhalb des Boot-Prozesses gestartet. Anstatt also zu fokussieren, wie man es tötet, würde ich zuerst schauen, was es angestoßen hat. Vielleicht sollten Sie Ihre Postrgres-Konfiguration überprüfen (postgres.conf), wurde das Setup geändert, um auf Port 3000 zu laufen?

Wenn Sie wirklich, es töten wollen, sudo ist dein Freund:

sudo kill 101

Ich würde bei der Verwendung von kill -9 vorsichtig sein, da es gewisse Risiken in Datenbanken mit diesem Signal (SIGKILL) töten, die Prozess wird sofort sterben und kann nicht nach sich selbst aufräumen (mehr dazu: GIYF, zum Beispiel https://www.linuxvoice.com/core-technology-signals/. Es gab eine gute Antwort auf Signale auf stackoverflow (IIRC), aber ich kann es gerade jetzt nicht finden ...)

Verwandte Themen