How to fix Error response from daemon: Cannot kill container: unknown error after kill in Docker

DockerINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 266 views

The Docker daemon fails to stop or kill a container with 'unknown error after kill'. This occurs when containers enter an inconsistent state due to AppArmor conflicts, zombie processes, or daemon issues.

Quick fix

Fixes Error response from daemon: Cannot kill container: unknown error after kill

docker ps -a | grep <container_name_or_id>
docker logs <container_id>
docker inspect <container_id>
  1. Check container status and logs
  2. Restart the Docker daemon
  3. Remove unknown AppArmor profiles (Ubuntu/Debian)
  4. Kill the container's host process directly
docker — error
docker ps -a | grep <container_name_or_id>
docker logs <container_id>
docker inspect <container_id>
Error response from daemon: Cannot kill container: unknown error after kill

What this error means

This error occurs when Docker's daemon attempts to terminate a container but fails to receive confirmation that the process has stopped. The full error typically reads: "Error response from daemon: Cannot kill container: unknown error after kill" or "tried to kill container, but did not receive an exit event". The Docker daemon uses signals (like SIGTERM and SIGKILL) to stop containers. When these signals don't reach the container process, or when the container's init process becomes unresponsive, Docker can't complete the stop operation. This leaves the container in a "zombie" or stuck state where it appears running but can't be interacted with. This issue commonly arises from conflicts with Linux security modules (particularly AppArmor), corrupted container state, or bugs in the container runtime (runc, containerd). On systems that previously had Docker installed via snap and then reinstalled via apt, orphaned AppArmor profiles are a frequent culprit.

Typical symptoms

  • Container appears running in 'docker ps' but cannot be stopped with 'docker stop'
  • 'docker kill' command fails with 'unknown error after kill'
  • Cannot remove container even with 'docker rm -f'
  • Docker daemon logs show 'tried to kill container, but did not receive an exit event'
  • Cannot execute commands inside the container with 'docker exec'
  • Container restart policies cause zombie containers to respawn repeatedly

Common causes

  1. Conflicting AppArmor profiles from previous Docker installations (especially snap to apt migrations)
  2. Container's PID 1 process has become a zombie and cannot respond to signals
  3. Docker daemon or containerd entered an inconsistent state
  4. Linux kernel bug in container signal handling (known issues with kernel 4.19+)
  5. Storage driver corruption (particularly with aufs driver)
  6. Container has restart policy 'always' and Docker Swarm is managing it
  7. Permission denied errors when Docker daemon tries to send kill signal

How to fix "Error response from daemon: Cannot kill container: unknown error after kill"

1Check container status and logs

First, verify the container state and check for specific error messages:

bash
docker ps -a | grep <container_name_or_id>
docker logs <container_id>
docker inspect <container_id>

Look for status indicators like "Restarting", "Dead", or stuck in "Up" state. Check the inspect output for restart policies that might be causing respawn behavior.

2Restart the Docker daemon

The simplest fix that resolves most cases is restarting the Docker service:

bash
sudo systemctl restart docker.socket docker.service

After the daemon restarts, try removing the container:

bash
docker rm -f <container_id>

This clears the daemon's internal state and often allows stuck containers to be removed.

3Remove unknown AppArmor profiles (Ubuntu/Debian)

If you're on Ubuntu or Debian and the daemon restart didn't work, conflicting AppArmor profiles are likely the cause:

bash
# Dry-run to see what will be affected
sudo aa-remove-unknown -n

# If the output looks safe, remove the unknown profiles
sudo aa-remove-unknown

Warning: This may affect snap-based applications. You may need to reboot after running this command. Reboot and try removing the container again:

bash
docker rm -f <container_id>
4Kill the container's host process directly

If the container still won't stop, locate and kill its process on the host:

bash
# Find the container's main process
ps aux | grep <container_id>

# Kill the process (replace <PID> with actual process ID)
sudo kill -9 <PID>

# Also kill the containerd-shim process if present
ps aux | grep containerd-shim | grep <container_id>
sudo kill -9 <shim_PID>

After killing the process, restart Docker and clean up:

bash
sudo systemctl restart docker
docker system prune -a
5Check for Docker Swarm or restart policies

Containers with restart: always policies or managed by Docker Swarm will respawn even after being killed:

bash
# Check if Swarm is active
docker service ls
docker stack ls

# If services exist, remove them first
docker service rm <service_name>

# Or leave Swarm mode entirely if not needed
docker swarm leave --force

For containers with restart policies, you need to update the policy before stopping:

bash
docker update --restart=no <container_id>
docker stop <container_id>

Advanced notes

AppArmor and snap conflicts: When Docker is installed via snap and then removed in favor of the official apt repository version, AppArmor profiles from the snap installation can persist. These profiles may block the new Docker daemon from properly managing containers. The aa-remove-unknown command removes these orphaned profiles.

Storage driver issues: The aufs storage driver has known issues that can cause container lockups. If you frequently encounter this issue, consider switching to overlay2:

bash
# WARNING: This will delete all Docker images and containers
sudo systemctl stop docker
# Edit /etc/docker/daemon.json and add: {"storage-driver": "overlay2"}
sudo rm -rf /var/lib/docker
sudo systemctl start docker

Using --init flag: To prevent zombie processes from making containers unkillable in the future, use the --init flag when running containers:

bash
docker run --init your-image

This adds a lightweight init process (tini) that properly handles signals and reaps zombie processes.

Manual cleanup (extreme cases): If nothing else works, you can manually remove the container's files, but this should be a last resort:

bash
# Find the storage driver
docker info | grep "Storage Driver"

# Remove container directory (replace <storage_driver> and <container_id>)
sudo systemctl stop docker
sudo rm -rf /var/lib/docker/<storage_driver>/<container_id>/
sudo systemctl start docker

Kernel bugs: Some versions of the Linux kernel (particularly 4.19+) have bugs in container signal handling. If you're experiencing this issue repeatedly, consider updating your kernel or checking the Docker GitHub issues for known kernel-related bugs.

Frequently asked questions

What does "Error response from daemon: Cannot kill container: unknown error after" mean?
This error occurs when Docker's daemon attempts to terminate a container but fails to receive confirmation that the process has stopped. The full error typically reads: "Error response from daemon: Cannot kill container: unknown error after kill" or "tried to kill container, but did not receive an exit event". The Docker daemon uses signals (like SIGTERM and SIGKILL) to stop containers.
How do I fix "Error response from daemon: Cannot kill container: unknown error after"?
The Docker daemon fails to stop or kill a container with 'unknown error after kill'. This occurs when containers enter an inconsistent state due to AppArmor conflicts, zombie processes, or daemon issues.
What causes "Error response from daemon: Cannot kill container: unknown error after"?
Conflicting AppArmor profiles from previous Docker installations (especially snap to apt migrations) Container's PID 1 process has become a zombie and cannot respond to signals Docker daemon or containerd entered an inconsistent state
Is the "Error response from daemon: Cannot kill container: unknown error after" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading