I need to start dockerd during system boot in Fedora 25.
I have installed docker-engine in Fedora 25 Server Edition.
Docker version:
Client:
Version: 1.13.0
API version: 1.25
Go version: go1.7.3
Git commit: 49bf474
Built: Tue Jan 17 09:58:06 2017
OS/Arch: linux/amd64
Server:
Version: 1.13.0
API version: 1.25 (minimum version 1.12)
Go version: go1.7.3
Git commit: 49bf474
Built: Tue Jan 17 09:58:06 2017
OS/Arch: linux/amd64
Experimental: false
I have stored docker file via custom location, so i used to start dockerd for below method
dockerd -g /u01/docker
I see this init scripts init1 and init2 But, they only start the docker, i need to start dockerd with custom location
Like:
dockerd -g /u01/docker
How can I change that github init script, or can you suggest how to write a new one?
I find out solution myself
I find out default docker.service file and change to our custom location path
I added this line ExecStart=/usr/bin/dockerd -g /u01/docker instead of ExecStart=/usr/bin/dockerd
docker.service:
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target firewalld.service
[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -g /u01/docker
ExecReload=/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
#TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process
[Install]
WantedBy=multi-user.target
After that I run
sytemctl daemon-reload
systemctl enable docker.service
systemctl start docker.service
Now, docker start while system boot.
Related
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
I could be missing something ridiculous, but every docker container I have tried to expose to my host machine (Mac) doesn't seem to work. I can tell that the containers are running and appear to have properly been exposed to the port I chose. Am I missing something obvious? Any help would be greatly appreciated.
I pulled down latest ElasticSearch image: https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html
Run Docker:
docker run -d -p 9200:9200 docker.elastic.co/elasticsearch/elasticsearch:5.4.0
Request to see running images:
docker ps
View running image:
5e8ae3b13f7c docker.elastic.co/elasticsearch/elasticsearch:5.4.0 "/bin/bash bin/es-..." 4 seconds ago Up 4 seconds 0.0.0.0:9200->9200/tcp, 9300/tcp eloquent_almeida
Run lsof to see if anything exposed on port 9200
lsof -i tcp:9200
Nothing returned
Mac OS: 10.12.4
Docker Updated Version:
docker version
Client:
Version: 17.04.0-ce
API version: 1.27 (downgraded from 1.28)
Go version: go1.7.5
Git commit: 4845c56
Built: Wed Apr 5 23:33:17 2017
OS/Arch: darwin/amd64
Server:
Version: 17.03.1-ce
API version: 1.27 (minimum version 1.12)
Go version: go1.7.5
Git commit: c6d412e
Built: Mon Mar 27 16:58:30 2017
OS/Arch: linux/amd64
Experimental: false
Downloaded nmap and ran against 9200 localhost. Also made sure 9200 is open now in /etc/pf.conf.
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00016s latency).
Other addresses for localhost (not scanned): ::1
PORT STATE SERVICE
9200/tcp closed wap-wsp
Also tried using docker-machine on mac's IP:
docker-machine ip default
192.168.99.100
Tried 192.168.99.100:9200 and still no luck
You know, it looks like something is wrong with downloaded image or docker installation. I repeated your steps - all is Ok:
[06:40 PM] borlaze#mac: /tmp $ docker run -d -p 9200:9200 docker.elastic.co/elasticsearch/elasticsearch:5.4.0
[06:41 PM] borlaze#mac: /tmp $ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fd05a1fe9b5a docker.elastic.co/elasticsearch/elasticsearch:5.4.0 "/bin/bash bin/es-..." 9 seconds ago Up 7 seconds 0.0.0.0:9200->9200/tcp, 9300/tcp practical_bell
[06:41 PM] borlaze#mac: /tmp $ lsof -i tcp:9200
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
com.docke 32108 borlaze 21u IPv4 0x601aa3189a6fc3e3 0t0 TCP *:wap-wsp (LISTEN)
com.docke 32108 borlaze 22u IPv6 0x601aa318a167e6cb 0t0 TCP localhost:wap-wsp (LISTEN)
Checked on OS 10.12.4, docker
[06:45 PM] borlaze#mac: /tmp $ docker version
Client:
Version: 17.03.1-ce
API version: 1.27
Go version: go1.7.5
Git commit: c6d412e
Built: Tue Mar 28 00:40:02 2017
OS/Arch: darwin/amd64
Server:
Version: 17.03.1-ce
API version: 1.27 (minimum version 1.12)
Go version: go1.7.5
Git commit: c6d412e
Built: Fri Mar 24 00:00:50 2017
OS/Arch: linux/amd64
Experimental: true
Try to remove image and repeat.
I simply run the following command:
docker run -d -p 80:80 --name webserver nginx
and after pulling all images returns this error:
docker: Error response from daemon: driver failed programming external
connectivity on endpoint webserver
(ac5719bc0e95ead1a4ec6b6ae437c4c0b8a9600ee69ecf72e73f8d2d12020f97):
Error starting userland proxy: Bind for 0.0.0.0:80: unexpected error
(Failure EADDRINUSE).
Here is my docker Version info:
Client:
Version: 1.12.0
API version: 1.24
Go version: go1.6.3
Git commit: 8eab29e
Built: Thu Jul 28 21:15:28 2016
OS/Arch: darwin/amd64
Server:
Version: 1.12.0
API version: 1.24
Go version: go1.6.3
Git commit: 8eab29e
Built: Thu Jul 28 21:15:28 2016
OS/Arch: linux/amd64
How to fix this?
You didn't provide informations such as Docker version, system or docker processes running so I assume the most likely situation.
The output contains: Failure EADDRINUSE. It means that port 80 is used by something else. You can use lsof -i TCP:80 to check which process is listening on that port. If there is nothing running on the port, it might be some issue with Docker. For example the one with not releasing ports immediately.
I run a docker cluster with a few thousand containers and a few times per day randomly I have a process that gets "stuck" blocking a container from stopping. Below is an example container with its corresponding process and all things I have tried to kill the container / process.
The container:
# docker ps | grep 950677e2317f
950677e2317f 7e553d1d9f6f "/bin/sh -c /minecraf" 2 days ago Up 2 days 0.0.0.0:22661->22661/tcp, 0.0.0.0:22661->22661/udp, 0.0.0.0:37681->37681/tcp, 0.0.0.0:37681->37681/udp gloomy_jennings
Try to stop container using docker daemon (it tries forever without result):
# time docker stop --time=1 950677e2317f
^C
real 0m13.508s
user 0m0.036s
sys 0m0.008s
Daemon log while trying to stop:
# journalctl -fu docker.service
-- Logs begin at Fri 2015-12-11 15:40:55 CET. --
Dec 31 23:30:33 m3561.contabo.host docker[9988]: time="2015-12-31T23:30:33.164731953+01:00" level=info msg="POST /v1.21/containers/950677e2317f/stop?t=1"
Dec 31 23:30:34 m3561.contabo.host docker[9988]: time="2015-12-31T23:30:34.165531990+01:00" level=info msg="Container 950677e2317fcd2403ef5b5ffad37204e880136e91f76b0a8682e04a93e80942 failed to exit within 1 seconds of SIGTERM - using the force"
Dec 31 23:30:44 m3561.contabo.host docker[9988]: time="2015-12-31T23:30:44.165954266+01:00" level=info msg="Container 950677e2317f failed to exit within 10 seconds of kill - trying direct SIGKILL"
Looking into the processes running on the machine reveals the zombie process (pid 11991 on host machine):
# ps aux | grep [1]1991
root 11991 84.3 0.0 5836 132 ? R Dec30 1300:19 bash -c (echo stop > /tmp/minecraft &)
# top -b | grep [1]1991
11991 root 20 0 5836 132 20 R 89.5 0.0 1300:29 bash
And it is indeed a process running within our container (check container id):
# cat /proc/11991/mountinfo
...
/var/lib/docker/containers/950677e2317fcd2403ef5b5ffad37204e880136e91f76b0a8682e04a93e80942/resolv.conf /etc/resolv.conf rw,relatime - ext4 /dev/sda2 rw,errors=remount-ro,data=ordered
Trying to kill the process yields nothing:
# kill -9 11991
# ps aux | grep [1]1991
root 11991 84.3 0.0 5836 132 ? R Dec30 1303:58 bash -c (echo stop > /tmp/minecraft &)
Some overview data:
# docker version
Client:
Version: 1.9.1
API version: 1.21
Go version: go1.4.2
Git commit: a34a1d5
Built: Fri Nov 20 13:20:08 UTC 2015
OS/Arch: linux/amd64
Server:
Version: 1.9.1
API version: 1.21
Go version: go1.4.2
Git commit: a34a1d5
Built: Fri Nov 20 13:20:08 UTC 2015
OS/Arch: linux/amd64
# docker info
Containers: 189
Images: 322
Server Version: 1.9.1
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 700
Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.0-19-generic
Operating System: Ubuntu 15.10
CPUs: 24
Total Memory: 125.8 GiB
Name: m3561.contabo.host
ID: ZM2Q:RA6Q:E4NM:5Q2Q:R7E4:BFPQ:EEVK:7MEO:YRH6:SVS6:RIHA:3I2K
# uname -a
Linux m3561.contabo.host 4.2.0-19-generic #23-Ubuntu SMP Wed Nov 11 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
If stopping the docker daemon the process still lives. The only way to get rid of the process is to restart the host machine. As this happens fairly frequently (requires every node to restart every 3-7 days) it has a serious impact on the uptime of the overall cluster.
Any ideas on what to do here?
Okay, I think I found the root cause of this. The folks over at Docker helped me out, check out this thread on GitHub.
It turns out this most likely is a bug in the Linux Kernel 4.19+. I'll be rolling back to an older version until it is fixed.
UPDATE: I've been running 3.* only in my cluster for several days now without any issues. This was most certainly a kernel bug.
I had a similar problem and switching to use overlay2 storage driver made the problem go away. Changing the storage driver will loose all docker state (images & containers). It seems that the aufs storage driver has some problems that might be a source of lock ups.
I'm traing to set up docker swarm over my virtual cluster. First, I try to install the swarm-master on the localhost with docker-machine.
The problem is that the machine need to use a proxy to access the discovery token.
First I ask a token with swarm create. To do that, I created this file :
$cat /etc/systemd/system/docker.service.d/http_proxy.conf
[Service]
Environment="HTTP_PROXY=http://**.**.**.**:3128/" "HTTPS_PROXY=http://**.**.**.**:3128/" "NO_PROXY=localhost,127.0.0.1,192.168.2.100,192.168.2.101,192.168.2.102,192.168.2.103,192.168.2.104,192.168.2.105,192.168.2.106,192.168.2.107,192.168.2.108,192.168.2.194,192.168.2.110"
I restarted the daemon and I can pull the swarm image :
$docker run -e "http_proxy=http://**.**.**.**:3128/" -e "https_proxy=http://**.**.**.**:3128/" swarm create
b54d8665e72939d2c611d8f9e99521b4
After I want to create the swarm master :
$docker-machine create -d generic --generic-ip-address localhost \
--engine-env HTTP_PROXY=http://192.168.254.10:3128/ \
--engine-env HTTPS_PROXY=http://192.168.254.10:3128/ \
--engine-env NO_PROXY=localhost,192.168.2.102,192.168.2.100 \
--swarm --swarm-master --swarm-discovery \
token://b54d8665e72939d2c611d8f9e99521b4 swarm-master
Result :
Running pre-create checks...
Creating machine...
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Provisioning created instance...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Configuring swarm...
To see how to connect Docker to this machine, run: docker-machine env swarm-master
And I have errors in the logs of the join and manage container (I think the error come because the containers don't take care of the proxy) :
$docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6fbf967cdb60 swarm:latest "/swarm join --advert" 53 seconds ago Up 52 seconds 2375/tcp swarm-agent
8b176116989e swarm:latest "/swarm manage --tlsv" 54 seconds ago Up 53 seconds 2375/tcp, 0.0.0.0:3376->3376/tcp swarm-agent-master
$docker logs 6fbf967cdb60
time="2015-11-17T19:37:21Z" level=info msg="Registering on the discovery service every 20s..." addr="localhost:2376" discovery="token://b54d8665e72939d2c611d8f9e99521b4"
time="2015-11-17T19:37:41Z" level=error msg="Post https://discovery.hub.docker.com/v1/clusters/b54d8665e72939d2c611d8f9e99521b4?ttl=60: dial tcp: lookup discovery.hub.docker.com on 8.8.4.4:53: read udp 172.17.0.3:46576->8.8.4.4:53: i/o timeout"
$docker logs 8b176116989e
time="2015-11-17T19:37:20Z" level=info msg="Listening for HTTP" addr="0.0.0.0:3376" proto=tcp
time="2015-11-17T19:37:40Z" level=error msg="Discovery error: Get https://discovery.hub.docker.com/v1/clusters/b54d8665e72939d2c611d8f9e99521b4: dial tcp: lookup discovery.hub.docker.com on 8.8.4.4:53: read udp 172.17.0.2:44241->8.8.4.4:53: i/o timeout"
Is it a bug of the generic driver ?
Some others informations :
# docker version
Client:
Version: 1.9.0
API version: 1.21
Go version: go1.4.2
Git commit: 76d6bc9
Built: Tue Nov 3 17:29:38 UTC 2015
OS/Arch: linux/amd64
Server:
Version: 1.9.0
API version: 1.21
Go version: go1.4.2
Git commit: 76d6bc9
Built: Tue Nov 3 17:29:38 UTC 2015
OS/Arch: linux/amd64
# docker info
Containers: 2
Images: 8
Server Version: 1.9.0
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 12
Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
CPUs: 2
Total Memory: 1000 MiB
Name: swarm-master
ID: 6SDE:CQRA:NM6W:TY2H:4DPB:O4YO:IGRT:33AA:OKQP:M6UK:EMSR:H4WR
WARNING: No memory limit support
WARNING: No swap limit support
Labels:
provider=generic
Thank you :)
The problem was that it's not possible to use docker machine to create the swarm-master on the same machine. So I created two VM, one with docker-machine (and mh-keystore) and one other for swarm-master.
Creating the mh-keystore on localhost :
$docker-machine create -d generic --generic-ip-address localhost mh-keystore
$docker $(docker-machine config mh-keystore) run -d \
-p "8500:8500" \
-h "consul" \
progrium/consul -server -bootstrap
$docker ps
Installation of swarm-master to the other machine
$ docker-machine create \
-d generic --generic-ip-address 192.168.2.100 \
--swarm --swarm-image="swarm" --swarm-master \
--swarm-discovery="consul://192.168.2.103:8500" \
swarm-master
Creation of agent :
$ docker-machine create \
-d generic --generic-ip-address 192.168.2.102 \
--swarm \
--swarm-discovery="consul://192.168.2.103:8500" \
swarm-agent-00