Update: Instead of this post, check out this StackOverflow answer that gives a much better and convenient method of doing this by using gid (group id). It puts my method to shame
Update: For Windows, run netstat -a -n -o|findstr 8080 (or any port) in CMD, run taskkill /pid 20212 /f with that PID in place of 20212 (or show PID column in Processes tab in Task Manager, find the PID in the first command output and kill it. Kinda messy, but works.)
I had a VM hosting and running a codebase through NodeJS.
I was accessing the code through ssh in VSCode, while the code ran through a custom script inside the VM itself. It was exposed through ssh port forwarding, but that irrelevant for this story.
So, when I was switching branches, the server script tended to get frozen. I wanted to kill it and its descendants while not hurting the node processes of the VSCode server in the same VM. So I couldn't just run killall node.
To get an overall idea about the process state, I first listed down the processes with pstree | grep node. There, I could see which node processes spawned which, but without any pids.
So I ran ps aux | grep node, which gave me all the node processes with pid and other stats like memory. But it still contained VSCode server processes. So I excluded any line containing vscode: ps aux | grep node | grep -v vscode.
Voila!
Now I had the pids of each unwanted node process, but I couldn't tell which column was the pid! So I ran ps aux | head to find which column it was.
Then I killed all of them with:
kill -15 2189 2240 # ...
Here, 2189, 2240, ... are the list of pids. -15 modifier means SIGTERM.
After testing again with ps aux | grep node | grep -v vscode, I saw some processes were too frozen to respond to SIGTERM, which meant I then run kill with -9 (SIGKILL) instead of -15.
So, that's all!
Top comments (0)