我似乎无法弄清楚如何杀死这个过程 .
我已经知道,我可以,并且一直只是在不同的端口上运行服务器,但这让我感到烦恼,我无法弄清楚这一点 .
下面你将首先看到我尝试运行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
4 回答
ps aux | grep 3000
sudo kill -9完全杀死进程的力量
找到你的
rails s
进程PID并将其终止或者你可以尝试这一个班轮
当我运行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)上的信号很好的答案,但现在似乎无法找到...)