Azure Batch: Docker error: Conflict the Container name is already in use by container

Question

Azure Batch: Docker error: Conflict the Container name is already in use by container

Demeusy, Valentin 5

Hello,

When I submit long runnging tasks (~8hours) in Azure Batch I get an error after some time. At first, everything seems fine, the job is running normally, I see the logs in stdout.txt. After a while, the task is in failed state, the stdout has been cleared and the stderr indicates the following:

docker: Error response from daemon: Conflict. The container name "REDACTED" is already in use by container "50f2aa....e47f38c76672c1c09". You have to remove (or rename) that container to be able to reuse that name.

It looks like the task has tried to restart while it was still running but I don't know how it's possible.

I am using Batch Shipyard to submit the jobs. Pool is running Ubuntu 24 Node size: standard_d2_v3 I only use dedicated node. Autoscale is on with a simple task based formula (but I see the same error without the autoscale). Task is using docker image stored in Azure private repository.

Thank you for your help.

Sujitha Lakkireddy 5 Reputation points Microsoft External Staff Moderator

2026-07-01T08:53:19.06+00:00

Hello Demeusy, Valentin,

Thank you for reaching out on Microsoft Q&A forum.

Based on the error, this does not look like Azure Batch intentionally running the same task twice in parallel. It looks more like the container start path is being invoked again while a previous Docker container with the same generated name still exists on the node.

Docker container names must be unique, so if the previous container was not removed cleanly — for example due to a task retry, node reboot, Docker daemon restart, task interruption, or cleanup failure — the next attempt to start a container with the same name will fail with:

"Conflict. The container name is already in use..."

Please check the Batch task execution information first, especially retryCount, exitCode, failureInfo, previous attempt details, maxTaskRetryCount, and any maxWallClockTime configured for the task. Azure Batch can retry a task depending on the task retry settings, and retryCount should help confirm whether a new attempt was started.

On the affected node, before cleaning up anything, please also check the Docker state and Docker daemon logs around the failure time:

docker ps -a

docker inspect <container-id>

journalctl -u docker --since "10 hours ago"

Also check whether there were any node-level events around the same time, such as reboot, reimage, Docker/service restart, Batch agent issue, or node health issue.

Since you are using Batch Shipyard, it is worth checking whether Shipyard is generating deterministic/fixed container names for the task. If the task is retried and Shipyard attempts to reuse the same container name while the previous container still exists, this conflict can occur.

As a temporary workaround/test, you can disable or reduce task retries and check whether the issue still reproduces. You can also test removing any stale container before starting the task container, for example:

docker rm -f <container-name> || true

Alternatively, if supported by your Batch Shipyard configuration, use auto-remove behavior or unique container names per task attempt.

Most likely root cause: task retry/restart path + stale Docker container with the same name remaining on the node.

Regards,
Sujitha
Demeusy, Valentin 5 Reputation points

2026-07-03T08:43:23.86+00:00

This is just rephrasing the other answer from @Alex Burlachenko , you are not adding anything else.

1 answer

Your answer

Demeusy, Valentin 5 Reputation points

2026-07-03T08:43:23.86+00:00

This is just rephrasing the other answer from @Alex Burlachenko , you are not adding anything else.

Answer 1

Alex Burlachenko 25,030 MVP Volunteer Moderator

Demeusy, Valentin hi, thx for sharing urs issue here at Q&A portal,

Looks like Batch/Shipyard is trying to start the task container again, but Docker still has the old container with the same name on the node.

That usually happens when the task gets interrupted/retried, the node reboots, Docker daemon restarts, Batch thinks the task needs to start again, but the previous container wasn’t removed cleanly. Then Docker refuses bc container names must be unique.

Since it happens after some hours, I’d check task retry count, max wall clock time, node reboot events, Docker daemon logs, and Batch node events. If stdout gets cleared, that’s another clue the task attempt may have restarted, not just crashed inside ur code.

Quick thing: make sure the container is run with auto-remove behavior or unique container names per attempt if Batch Shipyard lets u set it. If the name is fixed per task, retries can collide with stale containers.

On an affected node, before cleanup, run

docker ps -a

docker inspect <container-id>

journalctl -u docker --since '10 hours ago'

Worth checking Batch task execution info too, esp retryCount, exitCode, failureInfo, and previous attempts https://learn.microsoft.com/en-us/azure/batch/batch-retry-task

Batch Shipyard may also be part of the story here, bc it generates/manages Docker names. If it uses deterministic names and the cleanup path fails, long-running retries can hit exactly this.

Workaround rn: disable/limit retries while testing, use unique task IDs/container names, or add a cleanup step that removes the old container before start:

docker rm -f <container-name> || true

Not beautiful, but it proves the stale-container theory fast.

My guess: task/node restart + stale Docker container, not Azure Batch randomly running the same task twice on purpose.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

Demeusy, Valentin 5 Reputation points

2026-06-26T17:27:20.52+00:00
Thanks for the answer.

The link you provided gives a 404 error.

Here is the things that I checked:

my container name is unique per task

the command line include "--rm" so docker should remove the container once done

no retry set on the task

no maximum wall time set on the task

I don't have to the node through ssh so I can't check the docker log, any way to enable them in the azure console ?

I don't have any "node reboot" event in the metrics

What event would cause the docker daemon to restart ?

Are there anything that can cause a node to restart without it being in the metrics ?

I was able to reproduce the same error with the following scenario:

submit a job and a task

let the task execution start

stop the task in the azure interface

submit the same task or retrying the same task.

But I fail to understand how can this happen when I don't retry/resubmit the task.
Alex Burlachenko 25,030 Reputation points MVP Volunteer Moderator

2026-07-03T14:49:37.5+00:00

thx for checking, and yes, u are right, my previous link was bad. My bad...
https://learn.microsoft.com/en-us/azure/batch/jobs-and-tasks

https://learn.microsoft.com/en-us/azure/batch/batch-task-output-files

https://batch-shipyard.readthedocs.io/en/latest/14-batch-shipyard-configuration-jobs/

Better reference is the general Batch jobs/tasks doc, where Microsoft describes task retry and max wall clock behavior. Given ur checks, I’d drop retry and max wall time as the main suspects. The repro with manual stop is actually the key part here. It shows that when the task is stopped from Azure UI, the Docker container can remain on the node. Then when the same task is submitted/retried, Shipyard/Docker tries to create a container name that already exists, so Docker returns the conflict.

--rm does not fully protect against this. It removes the container after a normal Docker exit, but if the task is terminated externally, or if Shipyard/node-agent cleanup does not finish, the old container can still be left behind.

Without SSH, I’d check/enable these from Azure side

Batch task execution info: exitCode, failureInfo, retryCount, previous attempts

Batch node state and scheduling error info

Pool resize/autoscale history

Azure Activity Log for pool/node resize, delete, reimage, reboot, or service actions

Service Health / Resource Health around the failure time

Persist task output files to Azure Storage, because stdout/stderr on the node can be overwritten or lost between attempts.... About Docker daemon restart sooooo it can happen because of VM reboot, image update, OS update, node reimage, host maintenance, Docker crash, or Batch or Shipyard setup scripts touching Docker. Not every case will look like a simple ‘node reboot’ metric, especially if the node was reimaged/recycled or the container runtime restarted inside the VM.

So I’d phrase the current theory like this -this does not look like Azure Batch intentionally running the same task twice. It looks like the original container is not being cleaned up after an interrupt/terminate path. Manual stop reproduces that exact stale-container condition. The remaining question is what is interrupting the 8-hour task in the real run.

I’d also test the same workload with native Azure Batch container tasks, without Batch Shipyard, if possible. Shipyard manages Docker itself, and stale Docker container cleanup is exactly the layer where this can happen.

rgds,

Alex