Why docker ps Was Empty While a Containerized Service Was Running

Resolved a personal Ubuntu host's conflicting Docker views by identifying competing Snap and apt installations.

Linux / Containers / Root Cause Analysis · 2 min read

UbuntuDocker EngineSnapsystemdcontainerd

These are personal lab projects and learning notes. Architecture diagrams are simplified for publication; internal addresses and sensitive configuration are omitted. Professional work is documented separately.

The symptom

A web application remained reachable on its published port, yet docker ps returned no running containers. That contradiction suggested the CLI and the active service were not describing the same daemon context.

Investigation across system layers

I checked the listening port with ss and inspected process ancestry. docker-proxy, a container runtime shim and the application process showed that container processes were running despite the empty CLI view.

The host had separate Docker installations from Snap and apt, with separate daemon/runtime contexts. The CLI was observing a different daemon from the one associated with the live service. This explains why an empty container list did not mean there were no running container processes.

Illustrative diagnostic commands

Illustrative diagnostic commands — no recorded output

sudo ss -lntp
ps aux | grep -E 'dockerd|containerd|docker-proxy'
which docker
docker context ls
docker info
snap list docker
systemctl status docker

Examples only, not exact executed order or recorded output. Establish daemon ownership and workload impact before stopping any service; do not stop a production daemon based on this example.

Resolution and outcome

After identifying installation and process ownership, I stopped the Snap-managed Docker daemon and restarted the systemd-managed Docker service. The CLI then showed two running containers, including the previously missing application container, and the web service remained reachable.

Removing the redundant Snap installation was proposed as follow-up. The notes do not establish that removal was completed.

Tradeoffs and evidence boundary

Restarting a daemon can affect its workloads. This was a personal Ubuntu host, not an employer system or a measured enterprise outage. No exact output, downtime measurement or generalized zero-downtime guarantee is provided.

Lessons learned

When an administrative command contradicts a reachable service, check sockets, process ownership, packaging, daemon endpoints and CLI context together. Evidence from multiple layers can explain apparently impossible states.

Next steps

Review whether the redundant installation can be safely removed.
Document the intended Docker installation and CLI context for future maintenance.