ポート3000でプロセスを終了できません

Question

このプロセスを強制終了する方法がわかりません。

私は既に、別のポートでサーバを稼働させることができて、これまで行ってきたことは知っていますが、これはわかりません。

以下は、私がレールを走らせてから、PIDを見つけてkillしようとしたときのエラーです。

// ♥ 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 

Answer 1

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

Answer 2

あなたrails sプロセスPIDを見つけ、

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

か、この1つのライナー

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

Answer 3

PSの補助を試すことができますそれを殺します| grepの3000

のsudoのkill -9私はレールを実行している間、私はlsofをのために次の出力を取得し、完全に

Answer 4

プロセス力を殺す ：

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

だから、あなたはすでに考え出したように見えますどのプロセスがポート3000で実行されているか、postgresユーザが所有するプロセスで、おそらくレール関連ではない可能性があります。それが非常に低いpid（101）上で実行されていることを考えると、ブートプロセス内で起動する可能性が非常に高いです。だから、それを殺す方法に焦点を当てる代わりに、私はそれが最初に始まった原因を考えます。おそらく、postrgresの設定（postgres.conf）を確認してください。ポート3000で実行するように設定が変更されましたか？

あなたが本当にそれを殺したい場合は、sudoはあなたの友達です：

sudo kill 101

その信号（SIGKILL）でデータベースを殺すのに一定のリスクがあるので、私はkill -9を使用して慎重になるだろう、プロセスはすぐに死ぬでしょうし、それ自身の後でクリーンアップすることはできません（詳細については、GIYF、例えばhttps://www.linuxvoice.com/core-technology-signals/）。stackoverflow（IIRC）のシグナルについては良い答えがありましたが、