Multiprocess manager does not restart worker if there is only 1

[oalfred]

If I start uvicorn with just 1 worker, and set a limit for the maximum number of requests, then the application shuts down after that number of requests. If I instead use 2 workers, then the workers will be restarted after handling the specified number of requests.

I can tell from the logging that when I use 2 workers a parent process is started (INFO: Started parent process). I assume that this parent process is responsible for starting new workers and it does not run when using 1 worker. So in a sense I understand what is happening but I find it quite unintuitive. Is there some reason to not let a solitary worker be restarted?

---

main.py

from fastapi import FastAPI

app = FastAPI()


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

Start application with uvicorn --limit-max-requests 3 --workers 1 main:app, send three requests, curl localhost:8000, and the entire application shuts down.

Start with uvicorn --limit-max-requests 3 --workers 2 main:app instead, send 3 requests and only the worker that handled the requests will be shut down and a new one is started.

I'm using python 3.12.1, fastapi 0.111.0, and uvicorn 0.30.1.

[oalfred]

Is anyone able to shed some light on this? The FastAPI documentation suggests to use a single worker process when running in a container cluster, but this approach is incompatible with also using --limit-max-requests since the worker is not restarted after reaching the limit.

Is this a bug or is there some other way to accomplish this that I am missing?

[Gabriel2409]

I think your understanding is on point.

In the main run function, you have

  try:
      if config.should_reload:
          sock = config.bind_socket()
          ChangeReload(config, target=server.run, sockets=[sock]).run()
      elif config.workers > 1:
          sock = config.bind_socket()
          Multiprocess(config, target=server.run, sockets=[sock]).run()
      else:
          server.run()

You are in the case config.workers > 1

Now in Multiprocess, the run function repeatedly calls self.keep_subprocess_alive()

In this function, you can see that when a child process dies, another process is started.

    def keep_subprocess_alive(self) -> None:
        if self.should_exit.is_set():
            return  # parent process is exiting, no need to keep subprocess alive

        for idx, process in enumerate(self.processes):
            if process.is_alive():
                continue

            process.kill()  # process is hung, kill it
            process.join()

            if self.should_exit.is_set():
                return  # pragma: full coverage

            logger.info(f"Child process [{process.pid}] died")
            process = Process(self.config, self.target, self.sockets)
            process.start()
            self.processes[idx] = process

Now in the Server class, in on_tick, you have

if self.config.limit_max_requests is not None:
    return self.server_state.total_requests >= self.config.limit_max_requests

So from my understanding, the limit_max_requests is actually respected in the sense that it kills your child process when the nb of requests is exceeded. However, the implementation in Multiprocess is such that if a process is killed, another is created.

[oalfred]

Thank you for sharing your insights. Do you have any thoughts on why it is implemented this way? To me it is surprising and it seems inconsistent that if there are multiple workers and one is killed (due to a request limit or any other reason) then it is restarted, but if there is only one worker then it will not be restarted. I'm most certainly not an expert in ASGI servers so there may be good reasons for this implementation that I don't know of, but I would like to understand!

[oalfred]

I realise it may be bad etiquette to bump my own question, but this has become relevant for me again and the behavior is still the same with fastapi 0.120.3 and uvicorn 0.38.0.

It would be helpful for me to know if there is a workaround for this, or if it is a bug that could be fixed.

[nggit]

This seems to be by design. When using 1 worker, it means not using Uvicorn's process manager. And reloading will not work.

Edit: I thought the otherwise. I tought reload needs --workers > 1, or needs process manager.

The --reload and --workers arguments are mutually exclusive.

Probably 1 worker is meant for container systems, where they can restart it.

IMHO what I find strange in the Uvicorn options is:

--limit-max-requests INTEGER Maximum number of requests to service before
terminating the process.

That's more of a hindrance to me than a feature. You may be able to bypass this with a number greater than ulimit -n.

[oalfred]

Well, the --reload setting is for restarting the application when a file has changed, and while it would be nice if it worked together with --workers, that's not an issue for me at least.

I find --limit-max-requests useful for, e.g., mitigating memory leaks. There are other ways of course: I could use gunicorn as the process manager with uvicorn workers, or I could let a container system handle it in some way, but simply having uvicorn restart its own worker would be much simpler. I suppose I just can't see a reason why uvicorn would have it's own process management but not allowing it to be used with a single worker.

Anyway, thanks for chipping in on the discussion.

[nggit]

Hmm.. --limit-max-requests is not a suitable option for mitigating memory leaks.
Because it counts requests, not memory usage / worker's RSS. There can be many requests, even though memory usage is low.

What you want means 2 processes (1 process manager + 1 worker process). I prefer this too.
But Uvicorn adopts a single worker == truly 1 process.