Uvicorn in Windows kills subprocesses on reload

[sid-38]

Uvicorn server with reload=True, would send a Ctrl+C event to other subprocesses when reloading.

# main.py
import subprocess
import uvicorn

if __name__== '__main__':
    process = subprocess.Popen(["python", "frontend.py"], shell=True)

    print("Starting uvicorn")
    uvicorn.run(
        app="uvicorn_main:app",
        port=5000,
        log_level="debug",
        reload=True
    )

# frontend.py
if __name__ == "__main__":
    while True:
        print("frontend")

# uvicorn_main.py
async def app(scope, receive, send):
    assert scope['type'] == 'http'

    await send({
        'type': 'http.response.start',
        'status': 200,
        'headers': [
            [b'content-type', b'text/plain'],
        ],
    })
    await send({
        'type': 'http.response.body',
        'body': b'Hello, world!',
    })

On making changes to the uvicorn_main.py file, uvicorn reloads and the frontend loop ends.

Uvicorn version - 0.29.0
Watchfiles version - 0.21.0
Python version - 3.12.2
OS - Windows 11 Home

[sid-38]

I believe, the reason for this could be that on reload, uvicorn does a os.kill(pid, signal.CTRL_C_EVENT) and if the pid is that of an individual process instead of a process group it leads to the CTRL+C signal being sent to everything under the terminal.

It's a bug that's been reported in the following links:

1. https://bugs.python.org/issue42962
2. GenerateConsoleCtrlEvent should not succeed when dwProcessGroupId is not a group ID microsoft/terminal#335

[Kludex]

Does this happen with uvicorn 0.28.0?

[sid-38]

Yes, it does in my tests. I believe the issue affects versions from 0.22.0. If this indeed is confirmed to be an issue, I'd love to work on it

[ixxie]

@sid-38 @Kludex have there been any updates relating to this? We are running our various dev servers under a unified internal CLI, and this issue prevents us from being able to use Uvicorn's reload feature, since it kills everything when it triggers.

[toni-neurosc]

@ixxie I have been suffering this issue as well and apparently is not uvicorn's fault, it's more related to the way Python implements os.kill together with the Windows API itself, there's a discussion in this thread https://discuss.python.org/t/terminateprocess-via-os-kill-on-windows/30882/5

i have tried the _winapi.OpenProcess approach mentioned in the last comment but it did not work for me, perhaps i did something wrong, could you give it a go?

[ixxie]

Thank you @toni-neurosc for pointing me in the right direction. I'm going to give it a go an see what I can make of it.

[toni-neurosc]

Hi @ixxie, was the workaround useful or did you find some other way to circumvent the issue?

[ixxie]

@toni-neurosc I couldn't make sense of how to apply the workaround for my usecase, when I'm leveraging subprocess.run to launch subprocesses. I wrote a comment on that thread asking the author for clarifications.

[ixxie]

@toni-neurosc I did come up with a potential workaround: using WSL. In our case, its more trouble than its worth, but maybe it can help you out in your usecase?

[ixxie]

@toni-neurosc we ended up spawning the uvicorn process a new Windows Terminal tab. I'm not sure this helps in your usecase, but I thought I would share anyway:

import base64

def construct_command():
        # you often want to pass env vars
        def pass_envvar(var):
            value = os.environ.get(var)
            return f"[Environment]::SetEnvironmentVariable('{var}', '{value}')" if value else None
        pass_envvars = " && ".join([
            envvar for envvar in
            map(pass_envvar, [
                'FOO',
                'BAR',
            ]) if envvar
        ])
        cmd = f"cd ./backend && {pass_envvars} && poetry run backend"
        # complex commands are best encoded to avoid needing escape chars
        base64_cmd = base64.b64encode(bytearray(cmd, 'utf-16-le')).decode()
        # open a new tab in the current windows terminal and run
        return f'"wt --window 0 pwsh -noExit -EncodedCommand {base64_cmd}"'

You should then be able to pass this to subprocess and it will launch the server in a new tab. Not as nice as have it multiplexed in the same window, but our team deemed WSL to much hassle for a relatively minor devex comfort.

[ixxie]

@Kludex I understand if this is too much of an edge case to address directly in the codebase; but I think it would be fair to document this limitation and maybe even link to the relevant discussions. Ideally, maybe some workaround could be suggested also, using third-party tools. Would you be open to me creating an issue along these lines? Eventually, I'm happy to open a pull request to the docs, but I thought an issue would be appropriate first.