Error response from daemon: rpc error: code = 2 desc = The swarm does not have a leader [closed] - docker-machine

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I have created 3 nodes swarm cluster by Virtualbox using docker-machine. The three are all running and i'm able to use 'docker-machine ssh' to connect every one.There is a problem that I restart the physical machine and the cluster seems to not work,why? The follow is the details.Thanks for your guide and advice.
san#san-System-Product-Name:~$ docker-machine ls
NAME ACTIVE DRIVER STATE URL
SWARM DOCKER ERRORS
first - virtualbox Running tcp://192.168.99.100:2376
v17.06.0-ce
second - virtualbox Running tcp://192.168.99.101:2376
v17.06.0-ce
third - virtualbox Running tcp://192.168.99.102:2376
v17.06.0-ce
The first is a leader and the second is a manager while the third is a worker.I tried to use 'docker-machine ssh first docker node ls'.
Error response from daemon:
`rpc error: code = 2 desc = The swarm does not have a leader`.
It's possible that too few managers are online. Make sure more than
half of the managers are online.
exit status 1
san#san-System-Product-Name:~$ docker-machine ssh first docker info
Containers: 2
Running: 0 Paused: 0 Stopped: 2
Images: 3
Server Version: 17.06.0-ce
Storage Driver: aufs
Root Dir: /mnt/sda1/var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 17
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: pending
NodeID: dowdk4pzfzm85zijbo23e6xs3
Error: rpc error: code = 2 desc = The swarm does not have a leader. It's possible that too few managers are online. Make sure more than half of the managers are online.
Is Manager: true Node Address: 192.168.99.100
Manager Addresses:
192.168.99.100:2375
192.168.99.102:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfb82a876ecc11b5ca0977d1733adbe58599088a
runc version: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version:
4.4.74-boot2docker
Operating System: Boot2Docker 17.06.0-ce (TCL 7.2); HEAD : 0672754 - Thu Jun 29 00:06:31 UTC 2017
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 995.8MiB
Name: first
ID: ACGX:Z6QQ:5KOX:7W2O:OMMM:43PB:4QES:KKGJ:IXUC:J2SW:F4SJ:QMQ4
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 24
Goroutines: 76
System Time: 2017-07-28T01:57:37.410536525Z
EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels: provider=virtualbox
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
san#san-System-Product-Name:~$ docker-machine ssh first docker network ls
NETWORK ID NAME DRIVER SCOPE
22e85840407d bridge bridge local
fc3c6786739c docker_gwbridge bridge local
e294dde63753 host host local
55f8e340b794 none null local
how could i fix this problem and use
docker node ls
on manage node?very thanks for your advice.

I had the same problem but I'm not sure what caused it. I was able to fix it by entering:
docker swarm init --force-new-cluster
Everything got restored.

Related

Windows unable to connect to exposed to Docker port

So I have a container running with port forwarding set up. It seems that the port is listening on the local windows host, for some reason, the connection won't go through.
The command to run the docker container:
docker run -p 4400:4400 storybook:latest
Inside the container itself, I can verify the service is running on port 4400:
netstat -ltnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:4400 0.0.0.0:* LISTEN 33/node
wget http://0.0.0.0:4400
--2022-08-23 19:57:12-- http://0.0.0.0:4400/
Connecting to 0.0.0.0:4400... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5866 (5.7K) [text/html]
Saving to: 'index.html'
100%[==============================================================================>] 5,866 --.-K/s in 0s
2022-08-23 19:57:12 (363 MB/s) - 'index.html' saved [5866/5866]
And on the windows host, I can verify docker is listening on port 4440:
netstat -aon | find /i "listening"
TCP [::]:4400 [::]:0 LISTENING 20412
tasklist
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
com.docker.backend.exe 20412 Console 1 26,540 K
But I can't access the service via the Windows host.
wget http://localhost:4400
wget : The underlying connection was closed: The connection was closed unexpectedly.
I even tried getting the IP address of the docker container:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
898079f335be storybook:latest "npx nx serve storyb…" 34 minutes ago Up 34 minutes 0.0.0.0:4400->4400/tcp, :::4400->4400/tcp relaxed_mayer
> docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' 898079f335be
172.17.0.2
And tried accessing the service via that IP:
wget http://172.17.0.2:4400
wget : Unable to connect to the remote server
The version of windows:
Edition: Windows 10 Enterprise
Version: 21H2
OS Build: 19044.1766
Docker information:
Client:
Context: desktop-linux
Debug Mode: false
Plugins:
buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
compose: Docker Compose (Docker Inc., 2.0.0-beta.4)
scan: Docker Scan (Docker Inc., v0.8.0)
Server:
Containers: 7
Running: 1
Paused: 0
Stopped: 6
Images: 22
Server Version: 20.10.7
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
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: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: d71fcd7d8303cbf684402823e425e9dd2e99285d
runc version: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
init version: de40ad0
Security Options:
seccomp
Profile: default
Kernel Version: 5.4.72-microsoft-standard-WSL2
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 25.06GiB
Name: docker-desktop
ID: VFD3:RX76:D4JD:5Z6P:R2IQ:7JD4:FFQS:YDLJ:BDNW:J4UX:4U5A:GF4S
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
EDIT: I am using WSL2 as the backend.

Docker Windows getting Client.Timeout exceeded while awaiting headers for any pull image command or login

When trying to run docker run hello-world on windows 10(no option), I am getting this error(a common error I saw on many threads) :
Unable to find image 'hello-world:latest' locally
docker: Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers).
I already had some images pulled earlier(couple of months back) which are working. But I am not able to pull any new image(eg: mongo) or even not able to pull hello-world image. Have searched throughout, tried setting up dns to 8.8.8.8/8.8.4.4, experimental=true inside docker configs(Docker Desktop GUI), yet unable to resolve. One thing I wasn't expecting was HTTP PROXY inside docker info, as I had removed the proxy settings from docker's GUI and even environment variables.
docker info:
Client:
Debug Mode: false
Plugins:
scan: Docker Scan (Docker Inc., v0.3.4)
Server:
Containers: 3
Running: 2
Paused: 0
Stopped: 1
Images: 4
Server Version: 19.03.13
Storage Driver: overlay2
Backing Filesystem: extfs
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: 8fba4e9a7d01810a393d5d25a3621dc101981175
runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
init version: fec3683
Security Options:
seccomp
Profile: default
Kernel Version: 5.4.39-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.941GiB
Name: docker-desktop
ID: <Docker Id>
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http://<ip>:port/
HTTPS Proxy: http://<ip>:port/
No Proxy: localhost,127.0.0.2,firm.com,firm.org
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
Can someone please help how to remove these proxies from docker info and allow me to pull the images ?
I have not ticked Expose daemon on tcp://localhost:2375 without TLS and Use the WSL 2 based engine inside docker-desktop gui. Also inside proxies, setting manual is turned off and network uses manual dns configuration of 8.8.8.8. Also I am unable to ping to hub.docker.com which says request timeout, and trying to do docker login inside cmd returns the same request timeout error, but docker desktop(GUI) is showing my user logged in. I feel if we are able to remove the proxy from docker info, it might solve the problem.
I apparently solved it with this change:
Before:
After:
This is weird stuff according to me since we are disabling the manual proxy configs it shouldn't go inside it, but even after restarting and stopping the services it didn't work. So eventually I removed all the proxy url(despite manual proxy being off) and then it worked. Just windows stuff I guess.

Docker service tasks stuck in preparing state after reboot on windows

Restarting a windows server that is a swarm worker, causes windows containers to get stuck in a "Preparing" state indefinitely once the server and docker daemon are back online.
Image of tasks/containers stuck in preparing state:
https://user-images.githubusercontent.com/4528753/65180353-4e5d6e80-da22-11e9-8060-451150865177.png
Steps to reproduce the issue:
Create a swarm (in my case I have CentOS7 managers, and a few windows server 1903 workers)
Create a "global" docker service that only runs on the windows machines. They should start up fine
initially and work just fine.
Drain one or more of the windows nodes that is running the windows container(s) from step 2 (docker node update --availability=drain nodename)
Restart one or more of the nodes that were drained in step 3, wait for them to come back up
Set the windows node(s) back to active (docker node update --availability=active nodename)
At this point, just observe that the docker service created in step 2 will be "Preparing" the containers to start up on these nodes, and there it will stay (docker service ps servicename --no-trunc) -- you can observe this and run these commands from any master node
memberlist: Refuting a suspect message (from: c9347e85405d)
memberlist: Failed to send ping: write udp 10.60.3.40:7946->10.60.3.110:7946: wsasendto: The requested address is not valid in its
context.
grpc: addrConn.createTransport failed to connect to {10.60.3.110:2377 0 <nil>}. Err :connection error: desc = "transport: Error while
dialing dial tcp 10.60.3.110:2377: connectex: A socket operation was attempted to an unreachable host.". Reconnecting... [module=grpc]
memberlist: Failed to send ping: write udp 10.60.3.40:7946->10.60.3.186:7946: wsasendto: The requested address is not valid in its
context.
grpc: addrConn.createTransport failed to connect to {10.60.3.110:2377 0 <nil>}. Err :connection error: desc = "transport: Error while
dialing dial tcp 10.60.3.110:2377: connectex: A socket operation was attempted to an unreachable host.". Reconnecting... [module=grpc]
agent: session failed [node.id=wuhifvg9li3v5zuq2xu7c6hxa module=node/agent error=rpc error: code = Unavailable desc = all SubConns are
in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp 10.60.3.69:2377:
connectex: A socket operation was attempted to an unreachable host." backoff=6.3s]
Failed to send gossip to 10.60.3.110: write udp 10.60.3.40:7946->10.60.3.110:7946: wsasendto: The requested address is not valid in its
context.
Failed to send gossip to 10.60.3.69: write udp 10.60.3.40:7946->10.60.3.69:7946: wsasendto: The requested address is not valid in its
context.
Failed to send gossip to 10.60.3.105: write udp 10.60.3.40:7946->10.60.3.105:7946: wsasendto: The requested address is not valid in its
context.
Failed to send gossip to 10.60.3.69: write udp 10.60.3.40:7946->10.60.3.69:7946: wsasendto: The requested address is not valid in its
context.
Failed to send gossip to 10.60.3.186: write udp 10.60.3.40:7946->10.60.3.186:7946: wsasendto: The requested address is not valid in its
context.
Failed to send gossip to 10.60.3.105: write udp 10.60.3.40:7946->10.60.3.105:7946: wsasendto: The requested address is not valid in its
context.
Failed to send gossip to 10.60.3.186: write udp 10.60.3.40:7946->10.60.3.186:7946: wsasendto: The requested address is not valid in its
context.
Failed to send gossip to 10.60.3.69: write udp 10.60.3.40:7946->10.60.3.69:7946: wsasendto: The requested address is not valid in its
context.
Failed to send gossip to 10.60.3.105: write udp 10.60.3.40:7946->10.60.3.105:7946: wsasendto: The requested address is not valid in its
context.
Failed to send gossip to 10.60.3.109: write udp 10.60.3.40:7946->10.60.3.109:7946: wsasendto: The requested address is not valid in its
context.
Failed to send gossip to 10.60.3.69: write udp 10.60.3.40:7946->10.60.3.69:7946: wsasendto: The requested address is not valid in its
context.
Failed to send gossip to 10.60.3.110: write udp 10.60.3.40:7946->10.60.3.110:7946: wsasendto: The requested address is not valid in its
context.
memberlist: Failed to send gossip to 10.60.3.105:7946: write udp 10.60.3.40:7946->10.60.3.105:7946: wsasendto: The requested address is
not valid in its context.
memberlist: Failed to send gossip to 10.60.3.186:7946: write udp 10.60.3.40:7946->10.60.3.186:7946: wsasendto: The requested address is
not valid in its context.
Many of these errors are odd, for example... 7946 is totally open between the cluster nodes, telnets confirm this.
I expect to see the docker service containers start promptly, and not stuck in a Preparing state. The docker image is already pulled, it should be fast.
docker version output
Client: Docker Engine - Enterprise
Version: 19.03.2
API version: 1.40
Go version: go1.12.8
Git commit: c92ab06ed9
Built: 09/03/2019 16:38:11
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Enterprise
Engine:
Version: 19.03.2
API version: 1.40 (minimum version 1.24)
Go version: go1.12.8
Git commit: c92ab06ed9
Built: 09/03/2019 16:35:47
OS/Arch: windows/amd64
Experimental: false
docker info output
Client:
Debug Mode: false
Plugins:
cluster: Manage Docker clusters (Docker Inc., v1.1.0-8c33de7)
Server:
Containers: 4
Running: 0
Paused: 0
Stopped: 4
Images: 4
Server Version: 19.03.2
Storage Driver: windowsfilter
Windows:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics l2bridge l2tunnel nat null overlay transparent
Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
Swarm: active
NodeID: wuhifvg9li3v5zuq2xu7c6hxa
Is Manager: false
Node Address: 10.60.3.40
Manager Addresses:
10.60.3.110:2377
10.60.3.186:2377
10.60.3.69:2377
Default Isolation: process
Kernel Version: 10.0 18362 (18362.1.amd64fre.19h1_release.190318-1202)
Operating System: Windows Server Datacenter Version 1903 (OS Build 18362.356)
OSType: windows
Architecture: x86_64
CPUs: 4
Total Memory: 8GiB
Name: SWARMWORKER1
ID: V2WJ:OEUM:7TUQ:WPIO:UOK4:IAHA:KWMN:RQFF:CAUO:LUB6:DJIJ:OVBX
Docker Root Dir: E:\docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: this node is not a swarm manager - check license status on a manager node
Additional Details
These nodes are not using Docker Desktop for windows. I am provisioning docker on the box primarily based on the powershell instructions here: https://docs.docker.com/install/windows/docker-ee/
Windows firewall is disabled
iptables/firewalld is disabled
Communication is completely open between the cluster nodes
Totally up-to-date on cumulative updates
I posted on the moby repo issues but never heard a peep:
https://github.com/moby/moby/issues/39955
The ONLY way I've found to temporarily fix the issue is to drain the node from the swarm, delete docker files, reinstall windows "Containers" feature, then rejoin to the swarm. But, it happens again on reboot.
What's interesting is that when I see a swarm task in a "Preparing" state on the windows worker, the server doesn't seem to be doing anything at all, it's like the manager thinks the worker is preparing the container, but it isn't...
Anyone have any suggestions??

Processes are running slow in Docker container on Ubuntu 18.04

Processes are taking time when running them in a Docker container on an Ubuntu 18 machine. But the same process with the same Docker version is running fine on an Ubuntu 16 machine.
I have a node application listening on some port. Accepting get requests on the path "/" and "/docker" which simply runs a command "whoami" in the host machine and in a Docker container respectively and returns the result. The same node application with the same Docker container is running on both the machines (Ubuntu 16 and Ubuntu 18).
Firstly, I tried sending 20 concurrent get requests with path "/" to both the machines. And both the machines executed the command in an average of
35-40ms.
Secondly, I tried sending 20 concurrent get requests with path "/docker" to both the machines. Here, the Ubuntu 16 machine took a maximum of 4.3 seconds and an average of 3 seconds. But the Ubuntu 18 machine takes a maximum of 10 seconds and an average of 9 seconds.
I tried the above test multiple times and concluded that when running the process inside Docker, the time taken to execute is almost double in the Ubuntu 18 machine compared to Ubuntu 16.
I checked the following:
I tried monitoring through top and htop while hitting 20 requests. But everything seems the same there.
Also tried monitoring using perf command. But unable to find any unusual difference there. But I am not very used to perf command and so unable to understand clearly.
While these 20 requests were in processing. I run the same Docker command manually with strace. And found random results i.e. sometimes time taken in clock_gettime or futex (FUTEX_WAIT) or sometimes in +++ exited with 0 +++ message on Ubuntu 18, but it took less time on Ubuntu 16.
Below are the different configurations and code snippets I am using and running:
Machine1: Giving better performance.
node v10.16.0
npm 6.9.0
docker 18.09.8
ubuntu 16.04.3 LTS, xenial
Machine2: Giving poor performance.
node v10.16.0
npm 6.9.0
docker 18.09.8
ubuntu 18.04.2 LTS, bionic
Node application code snippet:
// for path "/docker"
var excuteInDocker = function() {
var cmd = "docker";
var args = ["exec", "ubuntu", "whoami"];
return executeCmd(cmd, args);
}
// for path "/"
var execute = function(){
var cmd = 'whoami';
var args = [];
return executeCmd(cmd, args);
}
Output of docker info which are common to both ubuntu 16 and 18:
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 2
Server Version: 18.09.8
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host 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: 894b81a4b802e4eb2a91d1ce216b8817763c29fb
runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f
init version: fec3683
Security Options:
apparmor
seccomp
Profile: default
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.296GiB
Name: myhostname
ID: LLLO:OMTS:PNNM:T3MP:AD2F:UMDG:IIZK:OGBO:3ZLL:YDBX:ONAO:AY5G
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 27
Goroutines: 42
System Time: 2019-07-25T15:25:54.991694211+05:30
EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
WARNING: No swap limit support
docker info specific to Ubuntu 16:
Kernel Version: 4.4.0-112-generic
Operating System: Ubuntu 16.04.3 LTS
Total Memory: 7.303GiB
ID: FOFI:RW7N:RZSP:HHKH:BKS3:LMWL:TC2J:W7V2:222Y:Q2AU:XMU3:KLU7
docker info specific to Ubuntu 18:
Kernel Version: 4.15.0-1040-aws
Operating System: Ubuntu 18.04.2 LTS
Total Memory: 7.296GiB
ID: LLLO:OMTS:PNNM:T3MP:AD2F:UMDG:IIZK:OGBO:3ZLL:YDBX:ONAO:AY5G
Ubuntu 16 machine Data:
1. Data of time taken in execution
2019-07-25 14:06:42.851 INFO uid: 540ae880-aeb7-11e9-919d-dd32b3cf84d5 time: 475 result: {"success":true,"data":"root"}
2019-07-25 14:06:43.183 INFO uid: 54145e60-aeb7-11e9-919d-dd32b3cf84d5 time: 745 result: {"success":true,"data":"root"}
2019-07-25 14:06:45.711 INFO uid: 540c4810-aeb7-11e9-919d-dd32b3cf84d5 time: 3326 result: {"success":true,"data":"root"}
.
.
.
2019-07-25 14:06:46.835 INFO uid: 541d5f10-aeb7-11e9-919d-dd32b3cf84d5 time: 4338 result: {"success":true,"data":"root"}
Logs of command strace -t docker exec ubuntu whoami:
Result of perf top --sort comm,dso:
Ubuntu 18 machine Data:
1. Data of time taken in execution:
2019-07-25 14:07:32.559 INFO uid: 715a6af0-aeb7-11e9-a5a9-2fffd4e800d1 time: 1008 result: {"success":true,"data":"root"}
2019-07-25 14:07:32.941 INFO uid: 7178c860-aeb7-11e9-a5a9-2fffd4e800d1 time: 1191 result: {"success":true,"data":"root"}
2019-07-25 14:07:40.363 INFO uid: 71767e70-aeb7-11e9-a5a9-2fffd4e800d1 time: 8628 result: {"success":true,"data":"root"}
.
.
.
2019-07-25 14:07:41.970 INFO uid: 718af0d0-aeb7-11e9-a5a9-2fffd4e800d1 time: 10101 result: {"success":true,"data":"root"}
Logs of command strace -t docker exec ubuntu whoami:
result of perf top --sort comm,dso:
So, I need help in debugging what is wrong with Docker on the Ubuntu 18 machine. Or if there is any limitation with Docker on Ubuntu 18 or maybe some machine or Docker configuration issue.
I did not encounter such a problem on my desktop, but mysql container was running very slowly in a way that I could not understand on my ubuntu laptop. This solution solved my problem.

Issue: Error while running ubuntu bash shell in docker

I am running docker on my arm based 32 bit device.
However, when i try to run an ubuntu bash shell as a docker container via the command : docker run -it ubuntu bash , I keep getting the following error:
docker: Error response from daemon: OCI runtime create failed:
container_linux.go:348: starting container process caused
"process_linux.go:402: container init caused \"open /dev/ptmx: no such file or directory\"": unknown.
Here's what docker info gives:
Containers: 4
Running: 0
Paused: 0
Stopped: 4
Images: 3
Server Version: 18.06.1-ce
Storage Driver: vfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
seccomp
Profile: default
Kernel Version: 3.10.65-00273-gfa38327-dirty
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 923MiB
ID: 2PDV:3KHU:VZZM:DM6F:4MVR:TXBN:35YJ:VWP5:TMHD:GMKW:TPMI:MALC
Docker Root Dir: /opt/usr/media/docker_workdir
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
It would be great if someone could tell me what's wrong and how can I fix this ?
It could be that, for one reason or another, your docker container can't find its own /dev/ptmx or even perhaps your /dev/ altogether.
One quick solution is to do:
docker run -it -v /dev:/dev ubuntu bash
This binds your /dev/ directory to the container's, meaning that they will use the same files.
Notice that, although in of itself this operation is harmless, in production environments this means that the isolation between the host's and the container's devices is gone.
For that reason, make sure to only ever use this trick in test environments.
It looks like your OS is missing pseudo-terminals (PTY) - a device that has the functions of a physical terminal without actually being one.
The file /dev/ptmx is a character file with major number 5
and minor number 2, usually of mode 0666 and owner.group
of root.root. It is used to create a pseudo-terminal mas­ter and slave pair.
FILES
/dev/ptmx - UNIX 98 master clone device
/dev/pts/* - UNIX 98 slave devices
/dev/pty[p-za-e][0-9a-f] - BSD master devices
/dev/tty[p-za-e][0-9a-f] - BSD slave devices
Reference: http://man7.org/linux/man-pages/man7/pty.7.html
This is by default included into Linux kernel. Maybe lack of it is somehow related to your OS architecture. Also, I'm not sure how can you fix, maybe try to update && upgrade OS.
Quick workaround if you don't need a tty would be to skip -t flag:
docker run -i ubuntu bash
In docker run -it, -i/--interactive means "keep stdin open" and -t/--tty means "tell the container that stdin is a pseudo tty". The key here is the word "interactive". If you omit the flag, the container still executes /bin/bash but exits immediately. With the flag, the container executes /bin/bash then patiently waits for your input. That means now you will have bash session inside the container, so you can ls, mkdir, or do any bash command inside the container.
one workable fix:
docker exec -i hello-world rm /dev/ptmx
docker exec -i hello-world mknod /dev/ptmx c 5 2
or enable kernel config: CONFIG_DEVPTS_MULTIPLE_INSTANCES=y

Resources