How to Check if Docker Is Running on Your System

You type docker ps and get a connection error. The CLI is fine. What’s missing is the docker daemon, the background service that manages images, containers, networks and volumes and answers every request the CLI sends over a socket.

On Linux it runs as dockerd under docker.service, usually managed by an administrator. On Windows and macOS it lives inside Docker Desktop.

Docker Docs points to docker info as the test that works on any operating system. For Linux services it also lists sudo systemctl is-active docker, sudo status docker and sudo service docker status (Docker Docs, 2025).

With the daemon stopped, the CLI stays installed but says nothing useful.

What does it mean for Docker to be running?

Docker counts as running when the daemon process, dockerd, is alive and answering the CLI over a socket. Seeing the docker binary on disk proves nothing.

Look for dockerd with ps or pgrep. It calls containerd to start and supervise the containers themselves, and it runs as root unless you set up rootless mode (Docker Docs, 2026). Linux uses Docker Engine, while Windows and macOS use Docker Desktop.

The CLI is only a client. It forwards each command and prints whatever comes back.

Every Docker container gets built from an image by the daemon, which also tracks its state afterward. No daemon, nothing to list or start.

Stop it and each command ends in a connection error, even with the CLI binary sitting right there.

How does the docker CLI connect to the daemon?

On Linux the CLI talks to a Unix socket, /var/run/docker.sock by default (Docker Docs, 2026). Windows uses a named pipe. Set the DOCKER_HOST variable or switch docker contexts and the CLI ends up somewhere else entirely.

Docker Desktop adds a context of its own, which is why the client on Windows and macOS talks to the Desktop engine and not the Linux default.

When the daemon listens on TCP, the ports are 2376 with TLS and 2375 without (Docker Docs, 2026). The API also exposes a health endpoint at /\_ping (Docker Engine API reference).

Socket ownership decides who gets in. It belongs to root, with access for members of the docker group (Docker Docs, 2026), so anyone outside that group needs sudo.

To see whether the client points at another host, run env | grep DOCKER_HOST. It prints a value only when something is set. If the variable was set by mistake, Docker Docs advises unset DOCKER_HOST (Docker Docs, 2025).

On Debian and Ubuntu, systemd starts dockerd with the -H fd:// flag, so the docker.socket unit hands the listening socket to the daemon (Docker Docs, 2025). While docker.socket is active, your first docker command starts a stopped docker.service.

Docker Docs states that remote access without TLS is not recommended and will require explicit opt-in in a future release (Docker Docs, 2026).

How do you check the Docker daemon status on Linux?

Run sudo systemctl status docker and read the service state. Active (running) means the daemon is up. Inactive (dead) means someone stopped it, and failed means the last start ended in an error.

Scripts do better with sudo systemctl is-active docker, which prints a single word (Docker Docs, 2025).

1. Run sudo systemctl status docker and read the Active line.
2. Run sudo systemctl is-active docker to get active, inactive or failed as plain text.
3. Run pgrep -a dockerd to find the process ID and command line.
4. Run docker info to confirm the daemon answers requests.
5. If the first three steps report a stopped daemon, run sudo systemctl start docker.

The full procedure for starting the Docker daemon is covered separately.

Reading systemctl output

Active (running) means the daemon accepts connections. Inactive (dead) means the service is stopped, so every docker command fails to connect. Failed is the one that needs digging, because the journal holds the reason the last start attempt went wrong.

Socket activation muddies this a little. With docker.socket active, the first docker command starts docker.service, so an inactive reading can disappear by the time you check again.

Distributions without systemd read the same state with sudo service docker status or sudo status docker (Docker Docs, 2025).

Checking the dockerd process directly

A process check helps when systemd is missing or the unit state looks off.

• pgrep -a dockerd prints the process ID and command line
• ps aux | grep dockerd lists the process (the grep line itself shows up too)
• top shows how much the daemon is using while it runs

A live dockerd process still doesn’t prove the API answers. Run docker info before you trust it.

How do you check if Docker is running with docker info, docker version and docker ps?

Start with docker info. Docker Docs calls it the operating-system independent way to test whether the daemon runs (Docker Docs, 2025). A Server section in docker version output and a successful docker ps tell you the same thing.

Docker info works the same on Linux, Windows and macOS and prints a full report on the daemon. Its one catch is that it reports on whichever daemon the active context selects, remote ones included, so you can get a healthy answer from a machine you didn’t mean to ask.

Docker version separates client details from server details, and a Server section proves the daemon answered. It also prints the Client section when the daemon is down. A quick glance at the top of the output can fool you.

Docker ps is fine as a check, since even an empty container list proves the daemon responds. Users outside the docker group get a permission error from it though, and the daemon may be perfectly healthy the whole time.

Then there’s docker run --rm hello-world, the slowest of the bunch. It downloads a test image, starts a container, prints a message and exits, which means it tests the whole chain (Docker Docs, 2026). The first run needs registry access. For a quick yes or no it’s overkill.

The other daemon-facing commands sit in a Docker cheat sheet, which saves a trip through the docs.

How do you check the daemon through the socket and the ping endpoint?

Send a request to the Engine API /_ping endpoint through the Unix socket with curl. The API defines a 200 response for a reachable daemon and a 500 for a daemon error (Docker Engine API reference).

This is the option when the docker CLI isn’t installed at all.

• Through the socket: curl --unix-socket /var/run/docker.sock http://localhost/_ping
• Header only: curl -I --unix-socket /var/run/docker.sock http://localhost/_ping
• Over TCP without TLS: curl http://127.0.0.1:2375/_ping, once the daemon listens on that address

Docker Engine 19.03 added HEAD support for /_ping, plus Cache-Control headers that stop the response from being cached (Docker Engine 19.03 release notes, 2019).

A daemon protected by TLS on port 2376 also wants certificate flags on the curl call.

The API route earns its place in minimal containers without the docker binary, in health probes, and in monitoring agents. The docker-prometheus-exporter project maps /_ping to its up metric, which is its test for whether the daemon is alive (docker-prometheus-exporter 1.1.3 documentation).

Curl needs the same socket access the CLI does. Outside the docker group you get a permission error unless the call runs with sudo.

A 200 from /_ping proves the API answers and nothing more. Image pulls and container starts are a separate question.

How do you check if Docker Desktop is running on Windows and macOS?

Open Docker Desktop and read the engine status indicator in its window. Then run docker info in PowerShell or Terminal. If you get a Server section back, the engine answers.

The app can be open while the engine is stopped, and then every command fails.

Both platforms run the daemon inside a virtual machine, so the app window and the engine are separate states.

Windows

Docker Desktop for Windows supports the WSL 2, Hyper-V and Docker VMM (Beta) backends, and WSL 2 is the default (Docker Docs, 2026).

In PowerShell, docker info returns a Server section when the engine runs. Task Manager shows Docker Desktop processes while the app is up. Windows Services lists a privileged Docker service only under the all-users install, because the per-user WSL 2 option installs none (Docker Docs, 2026).

The WSL 2 backend needs WSL version 2.1.5 or later, and wsl --version prints the installed one (Docker Docs, 2026).

macOS

Docker Desktop for Mac keeps a whale icon in the menu bar. It animates during startup and holds still once the engine is running.

Activity Monitor lists the Docker processes if you search for Docker, and docker info in Terminal returns a Server section on a healthy engine. An icon that never settles usually means the engine failed to start.

Which method should you use to check Docker?

For a manual check on any platform, use docker info. On Linux scripts, systemctl is-active docker is the better fit. Where no docker CLI exists, go to the /_ping endpoint, and for a quick look on Windows or macOS the Docker Desktop indicator does the job.

My pick is docker info over docker ps. It also prints the active context, so the result tells you which daemon actually answered.

Keep the Desktop indicator out of scripts. A script needs an exit code, and systemctl is-active or a /_ping call gives you one.

What does “Cannot connect to the Docker daemon” mean?

The CLI reached for the daemon endpoint and got no answer. Docker Docs gives two causes: the daemon is stopped, or the client is aimed at a host it can’t reach (Docker Docs, 2025).

Older clients print Cannot connect to the Docker daemon. Is 'docker daemon' running on this host? Newer ones add the endpoint to the same sentence.

Work through the table top to bottom, since the cheapest checks come first and each one is a single command.

Some daemons never start, and then the cause runs deeper. Docker can’t run correctly on a kernel older than 3.10 or one missing kernel modules, and the check-config.sh script tests a Linux kernel for both (Docker Docs, 2025).

Docker Compose reaches the daemon through the same endpoint, so the same error shows up there and the same fixes apply.

If the packages never finished installing, there’s no dockerd to start in the first place. The guide on installing Docker covers a clean setup.

How do you fix permission denied on the Docker socket?

Permission denied means the daemon runs but your user can’t open its socket. Add yourself to the docker group with sudo usermod -aG docker $USER, then log out and back in.

Keep in mind that the docker group grants root-level privileges (Docker Docs, 2026).

Read the message before you change anything. Permission denied is about access, while Cannot connect is about a missing daemon.

• sudo groupadd docker creates the group if the package left it out
• sudo usermod -aG docker $USER adds your user
• newgrp docker or a fresh login activates the membership
• docker run hello-world confirms access without sudo

Inside a Linux virtual machine, restarting the machine applies the new membership (Docker Docs, 2026).

While you sort out the group, sudo docker info proves the daemon runs. It changes nothing.

Running commands with sudo first can break ownership of ~/.docker, and the CLI then warns about a config.json permission error. Repair it with sudo chown "$USER":"$USER" /home/"$USER"/.docker -R (Docker Docs, 2026).

Permanent membership is the simple route, with no password step at all. The catch is that every process in your login session gets root-level reach through the socket.

Using newgrp with a group password cuts that ambient access, since only the Docker-enabled shell and its children reach the socket. It gives no protection against malicious code running as your user (Docker Docs, 2026), so I’d only bother on a single-user workstation.

Rootless mode removes the root-level exposure altogether, and its checks differ from everything above.

How do you start the Docker daemon and enable it at boot?

Run sudo systemctl start docker to start the daemon now and sudo systemctl enable docker.service to start it at every boot. Start acts immediately and enable only changes boot behavior. Debian and Ubuntu start the service automatically (Docker Docs, 2026).

1. Run sudo systemctl start docker to start the daemon now.
2. Run sudo systemctl enable docker.service and sudo systemctl enable containerd.service so both start at boot (Docker Docs, 2026).
3. Run sudo systemctl is-active docker and expect active.
4. Run docker info to confirm the daemon answers.

Restart stops the daemon and starts it again. Disable reverses enable, and the docs use it to stop boot startup. Start alone changes nothing about boot, and enable alone doesn’t start anything right now, which trips people up more often than you’d expect.

To skip systemd, run dockerd in a terminal. It stays in the foreground, prints its logs straight to the terminal, and stops on Ctrl+C (Docker Docs, 2024).

On Windows and macOS, starting the daemon means launching the Docker Desktop app. The setting that launches it at sign-in sits in the app settings.

How do you read Docker daemon logs when startup fails?

On Linux, run journalctl -xu docker.service to read the startup errors. Docker Desktop on macOS, and on Windows with WSL 2, writes daemon logs to a single init.log file instead (Docker Docs, 2026).

The init.log file is JSON with one line per event, and a component field names the service. Filter dockerd output with grep '"component":"dockerd"' (Docker Docs, 2026).

A few startup failures are documented. If the same directive, such as hosts, appears in daemon.json and on the dockerd command line, the daemon refuses to start. Debian and Ubuntu always pass -H through systemd, so a hosts entry in daemon.json collides with it. The kernel OOM killer can also stop the daemon along with your containers when memory runs out.

The fix for the systemd collision is an override file that clears ExecStart and restarts it as plain /usr/bin/dockerd, followed by sudo systemctl daemon-reload (Docker Docs, 2025).

A daemon that runs but stalls needs more detail. Set "debug": true in daemon.json and send sudo kill -SIGHUP $(pidof dockerd) to reload it.

sudo kill -SIGUSR1 $(pidof dockerd) writes a full stack trace to the log without stopping the daemon. Docker Desktop has no manual stack trace, so its Troubleshoot menu sends the diagnostics instead (Docker Docs, 2026).

When does the standard Docker running check not apply?

The usual checks can miss the daemon you actually use. That happens with rootless Docker, with a docker context pointing at a remote host, with Podman in place of Docker, and with a CLI inside a container that has no socket. Each one needs its own check.

Rootless Docker

Rootless mode runs the daemon and containers inside a user namespace, so the system-wide docker.service isn’t the process that answers (Docker Docs, 2026).

Check the service with systemctl --user status docker and control it with systemctl --user (start|stop|restart) docker.service. The socket for user ID 1000 is unix:///run/user/1000/docker.sock. To start it at boot, run sudo loginctl enable-linger for that user.

Setup needs at least 65,536 subordinate UIDs and GIDs in /etc/subuid and /etc/subgid, and Docker 20.10 or later packages ship dockerd-rootless-setuptool.sh (Docker Docs, 2026).

A system-wide daemon running next to it hides the problem. Docker Docs warns that until you disable docker.service and docker.socket, you are still running rootful Docker.

Remote daemon or another docker context

A local systemctl is-active docker says nothing about a daemon on another machine.

• docker info prints the active context in its Client section
• docker context ls lists the stored endpoints
• docker context use default returns the CLI to the local daemon

Read the context line before trusting any result. A green answer from the wrong daemon is still the wrong answer.

Podman and other daemonless runtimes

Podman describes itself as daemonless, so there’s no dockerd process to find and systemctl status docker reports a missing unit (Podman documentation).

Its CLI mirrors Docker, and plenty of people alias docker to podman. Check podman info instead.

Podman ships a RESTful API service that is supported on Linux only, with remote clients on Linux, Mac and Windows (Podman documentation).

A CLI inside a container

A docker CLI inside a container has no daemon and no socket unless the host socket is mounted in.

Google cAdvisor shows the pattern. Its documented run command bind-mounts /var/run and the Docker directories into the container (Docker Docs, 2025).

Mount /var/run/docker.sock and the container can reach the host daemon, with the same root-level reach as the docker group. Leave the mount out and every command ends in the connection error.

FAQ on How To Check If Docker Is Running

Is Docker installed the same as Docker running?

No. Installation puts the docker CLI and the dockerd binary on disk. Running means the daemon process is alive and its socket answers requests.

A host with the CLI present and a stopped service returns a connection error on every command.

How do you check whether Docker is running inside a script?

Run sudo systemctl is-active docker and read the exit code. Zero means active, and anything else means inactive or failed.

Without systemd, docker info returns a nonzero exit code when the daemon doesn’t answer.

How do you stop or restart Docker safely?

Run docker stop on the containers you care about first, then sudo systemctl restart docker. A daemon shutdown ends running containers unless live restore is configured.

Stop docker.socket as well if you want the daemon to stay down, because the next docker command would start the service again.

Can Docker Compose reach the daemon when docker ps works?

Yes. Docker Compose uses the same endpoint as the docker CLI, so a working docker ps confirms the path.

Compose fails only when it runs under another user, or with a different DOCKER\_HOST value than your shell.

Why does docker version show a Client section but no Server section?

The CLI prints its own details locally, then queries the daemon for the Server section. A missing Server section with an error line means the query failed.

Either the daemon is stopped, the socket is unreachable, or the docker context points at another host.

What Comes First in How To Check If Docker Is Running?

Start with docker info. One command tests the CLI, the socket and the daemon together, and it prints the active docker context, which tells a stopped daemon apart from a wrong host.

If that fails, go to sudo systemctl is-active docker on systemd hosts, then to a curl call to /\_ping when no CLI exists. Each step costs one command and rules out one layer.

A daemon that fails all of them sends you to the logs, read with journalctl -xu docker.service.

Docker Desktop has no systemctl step, so docker info and the ping call carry the check. The sequence was verified against Docker Docs in September 2026.

With the daemon answering, the next step is using Docker to build images and run containers.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu is a front-end developer at TMS Outsource with 8+ years of experience in web technologies. He writes about developer tools, software platforms, and web workflows based on daily hands-on use.

Latest posts by Bogdan Sandu (see all)

• How to Turn On Dark Mode in Notepad++ (Built-In, No Plugin) - October 3, 2026
• PostgreSQL Cheat Sheet - October 2, 2026
• How to Repair a Corrupt SQL Server Database Without Any Data Loss - October 2, 2026