In T175860, I discovered that the signal() timeout mechanism breaks the Celery service on a local VM, by running out of memory. Once we can give separate Celery revocation and alarm timeouts, we can test by shortening and exceeding the alarm timeout. It probably is correct to kill and fork the uwsgi, but doing so should cost net zero memory change, with the kill made before the fork. But short of this ideal, we don't want an OOM to damage the pool or the OS. Avoid damage if possible. Have the pool auto-degrade to a smaller number of workers. Log accurately.