Azure App Service Linux: Can a stopped container resume writing to shared /home storage?

Question

Azure App Service Linux: Can a stopped container resume writing to shared /home storage?

Andy Pullen 0

We operate a Node.js application on Azure App Service for Linux (Basic B1), using persistent /home storage.

The application uses an exclusive directory-based writer lock to prevent two processes modifying the same files.

Following an unexpected container shutdown, the old lock remained on disk. The replacement container correctly refused to start because it could not establish whether the previous writer was still active.

We would like clarification on Azure App Service's container lifecycle guarantees.

Our specific questions are:

When an App Service is stopped and Azure reports that the Stop operation has completed, is it guaranteed that every previous application container and process has terminated and can no longer write to the persistent /home storage?

Could an earlier container ever resume writing after the Stop operation has completed, including following overlapping restarts, platform maintenance or delayed termination?

Is there a Microsoft-supported mechanism for definitively terminating or fencing previous application instances before allowing a replacement to acquire exclusive writer ownership?

We are not asking for application troubleshooting or advice to delete stale locks. We are trying to establish whether Azure provides an authoritative guarantee that would make controlled recovery safe.

References to official documentation describing these guarantees or limitations would be particularly helpful.

Thank you.

0 comments

1 answer

Your answer

Answer 1

Azure App Service does not document the completed Stop operation as an authoritative storage fence, so it should not be used as proof that a replacement has exclusive writer ownership of persistent /home.

What Microsoft documents

The App Service status contract defines Stopped only as “the app isn’t running.” It does not state that Stop completion provides a fencing token, invalidates previous storage clients, or establishes exclusive access to /home. ^1^
With persistent storage enabled, /home survives restarts and is shared by all scaled-out instances. Therefore, a directory left there is durable shared state, not evidence that its creator is still alive—or that it cannot overlap another process during lifecycle transitions. ^2^
App Service explicitly uses overlapping restarts in several situations:
- During a file-server update, the new worker process starts first; after it responds, existing requests receive 30 seconds by default in the old process before that process is stopped.
- During a worker update, the app starts on the new worker, traffic moves, existing requests complete on the old worker, and only then is the old worker removed.
- Similar replacement behavior can occur during recovery from unexpected worker or file-server failures. ^3^
Proactive Auto-Heal can also perform an overlapping restart. ^4^

Consequently, even on a single-instance B1 plan, there can temporarily be an old and new process during replacement. “Single instance” describes plan capacity; it is not a documented single-writer guarantee during platform transitions.

Answers to the three questions

Does completed Stop guarantee that every previous process can no longer write to /home?
The public App Service documentation does not provide that guarantee. It says the app is no longer running, but does not define Stop completion as a storage-level fence. Treat it as an administrative runtime state, not as a distributed-lock primitive.
Could an earlier container resume writing after Stop completion?
No cited Microsoft document says that a container reported as stopped can later resume execution without being started again. However, the documentation also does not provide the stronger guarantee needed here: that completion of Stop irrevocably fences every prior storage client or generation. Maintenance and recovery can overlap old and new processes before termination completes, so recovery logic must tolerate concurrent generations rather than infer safety from observed lifecycle state.
Is there a Microsoft-supported App Service operation that definitively fences old instances?
No App Service fencing primitive is documented. Restart, Stop, Health Check, Auto-Heal, and worker replacement manage execution or traffic; they do not issue a writer epoch or enforce ownership on /home.

WEBSITES_CONTAINER_STOP_TIME_LIMIT is also not such a mechanism. It controls how long App Service waits for a custom container to terminate gracefully—default 5 seconds, maximum 120 seconds—but does not establish storage fencing or prove that a lock was released. ^4^

Supported design for authoritative ownership

Use an external coordination system that enforces ownership independently of container lifecycle. Azure Blob Storage supports finite-duration leases of 15–60 seconds; leases can be renewed, expire automatically, and cause writes to the leased blob without the lease ID to fail with HTTP 412. ^5^

Important limitation: a blob lease protects operations on the leased blob. It does not automatically fence arbitrary writes to files under /home. For true protection, the storage mutation path must validate the current lease or a monotonically increasing fencing token; otherwise, a paused old writer could continue writing /home after a newer writer acquires logical ownership.

If a contractual statement specifically covering “Stop completed means all previous /home writers are irreversibly fenced” is required, open an Azure support request for App Service. The public contract supplied by the documentation is insufficient to make that assertion safely.

References