Docker Daemon Not Responding: Diagnose and Recover
Troubleshoot an unresponsive Docker daemon on Linux and Windows: confirm the hang, check processes and logs, find resource pressure, restart safely, and prevent recurrence.
Rao Aadil, India 7 min read
Confirm the daemon is actually unresponsive
A hanging docker ps is usually the first sign that the Docker daemon has stopped answering. Run it with a timeout on Linux to separate a hang from an immediate connection error:
timeout 5 docker ps
If the command returns Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? immediately, the client cannot reach the socket, which often means the daemon is not running at all. If it waits for five seconds and then exits with no output, the daemon is likely up but not answering.
Windows users should open PowerShell or cmd and run docker ps. If the prompt sits there with no output, the daemon may be unresponsive. There is no built-in timeout command that wraps another command, but you can observe whether the command returns quickly with an error or hangs.
Run docker info and docker version as well. If both hang, the daemon is not responding to API calls over /var/run/docker.sock on Linux or //./pipe/docker_engine on Windows. If docker version shows client information but then hangs before server info, the client is connecting but the daemon is not answering.
Before assuming the daemon is broken, rule out client-side issues. Check docker context ls to see which endpoint the client is targeting. A wrong DOCKER_HOST environment variable or an inactive Docker Desktop installation can produce an immediate error, not a hang. On Windows, if Docker Desktop is not running, docker ps usually fails quickly with an error about the named pipe, not with a hang.
Inspect containers, read logs, check stats, restart services and run Compose stacks, just by describing what you want.
“why does this container keep restarting”
It reads the real state of the server before it says anything, shows you the exact command, and waits for your approval. Windows and Linux, over the SSH access you already have.
Check the daemon process and service state
Check the service state and process list on Linux:
systemctl status docker --no-pager
systemctl is-active docker
ps aux | grep dockerd
The daemon also depends on containerd, so check its status as well:
systemctl status containerd --no-pager
A healthy daemon shows active (running) in systemctl and a dockerd process that is not consuming 100% CPU. If the service is active but docker ps still hangs, the process may be alive but stuck. Look at the process state with ps -o stat,pcpu,pmem,etime,cmd -p <pid>, replacing <pid> with the dockerd PID from pgrep dockerd. A state of D (uninterruptible sleep) or a long elapsed time with almost no CPU time suggests the daemon is blocked.
Run PowerShell as Administrator on Windows and use:
Get-Service docker
Get-Process dockerd
For Docker Desktop, the service name may be com.docker.service; use Get-Service *docker* to list all Docker-related services. Check that the Docker Desktop process is running. A process that is alive but not responding will often show low CPU activity while you issue docker commands. Use Get-Process dockerd | Select-Object Id,CPU,StartTime to see if the process has been running for a long time with little work.
Read daemon and containerd logs to find why it's stuck
Journald usually captures the daemon logs on Linux:
journalctl -u docker -n 200 --no-pager
journalctl -u containerd -n 200 --no-pager
You can follow the log while reproducing the hang with journalctl -u docker -f in one terminal and docker ps in another. If journalctl returns no entries, persistent journaling may be disabled. Enable it by editing /etc/systemd/journald.conf, setting Storage=persistent, and restarting systemd-journald. If journald is not available, check /var/log/docker (may not exist on all distributions) or syslog for relevant entries.
Look for lines containing timeout, deadlock, OOM, failed to start, containerd crashed, or repeated starting daemon messages. These indicate the underlying cause.
Docker Desktop writes logs to %LOCALAPPDATA%\Docker\log.txt on Windows. Open that file or view the tail with PowerShell:
Get-Content $env:LOCALAPPDATA\Docker\log.txt -Tail 100
For Windows containers using the Docker Engine service, check the Application event log:
Get-EventLog -LogName Application -Source Docker -Newest 100
or use Event Viewer. Search for similar error strings.
Check resource exhaustion: memory, disk, and open files
Start with memory, disk, and file descriptors; a stuck daemon is often starved for one of them.
On Linux:
free -h
df -h /var/lib/docker
df -i /var/lib/docker
/var/lib/docker is the default data root. If Docker data is stored elsewhere, adjust the path. Low free memory, full disk, or inode exhaustion can all cause the daemon to hang. Check the daemon's open file limit:
PID=$(pgrep dockerd)
grep 'Max open files' /proc/$PID/limits
If the limit is low and the daemon manages many containers, it may run out of file descriptors.
Use PowerShell on Windows to inspect the dockerd process:
Get-Process dockerd | Select-Object Id,CPU,WorkingSet,Handles
Check free space on the drive where Docker data is stored (default C:\ProgramData\Docker for Windows containers or the Docker Desktop data directory). If the daemon is responsive enough to run docker stats, that will show per-container memory and CPU usage. If not, use Task Manager or top on Linux to see which process is consuming resources.
Safely restart the Docker daemon
If the daemon is truly stuck, restart it. Try a normal restart first on Linux:
sudo systemctl restart docker
If systemctl restart docker hangs or times out, send SIGTERM to the daemon directly and then start it:
sudo systemctl kill -s SIGTERM docker
sudo systemctl start docker
If that does not work, you may need SIGKILL, but try SIGTERM first to allow a clean shutdown. Note: by default, restarting the Docker daemon stops all running containers. To keep containers running across daemon restarts, enable live-restore in /etc/docker/daemon.json:
{
"live-restore": true
}
After adding this, run sudo systemctl restart docker to apply. With live-restore enabled, subsequent daemon restarts will keep containers running, though you cannot change container configurations while the daemon is down.
For Windows, run PowerShell as Administrator:
Restart-Service docker
Or from an elevated cmd:
net stop docker
net start docker
For Docker Desktop, restart the application from the system tray or Task Manager. Always confirm before restarting because running containers may stop unless live-restore is configured (Linux) or the platform has an equivalent setting. Note any unsaved state or running jobs.
Verify the daemon recovered and containers are healthy
After restart, run:
docker ps
docker info
docker info should return the server version and storage driver without hanging. Check that your containers are running as expected. If containers restarted due to restart policies, read their logs to understand why:
docker logs <container>
Check overall disk usage with docker system df. Run the same commands from PowerShell on Windows and verify Docker Desktop shows a healthy status.
Prevent future daemon unresponsiveness
Fix the likely causes now, or the daemon will hang again.
Configure log rotation to keep container logs from filling the disk. On Linux, edit /etc/docker/daemon.json:
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
On Docker Desktop, open Settings > Docker Engine and add the same JSON, then restart. For Windows containers, the daemon.json is usually located at C:\ProgramData\Docker\config\daemon.json.
Set resource limits on containers so one cannot starve the daemon. Use --memory, --cpus, and --pids-limit on docker run, or equivalent settings in Compose files. Enable container healthchecks so unhealthy containers are detected early. Keep Docker Engine and Docker Desktop updated, as older versions may contain daemon deadlock bugs.
Regularly prune unused images, containers, and volumes with docker system prune after confirming they are not needed.
Once the daemon is reachable, an AI agent can help identify which container triggered the problem. Ask it to "show me the logs for the api container, last 200 lines" or "which container is eating all the memory". It can restart that container with confirmation, but host-level daemon recovery still requires the manual service restart commands above.
