53

I'm trying to kill a dev server setup via yarn on Windows. While I Ctrl+C'd the command prompt, when I went back to localhost:8080 it had not stopped. How can I kill the process?

Run5k
  • 15,723
  • 24
  • 49
  • 63
Sam Fuller
  • 522
  • 1
  • 4
  • 9
  • 3
    Had the process not stopped or had it restarted after being killed. I would expect Web processes to be run with a monitor to restart it after failures. – mmmmmm Mar 06 '19 at 11:09

4 Answers4

107

You can track down the process running on port 8080 and kill it.

For macOS or Linux:

sudo lsof -iTCP:8080 -sTCP:LISTEN

You should get an output something like:

COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
yarn    12017 user   12u  IPv6 1876683      0t0  TCP *:8080 (LISTEN)

Now that you have the process ID(PID), you can kill the process. First try:

kill 12017(whatever the PID is)

If that does nothing, try:

kill -9 12017

For Windows:

netstat -ano | findstr :8080 (the port number)

This should give you the process to kill. You can then run:

taskkill /F /PID 12017(or whatever the process ID is)
baelx
  • 2,898
  • 1
  • 14
  • 20
  • 6
    For an 'all in one' linux command, check out [fuser](https://linux.die.net/man/1/fuser). `fuser -k 8080/tcp 8080/udp` should kill anything listening on 8080. – mbrig Mar 05 '19 at 18:32
  • 4
    NB: The Windows command will also list all local processes that are _connected_ to the webserver, at the instant that the command was run. The left address:port pair is the source address, the right address:port is the destination. Adding -t tcp will only list TCP connections, not UDP connections – CSM Mar 05 '19 at 20:15
  • @Bakuriu : native Italian user here. Try to guess how that "ano" mnemonic sound hilarious (and unforgettable) to me... – Dr. Gianluigi Zane Zanettini Mar 06 '19 at 08:56
  • @mbrig That's cool, but it sends `SIGKILL` by default. To do kills where the program has a chance to clean up after itself and avoid possible corruption, you can change the signal by providing an option like you would with `kill`, for example `-15` or `-TERM` or `-2` or `-INT`. – JoL Mar 06 '19 at 20:41
  • Windows also has a built-in GUI for this: Resource Monitor (perfmon.exe /res). Under the Network tab, check "Listening Ports." – erobertc Mar 07 '19 at 08:16
  • After `kill -9 PID` the process was always starting again. But `kill PID` stopped it permanently! – Anatolii Stepaniuk Jan 06 '20 at 10:45
7

If you install ProcessExplorer from SystemInternals, then you can see the process tree.

In ProcessExplorer, click the target-sight button, and then click on the cmd prompt that you launched the webrowser from. ProcessExplorer will then jump to that cmd prompt in its list. If the process view is not already threaded by parent-child relation, then press Ctrl-T a few times until it is. You then should be able to see the webserver. Select it, and then right-click on it. Select "Kill Process Tree" to forcibly kill the webserver.

SystemInternals also has pskill. You can use pskill -t "MyWebServer" to kill all processes, and their children, than are called MyWebServer.

CSM
  • 1,164
  • 8
  • 8
0

In a single command:

kill -INT $(lsof -t -i :8080)

Or more generally:

kill -INT $(lsof -t -i :PORT_NUMBER)

Additional Notes:

$() is called "Command Substitution"

Jon Ide
  • 11
-4

Unless the process you're trying to kill is one that gets started upon booting the server, rebooting the computer in question would probably work. It's probably a last resort option due to losing everything else the computer's been doing that hasn't been saved, and the time it takes for the reboot to occur, but there's a reason why a lot of IT professionals start their troubleshooting process for user machines with "Have you tried turning the computer off and back on again?"

nick012000
  • 117
  • 2
  • 2
    Not sure why I'm being downvoted. "Reboot the computer" is a valid solution for the problem asked by the OP. – nick012000 Mar 06 '19 at 02:40
  • 5
    Not my downvote, but this solution is a vast overkill. "Turn it off and on again" is mostly useful when you are debugging somebody else's problem and don't care about their inconvenience. – Stig Hemmer Mar 06 '19 at 09:46
  • (not my down) It is clearly not a user-level problem. Maybe a super-superuser level problem. – peterh Mar 06 '19 at 16:39