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.
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.
First, verify the container state and check for specific error messages:
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.
The simplest fix that resolves most cases is restarting the Docker service:
sudo systemctl restart docker.socket docker.serviceAfter the daemon restarts, try removing the container:
docker rm -f <container_id>This clears the daemon's internal state and often allows stuck containers to be removed.
If you're on Ubuntu or Debian and the daemon restart didn't work, conflicting AppArmor profiles are likely the cause:
# 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-unknownWarning: This may affect snap-based applications. You may need to reboot after running this command. Reboot and try removing the container again:
docker rm -f <container_id>If the container still won't stop, locate and kill its process on the host:
# 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:
sudo systemctl restart docker
docker system prune -aContainers with restart: always policies or managed by Docker Swarm will respawn even after being killed:
# 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 --forceFor containers with restart policies, you need to update the policy before stopping:
docker update --restart=no <container_id>
docker stop <container_id>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:
# 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 dockerUsing --init flag: To prevent zombie processes from making containers unkillable in the future, use the --init flag when running containers:
docker run --init your-imageThis 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:
# 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 dockerKernel 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.
image operating system "linux" cannot be used on this platform
How to fix 'image operating system linux cannot be used on this platform' in Docker
manifest unknown: manifest unknown
How to fix 'manifest unknown' in Docker
cannot open '/etc/passwd': Permission denied
How to fix 'cannot open: Permission denied' in Docker
Error response from daemon: failed to create the ipvlan port
How to fix 'failed to create the ipvlan port' in Docker
toomanyrequests: Rate exceeded for anonymous users
How to fix 'Rate exceeded for anonymous users' in Docker Hub