cli: docker ps -l doesn't list the existing container

Description

I have removed a lot of stopped container, except one. Then I was trying to list the only existing (stopped) container with docker ps -l or docker ps -n1 but it yields nothing.

$ docker ps -l
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
$ docker ps -n1
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

On the contrary docker ps -a does lists the container:

$ docker ps -qa
8f0b52e5b059

Strangely if I increase the argument for -n/--last the container is listed:

$ docker ps -qn 1
$ docker ps -qn 2
$ docker ps -qn 10
$ docker ps -qn 11
$ docker ps -qn 12
$ docker ps -qn 13
8f0b52e5b059

Steps to reproduce the issue:

Describe the results you received:

> docker ps -ql
# nothing

Describe the results you expected:

> docker ps -ql
8f0b52e5b059

Output of docker version:

Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b
 Built:             Wed Mar 11 01:21:11 2020
 OS/Arch:           darwin/amd64
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b
  Built:            Wed Mar 11 01:29:16 2020
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of docker info:

Client:
 Debug Mode: false
 Plugins:
  app: Docker Application (Docker Inc., v0.8.0)
  buildx: Build with BuildKit (Docker Inc., v0.3.0-5-g5b97415-tp-docker)
  clip: Docker Client Plugins Manager (Łukasz Lach, v19.06.0)
  dive: Explore contents of the image layers (Łukasz Lach, v19.06.0)
  microscan: Scan the security of an image with Aqua Microscanner (Łukasz Lach, v19.06.0)
  runlike: Get the command line necessary to run a copy of any container (Łukasz Lach, v19.06.0)
  wasm: Run wasm containers (Docker Inc.)
  mutagen: Synchronize files with Docker Desktop (Docker Inc., testing)

Server:
 Containers: 13
  Running: 11
  Paused: 0
  Stopped: 2
 Images: 11
 Server Version: 19.03.8
 Storage Driver: overlay2
  Backing Filesystem: <unknown>
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.19.76-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 1.947GiB
 Name: docker-desktop
 ID: QNMK:EWUP:NUXS:ICP5:CKGQ:AVYG:AEDB:XLSX:LK3Y:G3C7:GNBV:5GUO
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 102
  Goroutines: 96
  System Time: 2020-04-16T08:26:08.3063448Z
  EventsListeners: 3
 HTTP Proxy: gateway.docker.internal:3128
 HTTPS Proxy: gateway.docker.internal:3129
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  docker.for.mac.localhost:5000
  localhost:5000
  registry.ing.k8z.eu
  registry.k8z.eu
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

Additional environment details (AWS, VirtualBox, physical, etc.):

About this issue

Original URL
State: open
Created 4 years ago
Comments: 15 (5 by maintainers)

Most upvoted comments

TL;DR

Enter the following command:

docker context use default

Full Explanation

The Low-Level Problem

Having just experiencedd the same problem myself, I went off a hunch and soon discovered file located at the following file path (that will be different for you but also similar enough):

$HOME/.docker/contexts/meta/fe9c6bd7a66301f49ca9b6a70b217107cd1284598bfc254700c989b916da791e/meta.json

This JSON file contains the following:

{
	"Name": "desktop-linux",
	"Metadata": {},
	"Endpoints": {
		"docker": {
			"Host": "unix:///Users/USERNAME/.docker/run/docker.sock",
			"SkipTLSVerify": false
		}
	}
}

The Endpoints.docker.Host path is what dictates the path to the Docker daemon, so it’s possible you could also apply @lalyos’ workaround by pasting the UNIX socket path in place of that property’s value.

Another Possible Workaround

Although, as you might imagine with the hashed directory name within the file path, this isn’t a permanent file, and chances are high that your changes will be overridden the next time you reboot your Mac device, restart Docker, and/or update Docker Desktop.

You could always create a shell script to be placed within your .bashrc, .zshrc, or $__fish_config_dir.

The Actual Solution

While it’s still just a theory at this point, I think I may have discovered the culprit to this particular blight:

If you enter enter docker context ls into your terminal, I’m willing to bet you’ll see at least TWO contexts listed - default and desktop-linux – with the latter selected.

Assuming I’m correct, if you just enter docker context use default, it should update the Endpoints.docker.Host property within your local meta.json file with the correct path to your Docker Desktop daemon.

The High-Level Cause

This type of thing just doesn’t happen on its own, and if you’re like me, you don’t mess with Docker’s context feature all that much; however, this kinda thing doesn’t just happen on its own, though, right?

Well, I believe I have another theory as to what may be the root cause:

If you’re like me, a developer who uses the Docker extension for Visual Studio Code, and have your Visual Studio Code profile configured to sync-up across all your machines – at least one of which is running some flavor Linux (e.g., Debian or Ubuntu) and at least one other is running MacOS.

The Long-Term Solution

Unfortunately, at the time of this post, there isn’t a native way to configure a default Docker context in your Visual Studio Code’s settings.json file in any way shape or form – let alone a way to configure it based on Operating System.

Although, that may not be needed. It may be enough for the Docker development team (or some unsung open-source hero who’s well versed in Golang) to apply some sort of verification check based on the active Operating System to make sure the correct daemon is used (assuming that isn’t already implemented).

Again, this is just a theory on my part.

KerickHowlett on May 17, 2023