You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I need to intercept SIGTERM signals sent to the service, because I need to perform some cleanup and interruptions (especially setting threading.Event() flags)
However, the issue is that, when I type systemctl stop myservice, the service hangs for 30 seconds before shutting down (which is probably gunicorn's graceful_timeout setting), instead of shutting down immediately, as I intend to.
When looking in the source code of gunicorn, I notice that the Worker class uses a signal handler to shutdown itself gracefully:
My guess is that, since it is possible to use only one handler for each signal, I am overriding this handler by using my own handler.
But I still need both handlers, mine for my cleanup operations to be done and the default one for the gunicorn worker to stop properly.
Something maybe worth to mention is that, when I run run.sh in my shell and send SIGINT to it (by pressing Ctrl+C), my app stopped immediately, despite gunicorn also implements an handler for it.
Any ideas on how I should proceed? I thought about calling the function handle_exit in my own handler, but since my code is "gunicorn-agnostic", I have no idea about how I should do that. Should I change the design of my app?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have a Python Flask app:
This app is ran by gunicorn, using a classic
wsgi.py
file and a systemd service:The content of
run.sh
:I need to intercept SIGTERM signals sent to the service, because I need to perform some cleanup and interruptions (especially setting
threading.Event()
flags)However, the issue is that, when I type
systemctl stop myservice
, the service hangs for 30 seconds before shutting down (which is probably gunicorn'sgraceful_timeout
setting), instead of shutting down immediately, as I intend to.When looking in the source code of gunicorn, I notice that the Worker class uses a signal handler to shutdown itself gracefully:
My guess is that, since it is possible to use only one handler for each signal, I am overriding this handler by using my own handler.
But I still need both handlers, mine for my cleanup operations to be done and the default one for the gunicorn worker to stop properly.
Something maybe worth to mention is that, when I run
run.sh
in my shell and send SIGINT to it (by pressing Ctrl+C), my app stopped immediately, despite gunicorn also implements an handler for it.Any ideas on how I should proceed? I thought about calling the function
handle_exit
in my own handler, but since my code is "gunicorn-agnostic", I have no idea about how I should do that. Should I change the design of my app?Beta Was this translation helpful? Give feedback.
All reactions