无法杀死端口3000上的进程

时间:2017-01-12 14:43:03

标签: ruby-on-rails bash macos unix puma

我似乎无法弄清楚如何杀死这个过程。

我已经知道,我可以,而且一直只是在不同的端口上运行服务器,但是我只是讨厌我,我无法解决这个问题。

下面你将首先看到我尝试运行rails时遇到的错误,然后我尝试找到PID并杀死所有的错误。

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

5 个答案:

答案 0 :(得分:6)

找到您的rails s进程PID并将其终止

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

或者你可以试试这个班轮

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

答案 1 :(得分:0)

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

答案 2 :(得分:0)

当我运行rails时,我得到lsof的以下输出:

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

所以你似乎已经弄清楚了什么进程在端口3000上运行,postgres用户所拥有的postgres进程可能与rails相关。鉴于它运行在非常低的pid 101,它很可能在启动过程中启动。因此,在重点关注如何杀死它时,我会看看是什么原因导致它首先开始。也许您应该检查你的postrgres配置(postgres.conf),它的设置是否已更改为在端口3000上运行?

如果你真的想杀了它,sudo就是你的朋友:

sudo kill 101

我小心使用kill -9因为使用该信号杀死数据库存在某些风险(SIGKILL),该过程将立即死亡并且无法自行清理(更多信息)这个:GIYF,例如https://www.linuxvoice.com/core-technology-signals/。对于stackoverflow(IIRC)上的信号有一个很好的答案,但现在似乎无法找到它......)

答案 3 :(得分:0)

如果您已经知道端口(例如3000),请尝试

npx kill-port 3000

答案 4 :(得分:-1)

ps aux | grep 3000

sudo kill -9  完全杀死进程的力量