# An error in docker: failed to create shim task
**URL:**
**Author:**  [@adibablu](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fadibablu)%5C
**Post date:** [May 16, 2026, 1:33pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fan-error-in-docker-failed-to-create-shim-task%2F176060%2F1 "2026-05-16T13:33:16Z")
When I try to run this command:
```auto
docker start e16fc114c32f
```
I get this error response from daemon:
```auto
failed to create task for container:
failed to create shim task:
OCI runtime create failed:
runc create failed: unable to start container process: unable to apply cgroup configuration:
unable to start unit "docker-e16fc114c32f6c9154ae3c2c0bb8ade6298ff61eaf61529b58bd2939eefd7f7c.scope" (properties [{Name:Description Value:
"libcontainer container e16fc114c32f6c9154ae3c2c0bb8ade6298ff61eaf61529b58bd2939eefd7f7c"} {Name:Slice Value:"system.slice"}
{Name:Delegate Value:true}
{Name:PIDs Value:@au [303179]}
{Name:MemoryAccounting Value:true}
{Name:CPUAccounting Value:true}
{Name:IOAccounting Value:true}
{Name:TasksAccounting Value:true}
{Name:DefaultDependencies Value:false}]):
Unit docker-e16fc114c32f6c9154ae3c2c0bb8ade6298ff61eaf61529b58bd2939eefd7f7c.scope was already loaded or has a fragment file.: unknown
```
There is no solution from Docker Chat/AI. I can delete the container and create it again, but after some time, I got the error again. Although it randomly can start normal, too.
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [May 17, 2026, 8:43am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fan-error-in-docker-failed-to-create-shim-task%2F176060%2F2 "2026-05-17T08:43:58Z")
I don’t use Docker locally, so I’m not very familiar with it, but could it be a leftover process from a previous runtime?
* * *
## Docker error: `failed to create shim task` / `docker-.scope was already loaded or has a fragment file`
When running:
```bash
docker start e16fc114c32f
```
Docker fails with:
```plaintext
failed to create task for container:
failed to create shim task:
OCI runtime create failed:
runc create failed: unable to start container process:
unable to apply cgroup configuration:
unable to start unit "docker-e16fc114c32f6c9154ae3c2c0bb8ade6298ff61eaf61529b58bd2939eefd7f7c.scope"
...
Unit docker-e16fc114c32f6c9154ae3c2c0bb8ade6298ff61eaf61529b58bd2939eefd7f7c.scope was already loaded or has a fragment file.
```
### Short diagnosis
This does **not** look like a normal Dockerfile or application-code problem.
The important part is not just:
```plaintext
failed to create shim task
```
That phrase is broad and can appear for many runtime failures.
The important part is this:
```plaintext
unable to apply cgroup configuration:
unable to start unit "docker-.scope"
Unit docker-.scope was already loaded or has a fragment file.
```
That points to a **host-side Docker/containerd/runc/systemd/cgroup problem**.
Most likely:
> A previous failed start, crash, OOM kill, restart loop, or runtime cleanup race left a stale or failed systemd scope unit for this exact container ID. When Docker tries to start the same container again, systemd refuses to create/start the same `docker-.scope` unit.
That also explains why deleting and recreating the container helps temporarily: the recreated container gets a **new full container ID** , so Docker uses a **new systemd scope name**. The old stuck unit name is avoided, but the underlying trigger may still exist.
* * *
## Background: what `docker-.scope` means
Docker containers are tracked and limited using Linux **cgroups**. On systems where Docker uses the **systemd cgroup driver** , Docker containers appear as systemd scope units such as:
```plaintext
system.slice/docker-.scope
```
Docker’s own runtime metrics documentation shows paths like:
```plaintext
/sys/fs/cgroup/system.slice/docker-.scope/
```
for cgroup v2 with the systemd driver:
- [Docker docs: Runtime metrics / cgroups / finding the cgroup for a container](https://docs.docker.com/engine/containers/runmetrics/)
The Docker daemon reference also explains that with systemd cgroups, cgroup parents are systemd slice names:
- [Docker docs: `dockerd` reference / cgroup parent and systemd slices](https://docs.docker.com/reference/cli/dockerd/)
Your error shows systemd properties such as:
```plaintext
Slice=system.slice
Delegate=true
MemoryAccounting=true
CPUAccounting=true
IOAccounting=true
TasksAccounting=true
DefaultDependencies=false
```
Those are not application-level settings. They are systemd/cgroup properties used while Docker/runc prepares the container’s resource-control scope.
`runc` also documents this systemd behavior. When using systemd cgroups, `runc` creates a transient systemd scope and sets properties such as `Delegate`, `Slice`, `CPUAccounting`, `MemoryAccounting`, `IOAccounting`, and `TasksAccounting`:
- [runc docs: systemd cgroup support](https://github.com/opencontainers/runc/blob/main/docs/systemd.md)
- [systemd docs: cgroup delegation](https://systemd.io/CGROUP_DELEGATION/)
So the failure path is approximately:
```plaintext
docker start e16fc114c32f
-> Docker daemon
-> containerd
-> containerd-shim
-> runc
-> systemd/cgroup setup
-> create/start docker-.scope
-> systemd says that unit is already loaded or has a fragment file
```
This means Docker fails **before the containerized application meaningfully starts**.
* * *
## Why this is probably not a Dockerfile problem
A Dockerfile or entrypoint problem usually looks like:
```plaintext
exec: "foo": executable file not found in $PATH
permission denied
no such file or directory
ModuleNotFoundError
address already in use
```
Your error is different:
```plaintext
unable to apply cgroup configuration
unable to start unit docker-.scope
```
That is lower-level. It happens while Docker/runc is setting up the host-side cgroup/systemd scope.
The application can still be an **indirect trigger** if it causes:
- OOM kills;
- fast crash loops;
- repeated restarts;
- too many child processes;
- excessive memory/thread usage;
- host resource exhaustion.
But the direct failure is systemd refusing the `docker-.scope` unit.
* * *
## Most likely causes, ranked
### 1. Stale or failed `docker-.scope` unit
This is the strongest hypothesis because the error literally says:
```plaintext
Unit docker-.scope was already loaded or has a fragment file.
```
That means systemd still knows about the unit name Docker is trying to create.
Possible states:
- the unit is failed;
- the unit is still loaded;
- a transient unit fragment still exists;
- systemd still has bookkeeping for the unit;
- cleanup after a previous failure did not complete;
- a PID is still associated with that scope.
There is a similar historical Docker/Moby issue where Docker failed with:
```plaintext
Unit docker-.scope already exists.
```
The issue involved a systemd cgroup scope getting left behind and preventing the container from starting:
- [Moby issue #7015: systemd cgroup scope left behind](https://github.com/moby/moby/issues/7015)
- [Moby issue #13802: systemd scopes leakage](https://github.com/moby/moby/issues/13802)
Those are old issues, so they are not proof of the exact same current bug. But they show that this failure mode exists: a Docker/systemd scope can be left behind and later collide with a new start of the same container ID.
* * *
### 2. OOM kill or memory pressure
This is the next thing I would check.
Docker’s resource-constraint documentation explains that when the Linux kernel detects an out-of-memory condition, it can kill container processes. Docker also warns against disabling the OOM killer without memory limits because the host itself can become unstable:
- [Docker docs: Resource constraints / memory / OOM behavior](https://docs.docker.com/engine/containers/resource_constraints/)
A very similar OCI-runtime case exists in `crun`/Podman. After a container hit OOM, a failed systemd `libpod-.scope` remained, and later starts failed with:
```plaintext
Unit libpod-.scope was already loaded or has a fragment file.
```
Relevant issue:
- [crun issue #1138: systemd libpod scope fails after container OOM exit](https://github.com/containers/crun/issues/1138)
- [crun issue #1092: triggering OOM leaves cgroups in bad state](https://github.com/containers/crun/issues/1092)
That is not Docker, but the mechanism is similar:
```plaintext
container runtime
-> systemd scope
-> OOM or hard kill
-> failed/stale scope remains
-> restart fails with "scope was already loaded or has a fragment file"
```
So even though your visible error mentions systemd, the original trigger may still be memory exhaustion.
* * *
### 3. Crash/restart loop
A restart loop can amplify this problem.
Example:
```plaintext
container starts
-> application exits immediately
-> Docker restart policy starts it again
-> application exits again
-> cleanup/start race eventually leaves scope state behind
```
Check for restart policies such as:
```plaintext
always
unless-stopped
on-failure
```
The old Moby stale-scope issue involved a container dying on startup while something restarted it repeatedly:
- [Moby issue #7015](https://github.com/moby/moby/issues/7015)
If your container has a high restart count, the stale scope may be a symptom of the repeated lifecycle churn.
* * *
### 4. systemd / D-Bus / cgroup runtime instability
The fact that it “randomly can start normal too” matters.
A deterministic Dockerfile problem usually fails consistently. Intermittent success suggests timing, cleanup, systemd, D-Bus, cgroup, or runtime state.
Similar reports exist where Docker failed at the same layer:
```plaintext
failed to create shim task
unable to apply cgroup configuration
unable to start unit "docker-...scope"
```
Examples:
- [GitLab Runner issue #36949: intermittent Docker `docker-*.scope` failure](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/36949)
- [Podman issue #24010: slice was already loaded or has a fragment file](https://github.com/containers/podman/issues/24010)
- [crun issue #1560: flaky slice was already loaded or has a fragment file](https://github.com/containers/crun/issues/1560)
These are not all Docker, but they support the same general pattern: rapid or repeated container lifecycle operations can expose systemd/cgroup unit-creation races.
* * *
### 5. Rootless Docker issue
Your pasted error says:
```plaintext
Slice Value:"system.slice"
```
That makes rootless Docker less likely. Rootless Docker more often involves `user.slice` paths.
Still, check it:
```bash
docker info | grep -i rootless
```
If rootless mode is enabled, use `systemctl --user` for some checks.
Docker rootless docs:
- [Docker docs: Rootless mode troubleshooting](https://docs.docker.com/engine/security/rootless/troubleshoot/)
- [Docker docs issue: rootless cgroup path differs from `system.slice`](https://github.com/docker/docker.github.io/issues/14545)
* * *
### 6. Old or mismatched Docker/containerd/runc/systemd/kernel versions
This stack has several moving parts:
```plaintext
Linux kernel
systemd
Docker daemon
containerd
containerd-shim
runc
cgroup v1/v2
```
Docker’s cgroup v2 documentation notes version requirements, including containerd v1.4+, runc v1.0.0-rc91+, and kernel v4.15+ with v5.2+ recommended:
- [Docker docs: Running Docker on cgroup v2](https://docs.docker.com/engine/containers/runmetrics/)
If Docker, containerd, runc, systemd, or the kernel are old or mixed from unusual package sources, update them through the OS-supported path.
* * *
## Immediate recovery
### Step 1: Get the full container ID and exact systemd unit
```bash
CID=e16fc114c32f
FULL_ID=$(docker inspect -f '{{.Id}}' "$CID")
UNIT="docker-${FULL_ID}.scope"
echo "CID=$CID"
echo "FULL_ID=$FULL_ID"
echo "UNIT=$UNIT"
```
Expected shape:
```plaintext
UNIT=docker-e16fc114c32f6c9154ae3c2c0bb8ade6298ff61eaf61529b58bd2939eefd7f7c.scope
```
That should match the unit in the error.
For a generic copy/paste version:
```bash
CID=
FULL_ID=$(docker inspect -f '{{.Id}}' "$CID")
UNIT="docker-${FULL_ID}.scope"
echo "CID=$CID"
echo "FULL_ID=$FULL_ID"
echo "UNIT=$UNIT"
```
* * *
### Step 2: Inspect Docker’s view of the container
```bash
docker inspect "$CID" \
--format 'Status={{.State.Status}} ExitCode={{.State.ExitCode}} OOMKilled={{.State.OOMKilled}} Error={{.State.Error}} Restarting={{.State.Restarting}} RestartCount={{.RestartCount}}'
```
Also check restart policy and memory settings:
```bash
docker inspect "$CID" \
--format 'RestartPolicy={{json .HostConfig.RestartPolicy}} Memory={{.HostConfig.Memory}} MemorySwap={{.HostConfig.MemorySwap}} OomKillDisable={{.HostConfig.OomKillDisable}}'
```
Interpretation:
| Output | Meaning |
| --- | --- |
| `OOMKilled=true` | Memory pressure is probably a root trigger. |
| `ExitCode=137` | Often SIGKILL; commonly OOM, though not always. |
| `RestartCount` high | Restart loop likely. |
| `Restarting=true` | Docker may already be retrying. |
| `Memory=0` | No hard memory limit configured. |
| `RestartPolicy={"Name":"always"...}` | Automatic restarts may amplify the issue. |
* * *
### Step 3: Inspect the systemd scope
```bash
sudo systemctl status "$UNIT" --no-pager --full || true
sudo systemctl show "$UNIT" \
-p Id -p LoadState -p ActiveState -p SubState -p FragmentPath -p ControlGroup \
--no-pager || true
sudo systemctl list-units --all --type=scope | grep "$FULL_ID" || true
sudo systemctl --failed | grep "$FULL_ID" || true
```
Look for:
| Observation | Likely meaning |
| --- | --- |
| `ActiveState=failed` | Failed stale scope; reset may help. |
| `LoadState=loaded` | systemd still knows the unit. |
| `FragmentPath=/run/systemd/...` | transient unit fragment may still exist. |
| `ActiveState=active` | some process may still be in that scope; do not kill blindly. |
| No unit appears, but Docker still fails | Docker/containerd may hold stale runtime state. |
Also inspect the PID shown in the original error:
```bash
ps -fp 303179 || true
cat /proc/303179/cgroup 2>/dev/null || true
sudo systemctl status 303179 --no-pager --full 2>/dev/null || true
```
* * *
### Step 4: Reset the failed scope
Try the least disruptive fix first:
```bash
sudo systemctl reset-failed "$UNIT"
sudo systemctl daemon-reload
docker start "$CID"
```
`systemctl reset-failed` resets the failed state of specified units and also resets some per-unit counters such as start-rate-limit counters and service restart counters:
- [systemctl manual: `reset-failed`](https://man7.org/linux/man-pages/man1/systemctl.1.html)
If this works, the immediate blocker was the failed/stale systemd scope.
Important: this does **not** prove the underlying cause is fixed. It only clears the stuck systemd state.
* * *
### Step 5: If reset alone does not work, stop the unit carefully
First inspect it:
```bash
sudo systemctl status "$UNIT" --no-pager --full || true
```
If it is clearly stale and not running useful container processes:
```bash
sudo systemctl stop "$UNIT" || true
sudo systemctl reset-failed "$UNIT"
sudo systemctl daemon-reload
docker start "$CID"
```
Do **not** start by manually deleting cgroup directories. Let systemd and Docker clean their own state first.
* * *
### Step 6: Restart containerd and Docker
If the targeted systemd reset does not work:
```bash
sudo systemctl restart containerd
sudo systemctl restart docker
docker start "$CID"
```
This can affect other running containers.
A more deliberate sequence:
```bash
sudo systemctl stop docker
sudo systemctl stop containerd
sudo systemctl daemon-reload
sudo systemctl reset-failed
sudo systemctl start containerd
sudo systemctl start docker
docker start "$CID"
```
Docker daemon logs on systemd hosts can be viewed with `journalctl`:
- [Docker docs: Read Docker daemon logs](https://docs.docker.com/engine/daemon/logs/)
```bash
sudo journalctl -u docker.service -u containerd.service -b --no-pager | tail -300
```
* * *
## Root-cause investigation
### 1. Check for OOM
```bash
docker inspect "$CID" \
--format 'OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}} Error={{.State.Error}} RestartCount={{.RestartCount}}'
```
Kernel logs:
```bash
sudo journalctl -k -b --no-pager \
| grep -i -E 'oom|out of memory|killed process|memory cgroup' || true
```
Previous boot:
```bash
sudo journalctl -k -b -1 --no-pager \
| grep -i -E 'oom|out of memory|killed process|memory cgroup' || true
```
If you see lines like:
```plaintext
Out of memory: Killed process ...
Memory cgroup out of memory
oom-kill
Killed process ... python
Killed process ... node
Killed process ... java
```
then the systemd scope failure may be a secondary symptom. The real trigger may be memory exhaustion.
If OOM is confirmed, use memory limits deliberately:
```bash
docker run \
--memory=8g \
--memory-reservation=6g \
--memory-swap=10g \
...
```
For Compose:
```yaml
services:
app:
image: :
mem_limit: 8g
memswap_limit: 10g
restart: unless-stopped
```
Be careful with `--memory-swap`; Docker documents non-obvious semantics for it:
- [Docker docs: `--memory` and `--memory-swap`](https://docs.docker.com/engine/containers/resource_constraints/)
Do **not** blindly use:
```bash
--oom-kill-disable
```
unless you also set a memory limit and understand the consequences. Docker warns that disabling the OOM killer without memory limits can destabilize the host.
* * *
### 2. Check for restart loops
```bash
docker inspect "$CID" \
--format 'RestartPolicy={{json .HostConfig.RestartPolicy}} RestartCount={{.RestartCount}}'
```
Logs:
```bash
docker logs --tail=300 "$CID"
```
If restart count is high, temporarily disable restart while debugging:
```bash
docker update --restart=no "$CID"
```
Then start manually:
```bash
docker start "$CID"
docker logs -f "$CID"
```
This separates two problems:
```plaintext
Problem A: the application crashes or OOMs.
Problem B: Docker/systemd cleanup gets stuck afterward.
```
Fix Problem A if it keeps triggering Problem B.
* * *
### 3. Test whether the problem is container-specific or host-wide
```bash
docker run --rm hello-world
docker run --rm alpine true
```
Interpretation:
| Result | Meaning |
| --- | --- |
| `hello-world` works, affected container fails | More likely stale scope tied to this container, app OOM, or app restart loop. |
| `hello-world` also fails with cgroup/scope error | More likely host-wide Docker/containerd/runc/systemd/cgroup issue. |
| `hello-world` sometimes works, sometimes fails | Intermittent runtime/systemd/D-Bus/cgroup instability. |
This is one of the fastest ways to avoid debugging the wrong layer.
* * *
### 4. Check runtime and OS versions
```bash
docker version
docker info
containerd --version
runc --version
systemctl --version
uname -a
cat /etc/os-release
cat /etc/docker/daemon.json 2>/dev/null || true
```
Pay attention to:
```plaintext
Cgroup Driver
Cgroup Version
Runtimes
Default Runtime
Rootless
Kernel Version
Operating System
Docker package source
```
If packages are old or mixed, update Docker/containerd/runc/systemd/kernel using the OS-supported method and reboot.
On Ubuntu/Debian with Docker’s official packages, this is commonly:
```bash
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo reboot
```
If using distro packages such as `docker.io`, mention that when reporting the issue, because Docker Engine, containerd, and runc versions may differ from Docker’s official packaging.
* * *
### 5. Check rootless Docker
```bash
docker info | grep -i rootless
```
If rootless mode is enabled:
```bash
systemctl --user status docker --no-pager || true
systemctl --user list-units --all --type=scope | grep docker || true
systemctl --user --failed | grep docker || true
```
For rootless Docker:
```bash
systemctl --user reset-failed 'docker-*.scope'
systemctl --user daemon-reload
systemctl --user restart docker
```
For normal rootful Docker:
```bash
sudo systemctl reset-failed 'docker-*.scope'
sudo systemctl daemon-reload
sudo systemctl restart containerd docker
```
* * *
## Why deleting/recreating the container helps temporarily
Deleting and recreating the container changes the full container ID.
Old container:
```plaintext
e16fc114c32f6c9154ae3c2c0bb8ade6298ff61eaf61529b58bd2939eefd7f7c
```
Old scope:
```plaintext
docker-e16fc114c32f6c9154ae3c2c0bb8ade6298ff61eaf61529b58bd2939eefd7f7c.scope
```
New container:
```plaintext
some-new-full-container-id
```
New scope:
```plaintext
docker-some-new-full-container-id.scope
```
So recreation avoids the stuck unit name.
But if the trigger is OOM, restart loop, runtime cleanup race, or host instability, the same class of failure can return later.
* * *
## My suggested command sequence
### A. Identify, inspect, reset
```bash
CID=e16fc114c32f
FULL_ID=$(docker inspect -f '{{.Id}}' "$CID")
UNIT="docker-${FULL_ID}.scope"
echo "$UNIT"
docker inspect "$CID" \
--format 'Status={{.State.Status}} ExitCode={{.State.ExitCode}} OOMKilled={{.State.OOMKilled}} Error={{.State.Error}} Restarting={{.State.Restarting}} RestartCount={{.RestartCount}}'
docker inspect "$CID" \
--format 'RestartPolicy={{json .HostConfig.RestartPolicy}} Memory={{.HostConfig.Memory}} MemorySwap={{.HostConfig.MemorySwap}} OomKillDisable={{.HostConfig.OomKillDisable}}'
sudo systemctl status "$UNIT" --no-pager --full || true
sudo systemctl show "$UNIT" \
-p Id -p LoadState -p ActiveState -p SubState -p FragmentPath -p ControlGroup \
--no-pager || true
sudo systemctl list-units --all --type=scope | grep "$FULL_ID" || true
sudo systemctl --failed | grep "$FULL_ID" || true
sudo systemctl reset-failed "$UNIT"
sudo systemctl daemon-reload
docker start "$CID"
```
### B. If that fails
```bash
sudo systemctl stop "$UNIT" || true
sudo systemctl reset-failed "$UNIT"
sudo systemctl daemon-reload
docker start "$CID"
```
### C. If that still fails
```bash
sudo systemctl restart containerd
sudo systemctl restart docker
docker start "$CID"
```
### D. If it keeps recurring
```bash
sudo journalctl -k -b --no-pager \
| grep -i -E 'oom|out of memory|killed process|memory cgroup' || true
docker inspect "$CID" \
--format 'RestartPolicy={{json .HostConfig.RestartPolicy}} RestartCount={{.RestartCount}} OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}}'
docker logs --tail=300 "$CID"
docker info | grep -i -E 'Cgroup|Runtime|Rootless|containerd|runc|Kernel|Operating System'
```
* * *
## What not to do first
### Do not manually delete cgroup directories first
Avoid starting with:
```bash
sudo rm -rf /sys/fs/cgroup/system.slice/docker-*.scope
```
The cgroup tree is kernel/systemd-managed state. Manual deletion can make diagnosis worse.
Prefer:
```bash
systemctl status
systemctl stop
systemctl reset-failed
systemctl daemon-reload
systemctl restart docker/containerd
```
* * *
### Do not blindly kill `containerd-shim` processes
Avoid:
```bash
sudo kill -9
```
unless you have mapped that PID to the affected container and understand the impact.
* * *
### Do not disable the OOM killer as a shortcut
Avoid:
```bash
--oom-kill-disable
```
unless you also set memory limits and understand the consequences.
* * *
### Do not treat `docker rm && docker run` as a real fix
It is a workaround because it changes the container ID and scope name. It does not explain why the scope got stuck.
* * *
## Minimal diagnostic bundle
If asking Docker, your distro, an infrastructure admin, or a hosting provider, collect this:
```bash
CID=e16fc114c32f
FULL_ID=$(docker inspect -f '{{.Id}}' "$CID" 2>/dev/null || true)
UNIT="docker-${FULL_ID}.scope"
{
echo '### date'
date -Is
echo '### docker version'
docker version || true
echo '### docker info'
docker info || true
echo '### containerd version'
containerd --version || true
echo '### runc version'
runc --version || true
echo '### systemd version'
systemctl --version || true
echo '### kernel / os'
uname -a || true
cat /etc/os-release || true
echo '### container state'
docker inspect "$CID" --format '{{json .State}}' || true
echo '### restart and memory config'
docker inspect "$CID" \
--format 'RestartPolicy={{json .HostConfig.RestartPolicy}} Memory={{.HostConfig.Memory}} MemorySwap={{.HostConfig.MemorySwap}} OomKillDisable={{.HostConfig.OomKillDisable}}' || true
echo '### target unit'
echo "$UNIT"
sudo systemctl status "$UNIT" --no-pager --full || true
sudo systemctl show "$UNIT" \
-p Id -p LoadState -p ActiveState -p SubState -p FragmentPath -p ControlGroup \
--no-pager || true
echo '### docker scopes'
sudo systemctl list-units --all --type=scope | grep docker || true
echo '### failed units'
sudo systemctl --failed || true
echo '### docker/containerd logs'
sudo journalctl -u docker.service -u containerd.service -b --no-pager | tail -500 || true
echo '### kernel OOM logs'
sudo journalctl -k -b --no-pager \
| grep -i -E 'oom|out of memory|killed process|memory cgroup' || true
} > docker-scope-debug.txt
```
Review `docker-scope-debug.txt` before sharing it. It may contain private paths, image names, hostnames, or internal service names.
* * *
## Useful references
Official docs:
- [Docker docs: Runtime metrics and cgroup paths](https://docs.docker.com/engine/containers/runmetrics/)
- [Docker docs: Resource constraints and OOM behavior](https://docs.docker.com/engine/containers/resource_constraints/)
- [Docker docs: Docker daemon logs](https://docs.docker.com/engine/daemon/logs/)
- [Docker docs: `dockerd` reference](https://docs.docker.com/reference/cli/dockerd/)
- [Docker docs: Rootless mode troubleshooting](https://docs.docker.com/engine/security/rootless/troubleshoot/)
- [runc docs: systemd cgroup support](https://github.com/opencontainers/runc/blob/main/docs/systemd.md)
- [systemd docs: cgroup delegation](https://systemd.io/CGROUP_DELEGATION/)
- [systemctl manual: `reset-failed`](https://man7.org/linux/man-pages/man1/systemctl.1.html)
Similar issues and useful cases:
- [Moby #7015: Docker systemd cgroup scope left behind](https://github.com/moby/moby/issues/7015)
- [Moby #13802: systemd scopes leakage](https://github.com/moby/moby/issues/13802)
- [crun #1138: failed systemd scope after container OOM](https://github.com/containers/crun/issues/1138)
- [crun #1092: OOM leaves cgroups in bad state](https://github.com/containers/crun/issues/1092)
- [crun #1560: slice already loaded / fragment file](https://github.com/containers/crun/issues/1560)
- [Podman #24010: slice already loaded / fragment file during parallel testing](https://github.com/containers/podman/issues/24010)
- [GitLab Runner #36949: intermittent Docker `docker-*.scope` failure](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/36949)
- [Docker docs issue #14545: rootless cgroup paths differ from `system.slice`](https://github.com/docker/docker.github.io/issues/14545)
* * *
## Bottom line
For this exact error, I would treat the immediate cause as:
```plaintext
systemd still has docker-e16fc114c32f6c9154ae3c2c0bb8ade6298ff61eaf61529b58bd2939eefd7f7c.scope
loaded, failed, active, or represented by a transient fragment.
```
Most likely triggers:
1. stale/failed systemd scope after a previous failed start;
2. OOM kill or memory pressure;
3. crash/restart loop;
4. Docker/containerd/runc/systemd cleanup race;
5. host runtime version or cgroup v2 issue;
6. rootless Docker only if `docker info` says rootless.
Best first recovery:
```bash
CID=e16fc114c32f
FULL_ID=$(docker inspect -f '{{.Id}}' "$CID")
UNIT="docker-${FULL_ID}.scope"
sudo systemctl reset-failed "$UNIT"
sudo systemctl daemon-reload
docker start "$CID"
```
Then immediately check the trigger:
```bash
sudo journalctl -k -b --no-pager \
| grep -i -E 'oom|out of memory|killed process|memory cgroup' || true
docker inspect "$CID" \
--format 'RestartPolicy={{json .HostConfig.RestartPolicy}} RestartCount={{.RestartCount}} OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}}'
docker info | grep -i -E 'Cgroup|Runtime|Rootless|containerd|runc|Kernel|Operating System'
```
Deleting and recreating the container is only a workaround. It changes the container ID and therefore the `docker-.scope` name. If the underlying trigger remains, the error can return.