Docker Name Conflict Investigation

Problem

Coverity runner failed with:

Conflict. The container name
"/coverity_2024.9.0_0.20.0__as_volume"
is already in use by container
"6ad6f773349bd9..."

Initial assumption: a stale Docker container already existed.

---

Attempt 1 — Remove Container

docker rm -f coverity_2024.9.0_0.20.0__as_volume

Result:

No such container

Unexpected because Docker previously reported the container existed.

---

Attempt 2 — Inspect Container by ID

docker inspect 6ad6f773349bd9...

Result:

[]
error: no such object

Container ID from error message could not be found.

---

Attempt 3 — Search Containers

Search by name:

docker ps -a --filter name=coverity

Result:

(no output)

Search full container list:

docker ps -a --no-trunc | grep -i cover

Result:

(no output)

No Coverity-related containers visible.

---

Attempt 4 — Verify Docker Context

Current context:

docker context show

Result:

default

Check Docker overrides:

echo $DOCKER_HOST
env | grep -E 'DOCKER|CONTAINER|COVERITY'

Result:

(empty)

Check daemon information:

docker info | grep -E "Name:|Docker Root Dir"

Result:

Name: HC1SVECM1
Docker Root Dir: /mt/sdd1/docker_data

Shell appears to use the default Docker daemon.

---

Hypotheses

1. Typo in Container Name

Rejected.

Name was copied directly from Coverity output.

2. Hidden Container Exists

Rejected.

Neither docker ps -a nor docker inspect could find it.

3. Missing sudo Privileges

Possible.

Corporate server does not grant sudo.

Coverity runner may run with permissions different from the interactive user.

Could not verify.

4. Different Docker Environment

Possible.

Coverity runner may:

• use a wrapper script
• run as another user
• connect to a different Docker daemon
• use a remote Docker endpoint

while the shell uses:

default context
HC1SVECM1 daemon

5. Concurrent Coverity Jobs

Strong candidate.

Possible sequence:

1. Job A creates container.
2. Job B starts and gets name conflict.
3. Job A exits and removes container.
4. User inspects Docker and finds nothing.

Would explain why:

• conflict occurred
• container cannot be found afterward

---

Suggested Follow-up Checks

List running Coverity processes:

ps -ef | grep -i coverity

Monitor Docker while rerunning Coverity:

watch -n 0.2 'docker ps -a --no-trunc | grep -i cover || true'

Inspect Docker events:

docker events --since 10m --filter type=container

Review Coverity runner implementation for:

• Docker host overrides
• fixed container naming
• remote Docker usage

---

Conclusion

Most likely explanations:

1. Coverity runner is not using the same Docker environment as the shell.
2. Multiple Coverity jobs are competing for the same fixed container name.

Evidence does not support the existence of a removable container visible from the current Docker session.