Azure App Services - 502 timeout error caused by gunicorn timeout when app not used in a while

Question

I'm getting a 502 error when I haven't used my app deployed on Azure App services in half and hour or so, and when I check the logs I'm pretty sure that the 502 is caused by that one of the gunicorn workers shut down due to a time-out error.

According to the following thread:

https://stackoverflow.com/questions/10855197/gunicorn-worker-timeout-error

this is said to be caused by a too low timeout limit for the workers, so I've tried setting it to both 120 and 600 as adviced by Microsofts own tutorial on deploying Flask to app services:

https://learn.microsoft.com/en-us/azure/app-service/configure-language-python#flask-app

But the problem still persist.

I have gone to the gunicorn readme where this issue is mentioned, however I can't execute the commands when going into the app service with SSH as I don't seem to have permissions (even though I'm logged in as root when accessing the instance trough the web SSH in the portal).

https://docs.gunicorn.org/en/stable/faq.html#why-are-workers-silently-killed

This is my gunicorn.py (config file)

"""gunicorn WSGI server configuration."""  
from multiprocessing import cpu_count  
from os import environ  
  
def max_workers():      
    return cpu_count()  
  
bind = '0.0.0.0:' + environ.get('PORT', '80')  
max_requests = 1000  
  
workers = max_workers()  
  
# Reference in setting timeout to 600 for Flask applications deployed on Azure App Services  
# https://learn.microsoft.com/en-us/azure/app-service/configure-language-python#flask-app  
timeout = 600  
  
loglevel = 'debug'  

I'm not using NGINX right now as I was hoping to instead use the App-service built in load balancer, don't know if that is what is causing the problems. The app I'm deploying is a Django application if that makes any difference.

This is how the error looks like in the logstream when the worker exit

2021-12-16T12:31:28.764615128Z [2021-12-16 12:31:28 +0000] [21] [INFO] Starting gunicorn 20.1.0  
2021-12-16T12:31:28.764631529Z [2021-12-16 12:31:28 +0000] [21] [INFO] Listening at: http://0.0.0.0:80 (21)  
2021-12-16T12:31:28.764636529Z [2021-12-16 12:31:28 +0000] [21] [INFO] Using worker: sync  
2021-12-16T12:31:28.906339787Z [2021-12-16 12:31:28 +0000] [23] [INFO] Booting worker with pid: 23  
2021-12-16T12:41:27.605235533Z [2021-12-16 12:41:27 +0000] [21] [CRITICAL] WORKER TIMEOUT (pid:23)  
2021-12-16T12:41:27.605265633Z [2021-12-16 13:41:27 +0100] [23] [INFO] Worker exiting (pid: 23)  
2021-12-16T12:41:28.602336871Z [2021-12-16 12:41:28 +0000] [21] [WARNING] Worker with pid 23 was terminated due to signal 9  
2021-12-16T12:41:28.629741440Z [2021-12-16 12:41:28 +0000] [24] [INFO] Booting worker with pid: 24  

Answer 1

So I am going to add this here because I recently went through this myself. Turns out we had forgotten to allow our database to be accessed by other Azure services.