Azure Container Apps (ACA) revision swap: SIGTERM not delivered immediately on deprovision

Hello,

I’m posting an update with additional findings.

First, I’d like to correct my earlier statement about SIGTERM. I initially thought SIGTERM was not being delivered, but the real reason it looked that way was that Celery did not perform a warm shutdown.

We are running Celery with the prefork pool. In our container, there is one main process (PID 1) and two child worker processes.

After further investigation, we confirmed that SIGTERM should ideally be delivered only to the main process (PID 1), but in our case the platform sends SIGTERM to all child processes as well. Also, this SIGTERM was not propagated from the main process—it appears to be delivered directly by the platform to each child process.

Because the child processes are terminated by SIGTERM, we believe the main Celery process cannot complete a proper warm shutdown and errors occur (e.g., worker lost errors).

Could you help explain why SIGTERM is delivered to all processes (not just PID 1) in this environment?

For reference, this is the Korea Central region and Consumption profile

Thank you.

On the application side, Celery already handles SIGTERM properly for graceful (warm) shutdown, and we confirmed it works as expected in a typical Kubernetes environment.

However, in Azure Container Apps (ACA) Dedicated profile, when a revision starts being deprovisioned, the app stays in the Deprovisioning state for about 30 seconds, and SIGTERM is not delivered during this period.

That means no shutdown signal is observed by the app, so it continues to receive and process incoming tasks.

After those ~30 seconds, SIGTERM and container removal happen at the same time. If there are still running tasks, Celery attempts a warm shutdown at that point.

But by then, the ACA container is already gone when viewed from the Portal/CLI. The log stream may still connect, but it looks like the container’s network configuration has already been torn down—network communication no longer works.

As a result, even if we handle SIGTERM, the ACA container becomes unusable during this termination flow.

Could you please investigate/confirm whether this behavior is expected in ACA, and whether there is a supported way to ensure SIGTERM is delivered promptly (and traffic/tasks are drained) before the container/network is removed?

Hi @최 선호

Thank you for reaching out to Microsoft Q&A.

Apologies for the delayed response.

ACA does not implement Kubernetes style lifecycle hooks or PID 1 only signaling. Instead, it uses a “kill entire container” approach for simplicity and consistency across profiles.

When a revision is deactivated, ACA sends SIGTERM to all processes in the container to ensure the container stops promptly. This behavior is consistent whether child processes are forked, spawned, or placed in separate process groups.

Even if you use setsid or isolate process groups, ACA does not respect those boundaries it enumerates all PIDs in the container and signals them directly.

This design choice means frameworks like Celery prefork pool cannot rely on the master process to propagate signals because the children receive SIGTERM independently and exit before the master can coordinate a warm shutdown. Celery expects only the main process to receive SIGTERM and then gracefully stop workers. ACA breaks this assumption because child workers terminate immediately, causing WorkerLostError and incomplete task handling.

To avoid this, Try the steps outlined below:

Avoid Prefork Pool

Use --pool=solo or --pool=threads to keep everything in one process.

Configure Grace Period

Set terminationGracePeriodSeconds (up to 600s) in your ACA template:

JSON

"template": {
  "terminationGracePeriodSeconds": 60,
  "containers": [
    {
      "image": "<your-image>",
      "name": "celery-worker"
    }
  ]
}

Try to trap SIGTERM in Entrypoint

Implement a signal handler to stop accepting new tasks and exit cleanly.

Sample code in Python:

Python

import signal, sys
from celery import Celery
app = Celery('tasks')
def handle_sigterm(signum, frame):
    print("SIGTERM received, stopping consumers...")
    app.control.cancel_consumer()
    sys.exit(0)
signal.signal(signal.SIGTERM, handle_sigterm)

Design for Ephemeral Compute

Persist task state externally (e.g., Azure Service Bus).

Make tasks idempotent.

Keep tasks short so abrupt termination has minimal impact.