terminate tasks gracefully and not forcefully on closing VSCode or when using the "kill" (trashcan) button

[Mutantpenguin]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.87.0 (and all versions before I can remember)
• OS Version: Ubuntu 22.04.4

Steps to Reproduce:

I am not able to create a real minimal example, but will show my exact usecase here and try to explain it.

1. create a task with the command bench start from frappe bench (https://github.com/frappe/bench) and run it
   • this starts 3 redis servers, a node server, a yarn watcher and some other stuff
2. use the "kill" button for the task or close VSCode
3. bench start got terminated, but all the processes it itself spawned are still running
4. reopening VSCode and starting the task again will error out, because the still running redis servers are blocking some necessary ports
   • even if it would work, we would still have multiple resource hogging processes lingering in the background

Pressing CTRL-C instead in the tasks terminal gracefully shuts it down and bench start is able to do its proper teardown of all the spawned processes. I am not invested at all in bench so can't answer specific questions to it, but I know that it is using honcho and a Procfile to managing all these processes.

So I guess all I am asking for is a way for tasks to not be forcefully killed, but do the same as CTRL-C in the console would do to it.

This seems to describe that the same functionality already exists for launch.json: microsoft/vscode-js-debug#630 (comment)

[Mutantpenguin]

This issue here is similar to mine but only concerned about the kill button, and not closing VSCode.
#160740

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[fanmengmen]

I agree with this. I guess terminate task using SIGKILL which can't be trapped. I need execute some commands to clean the tmp files created by this task

[vscodenpa]

🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[Mutantpenguin]

Great, I am really glad that it reached the backlog!

If I may make a recommendation:

• I think the current way should stay as the default way to always be backwards compatible.
• What I and others want here should be an optional and explicit setting for a task.

[cjlryan]

This is especially useful for long running tasks - I've ran across it while creating a task that requires specific ports and runs a clean up process on SIGINT (eg: Firebase Emulator).

If I stopped the task by clicking trash icon, I found that the process had continued in the background, which meant the required ports were still in use and had to be killed individually using lsof -I :$PORT_NUMBER to identify the ID of the underlying Java process, then kill $PID. Doing that for 9 separate ports every time you need to restart the emulator is less than ideal. 😬

Totally agree with @Mutantpenguin - this should be an explicit setting defined on a task by task basis.

[tmeekins]

Please make an option for this to work with SIGBREAK. I need to terminate our build tools, which have SIGBREAK handlers (just like Ctrl-C in the command prompt) clean up the build and write out partially built data. It's been a PITA for me since Terminate just kills the process.

[lijie-lee]

Hi VSCode team. Is there any updates about this issue? I also met this issue in our VSCode extension.

[BenAldebert]

This has been an issue for me for the last few months using VS Code, not sure exactly what version it started, but after updating today it got even worse. I'm developing on Windows with NodeJS (Express backend, Angular frontend, running as tasks within VS Code), every time I close the window, close the workspace, kill tasks or restart running tasks it does not free the port (previous to today's update, this only occurred if I closed the window). If I gracefully kill the tasks within the terminal windows manually (Ctrl+C for my Express backend server, q+enter in the ng serve frontend server), everything works fine.

I've been blindly killing Node processes within Task Manager when this happens, but after today's update I got annoyed and wrote a little PowerShell script (and an accompanying VS Code task!) to automate this process. Hopefully this is resolved eventually, but until then here's the script/task I'm using:

PowerShell Script:

Param(
    [int] $PortNumber,

    [ValidateSet("TCP", "UDP", IgnoreCase = $true)]
    [string] $Protocol = "TCP"
)

$Protocol = $Protocol.ToUpper()

$processId = $null

if ($Protocol -eq "TCP") {
    try {
        $connections = Get-NetTCPConnection -LocalPort $PortNumber -ErrorAction SilentlyContinue
        if ($connections -is [System.Collections.IEnumerable]) {
            $processId = $connections[0].OwningProcess
        }
        else {
            $processId = $connections.OwningProcess
        }
    }
    catch {
        # Ignore error if no process is using the port
    }
}
elseif ($Protocol -eq "UDP") {
    try {
        $connections = Get-NetUDPEndpoint -LocalPort $PortNumber -ErrorAction SilentlyContinue
        if ($connections -is [System.Collections.IEnumerable]) {
            $processId = $connections[0].OwningProcess
        }
        else {
            $processId = $connections.OwningProcess
        }
    }
    catch {
        # Ignore error if no process is using the port
    }
}

if ($null -eq $processId) {
    Write-Host "No process is using $Protocol port $PortNumber"
    return
}

$process = Get-Process -Id $processId

Write-Host "Killing $($process.ProcessName) process (PID: ${processId}) using ${Protocol} port ${PortNumber}..."

taskkill /F /PID $processId

And then you can run this easily within VS Code by creating a task. This task assumes the above script is saved as Stop-ProcessUsingPort.ps1 saved in C:\temp, but you can adjust the properties as needed

{
    "version": "2.0.0",
    "tasks": [
    // Other tasks...
        {
            "label": "free-port",
            "detail": "Free up a port that is currently in use.",
            "type": "shell",
            "command": "./Stop-ProcessUsingPort.ps1 -Protocol ${input:protocol} -PortNumber ${input:portNumber}",
            "options": {
                "cwd": "C:\\temp"
            },
            "problemMatcher": [],
            "presentation": {
                "close": false
            },
            "icon": {
                "id": "debug-disconnect",
                "color": "terminal.ansiRed"
            }
        }
    ],
    "inputs": [
    // Other inputs...
        {
            "id": "protocol",
            "type": "pickString",
            "description": "Select the protocol the port is using",
            "default": "TCP",
            "options": [
               {
                    "value": "TCP",
                    "label": "Transmission Control Protocol"
                },
                {
                    "value": "UDP",
                    "label": "User Datagram Protocol"
                }
            ]
        },
        {
            "id": "portNumber",
            "type": "promptString",
            "description": "Enter the port number to free",
            "default": "3002"
        }
    ]
}

[meganrogge]

I'm thinking this opt-in setting should apply not only to tasks, but also terminals.