CTRL+C, signals sometimes not handled

[jules-ch]

When developping locally, I encounter most of the time when trying to kill the server, the server is not shutting down, my terminal just hangs.

I'm not encountering this with uvicorn hence my question. Is this because of the 2 loops rust and python ?

Also when killing the worker straight away, logger says "Shutting down worker" but startup continue normally, I'll file a bug for this one.

[gi0baro]

When developping locally, I encounter most of the time when trying to kill the server, the server is not shutting down, my terminal just hangs.

I'm not encountering this with uvicorn hence my question. Is this because of the 2 loops rust and python ?

I highly doubt that's the reason.
Any additional context you can provide? Sounds like Granian is waiting for connections to close on the client side. Are you using Server-Sent Events? Websockets? Which application protocol is this? ASGI? Can you provide which framework you're using?

Also when killing the worker straight away, logger says "Shutting down worker" but startup continue normally, I'll file a bug for this one.

I'm not sure I got this. Can you rephrase what's wrong?

[jules-ch]

I'll try to have a minimal example sorry. I have none on my hands.
Just wondering if other people encountered this.
The thing is it never happened on uvicorn.

I'm using a FastAPI app using the ASGI interface with uvloop, I have an application that uses the lifespan context manager to create multiple global clients (httpx, valkey, sqlalchemy async engine) and one websocket producer as an asyncio task to broadcast messages to WS clients.
Everything is teared down when the application is shut down.

I'll try to pinpoint what is the culprit but looks odd that signals are properly handled on uvicorn and not on granian for my case.

[jules-ch]

Ok I have more info.
I could not reproduce it on MacOS, only on linux.

even on a simple hello world app:

• If I stop the app after start up, worker is killed properly
• If I stop the app after making a request in the browser, worker hangs until I close the browser
• If I stop the app after making a request with curl, worker is killed properly.

I tried disabling keep-alive, but it does not seem to resolve the problem.
I'll make a video of this later.

[jules-ch]

Hey @gi0baro That's what I thought too, but the --no-http1-keep-alive is not resolving the problem.

Here is the basic ASGI app I'm using with granian command:

granian app:app --interface=asgi --loop=asyncio --http=1 --no-http1-keep-alive

import logging

from fastapi import FastAPI

app = FastAPI()


logger = logging.getLogger(__name__)


@app.get("/")
async def root():
    logger.info("hello")
    print("hello")
    return {"message": "Hello World"}

Screencast.from.2025-06-15.21-22-54.webm

Thanks for your time on this lib and answering discussions, I'll use the worker-kill-timeout in the meantime in local.

Just for my curiosity, this part (http1 persistent connections) is handled with hyper right ?

[gi0baro]

That's what I thought too, but the --no-http1-keep-alive is not resolving the problem.

@jules-ch tested locally with ASGI apps in Granian's repo tests and benchmarks, and disabling keep alive works also for that.
I'm not sure if FastAPI is trying to do something on shutdown that prevents the worker to successfully shutdown, but it seems so.

[jules-ch]

was it on linux ? macos seems to work fine. I'm gonna try on a simple bare ASGI app

[gi0baro]

was it on linux ? macos seems to work fine. I'm gonna try on a simple bare ASGI app

Yep, Linux

[jules-ch]

On a bare ASGI App I can not reproduce, this is probably related to starlette then and lifespan events.

Might be interesting to handle multiple SIGINT for graceful and forced shutdown for better dev experience. :)
I'll try to pin point and raise this upstream.