关于ruby on rails：无法杀死端口3000上的进程


Cannot kill process on port 3000

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

我已经知道，我可以，并且一直只是在不同的端口上运行服务器，但这让我感到烦恼，我无法弄清楚这一点。

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
// ? 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
相关讨论

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

1
2
$ 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)
相关讨论

当我运行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就是你的朋友：

<5233>

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

1
tmp/pids $ kill -9 $(cat server.pid)
相关讨论

ps aux | grep 3000

sudo kill -9
哪个杀人过程充分