Closed aarontp closed 5 months ago
@aarontp removing '--pool=solo' from worker.py:253 should enable time limits and avoid the blocking issues we were experiencing.
@aarontp removing '--pool=solo' from worker.py:253 should enable time limits and avoid the blocking issues we were experiencing.
Indeed, that worked, thanks!
PTAL, I added the soft limit exception to the execute()
method as well.
Description of the change
SINGLE_RUN
feature and config option.'--pool=solo
to--concurrency=1
as a solo pool executes tasks directly instead of forking and cannot process celery timeouts.After this change there will be four different timeouts that can occur:
TurbiniaTask.execute()
and uses the timeout values set in the Job config in the turbinia config file.celery.exceptions.SoftTimeLimitExceeded
exception to the worker and should be caught in theTurbiniaTask.execute()
orTurbiniaTask.run_wrapper()
methods depending on the state of the Task. This is set slightly longer than the Turbinia workout timeout to allow the worker to clean-up and give results when possible. The buffer is defined bytask_manager.CELERY_SOFT_TIMEOUT_BUFFER
.task_manager.CELERY_HARD_TIMEOUT_BUFFER
), celery is configured to kill the worker running the task. This is not catchable so we will not get any results back from the worker so the server will also need to time out the task.task_manager.SERVER_TASK_TIMEOUT_BUFFER
seconds after the Task timeout. This buffer is large because the timer starts from when the task is enqueued and can't account for any scheduling and other wait time. This is to avoid timing out valid tasks due to worker congestion.Applicable issues
Additional information
Checklist