-
-
Notifications
You must be signed in to change notification settings - Fork 390
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs: Add example for gunicorn
with uvicorn
workers
#2876
Comments
gunicorn
with uvicorn
workers
This relates to #2609, partially |
We were specifically talking about logging with gunicorn workers - great to have a full example, but just want to make sure that the logging topic doesn't get lost. |
Thinking about this, I'm not sure if this is actually Litestar specific? The logging setup of gunicorn with uvicorn workers will be exactly the same as for any other ASGI apps. Maybe we don't need to re-invent the wheel here and could just link to existing documentation? |
Tried doing it the same way as I did it with FastAPI, but any stray exceptions aren't being logged out. |
Litestar's logging behaviour of exception is different than FastAPI's, but this is independent of the server being used. Exceptions aren't logged by default if you're not in debug mode. You can configure this by setting |
It still doesn't log anything out. class TranscribeController(Controller):
path = '/transcribe'
@post()
async def transcribe(self, data: Annotated[UploadFile, Body(media_type=RequestEncodingType.MULTI_PART)]) -> bytes:
content = await data.read()
raise Exception(content)
return content
def initialise() -> Litestar:
return Litestar(
logging_config=LoggingConfig(log_exceptions='always'),
route_handlers=[TranscribeController],
) It works fine on Uvicorn though, but with Gunicorn, it disappears. |
How are you running gunicorn? I tested it and it works just fine. In any case, as I mentioned before, this isn't unique to Litestar. It has to do with how gunicorn handles logging. See for example this issue which describes the same behaviour you're experiencing, but with FastAPI. |
I am well familiar with that issue and I have worked around it and still managed to get my exceptions printed. # gunicorn.conf.py
from server import initialise
from server.config import Config
wsgi_app = f'{initialise.__module__}:{initialise.__name__}()'
reload = False
preload_app = True
bind = f'0.0.0.0:{Config.server_port}'
workers = Config.worker_count
worker_class = 'uvicorn.workers.UvicornWorker'
timeout = 300 |
That's your config but how are you running it? Is it perhaps inside a container (the bind to |
Nope, it's not containerised. Running it in a poetry venv with |
What platform are you on? |
I don't know why but it seems to be the I've found this issue which seems to describe this exact behaviour, but apparently it has been fixed since. |
I have tested on my personal Windows laptop and within a Linux VPS. I'll try disabling |
Yeah, I have confirmed that it is indeed |
not familiar with the issue - just interjecting here quickly - but with the advent of process management in Uvicorn, it may help your particular situation? (to swap from Gunicorn) |
This seems odd. I'm still not 100% convinced this is a bug on our end, but would you mind opening a separate issue for this? It's not really a documentation thing in any case, because this should work |
Add documentation examples for gunicorn w/ uvicorn workers. See the X post below for a user asking a question on this topic.
Ref:
Note
While we are open for sponsoring on GitHub Sponsors and
OpenCollective, we also utilize Polar.sh to engage in pledge-based sponsorship.
Check out all issues funded or available for funding on our Polar.sh dashboard
The text was updated successfully, but these errors were encountered: