-1

I cannot seem to figure out how to kill this process.

I already know that i can, and have been, just running the server on a different port, but it's just annoying me that i can't figure this out.

Below you'll see first the error i get when i try to run rails s then all of my attempts to find the PID and 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
ahocevar
  • 5,448
  • 15
  • 29
jd2rogers2
  • 21
  • 1
  • 5

4 Answers4

8

find your rails s process PID and kill it

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

or you can try this one liner

$ sudo kill -9 $(lsof -i tcp:3000 -t)
sa77
  • 3,563
  • 3
  • 24
  • 37
  • @user3775217 hi all, no luck. the ps aux command in the above answer didn't return anything even. some more information for y'all i've tried restarting my computer entirely and it is still there, same after rails restart command. one thing occurred to me, i do have a web app running on heroku, could that have anything to do with it? – jd2rogers2 Jan 12 '17 at 21:54
  • 1
    Your rails process must have different PID after restart. You must have setup autostart rails process on each reboot. – sa77 Jan 13 '17 at 02:35
  • that sounds promising, any questions or articles you can leave here to help me fix? – jd2rogers2 Jan 14 '17 at 19:29
  • that's specific to your local setup .. however, you can try checking login items section on your users and groups panel (spotlight search `users & groups`) .. and remove if any script is running rails server when you boot – sa77 Jan 16 '17 at 16:29
0
tmp/pids $ kill -9 $(cat server.pid)
user3775217
  • 4,675
  • 1
  • 22
  • 33
  • Although this code may help to solve the problem, it doesn't explain _why_ and/or _how_ it answers the question. Providing this additional context would significantly improve its long-term value. Please [edit] your answer to add explanation, including what limitations and assumptions apply. For example, it's usually a good idea to check for PID re-use, e.g. as `start-stop-daemon` does. – Toby Speight Jan 12 '17 at 21:18
0

While I run rails, I get the following output for lsof:

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

So you already seem to have figured out what process is runnning on port 3000, a postgres process owned by the postgres user and probably not rails related. Given that it is running on a very low pid, 101, it was very likely started within the boot process. So instead on focussing how to kill it, I would look what caused it to start in the first place. Perhaps you should check your postrgres config (postgres.conf), was it's setup changed to run on port 3000?

If you really want to kill it, sudo is your friend:

sudo kill 101

I'd be careful with using kill -9 as there are certain risks in killing databases with that signal (SIGKILL), the process will die immediately and can't clean up after itself (more on this: GIYF, for example https://www.linuxvoice.com/core-technology-signals/. There was a good answer on signals on stackoverflow (IIRC), but can't seem to find it just now...)

niels
  • 1,719
  • 10
  • 20
-1

ps aux | grep 3000

sudo kill -9 Which kill process force fully

nisha
  • 1
  • 1