Logging with Gunicorn and use_queues

[GrahamMThomas]

Not sure if this is a bug in a package. I'm just writing this to help the next poor soul who comes along and tries to get this to work.

Maybe it's obvious to others, use_queues has to spawn a thread to manage a queue. Gunicorn spawns threads to handle api requests. The use_queues thread is unable to listen to the Gunicorn threads... I think...

Therefore use_queues must be disabled in order to get access logs from gunicorn.

[jasondarnell]

I am the "next poor soul". Thank you for noting this.

[ibuys]

Possibly related, I ran into an issue today during deployment of a Django application that relies on Gunicorn, using watchtower==0.8.0 caused Gunicorn to crash on launch, downgrading to watchtower==0.7.3 and the problem went away and Gunicorn started normally.

[colinhowe]

This just saved my bacon too. For future searchers: .../watchtower/__init__.py:200: WatchtowerWarning: Received message after logging system shutdown is the error that pops up.

Would be good to not have to turn off queues

Edit to add: I switched my logging from being configured in gunicorn to being configured in Django and it worked. I had to coax gunicorn into not skipping access logging with this travesty: logconfig_dict = {'dummyvalue': True}

[luisjimenez6245]

Im running to WatchtowerWarning: Received message after logging system shutdown when running the watchtower with FastAPI, The solutions was to disable queues. but is there a way to fix this issue?

[kislyuk]

I am unable to reproduce this issue. When I run my wsgi application with gunicorn, I am able to log messages successfully. It's possible that logging messages in certain contexts causes a deadlock, but I would need specific information on how to reproduce that in order to act on it.

Setting use_queues to False in production is not recommended, since it will cause performance issues due to the synchronous sending of one CloudWatch API request per log message.

[DilLip-Chowdary-Codes]

Setting use_queues to False in production is not recommended, since it will cause performance issues due to the synchronous sending of one CloudWatch API request per log message.

Got the same issue, any solutions for this?

[Insighttful]

Same issue. Using Uvicorn 0.24 and FastAPI 0.105.

[bluemarbleconsulting]

Also seeing this issue with FastAPI 0.115.6 and uvicorn 0.34.0. FastAPI starts, the WatchtowerWarning is thrown, and then it seems the thread dies entirely causing any future logs to not be sent.