I installed docker from binaries on SLES 15 x86_64 (https://docs.docker.com/engine/install/binaries/#install-static-binaries). And now I need to configure boot on start up and rootless launch. But I have no docker.service. And I don't understand how to configure it manually.
Thank you.
Normally I'd suggest to enable Container Module 12 x86_64 (aka sle-module-containers/12/x86_64) as described here but I think you have your reasons for not using it.
You need to create the docker.service and docker.socket files in the /etc/systemd/system folder as described in the documentation.
docker.service content can found here and it's currently:
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service containerd.service
Wants=network-online.target containerd.service
Requires=docker.socket
[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 -H fd:// --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutStartSec=0
RestartSec=2
Restart=always
# Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
# Both the old, and new location are accepted by systemd 229 and up, so using the old location
# to make them work for either version of systemd.
StartLimitBurst=3
# Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
# Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
# this option work for either version of systemd.
StartLimitInterval=60s
# 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
# Comment TasksMax if your systemd version does not support it.
# Only systemd 226 and above support this option.
TasksMax=infinity
# 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
OOMScoreAdjust=-500
[Install]
WantedBy=multi-user.target
docker.socket can be found here and it's currently:
[Unit]
Description=Docker Socket for the API
[Socket]
# If /var/run is not implemented as a symlink to /run, you may need to
# specify ListenStream=/var/run/docker.sock instead.
ListenStream=/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker
[Install]
WantedBy=sockets.target
Related
I need to rename the docker.service to docker-ce.service. I know this is a bit unusual.
The reason being is I currently use kubespray to provision my kubernetes cluster and it installs containerd for me as the runtime. In addition to this, for some specific machines only, I also require docker to be installed on these machines. Kubespray is quite thorough when installing containerd as it goes ahead and uninstalls docker if it finds the service present. To overcome this, renaming the service of docker would work and allow kubespray to not uninstall it however this is proving quite troublesome.
Changing the service itself is simple, however the docker.socket no longer starts and errors with the following:
[root#vm01234 system]# systemctl status docker.socket
● docker.socket - Docker Socket for the API
Loaded: loaded (/usr/lib/systemd/system/docker.socket; enabled; vendor preset: disabled)
Active: inactive (dead)
Listen: /var/run/docker.sock (Stream)
Dec 09 16:47:04 vm01234 systemd[1]: docker.socket: Socket service docker.service not loaded, refusing.
Dec 09 16:47:04 vm01234 systemd[1]: Failed to listen on Docker Socket for the API.
Had a look through all the Docker docs and other threads but couldn't find anything. Hoping someone is able to help.
Running on RHEL 8.6.
For reference, here is are my service and socket files:
docker.socket
[Unit]
Description=Docker Socket for the API
[Socket]
ListenStream=/var/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker
[Install]
WantedBy=sockets.target
docker-ce.service
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service containerd.service
Wants=network-online.target
Requires=docker.socket containerd.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/local/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always
# Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
# Both the old, and new location are accepted by systemd 229 and up, so using the old location
# to make them work for either version of systemd.
StartLimitBurst=3
# Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
# Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
# this option work for either version of systemd.
StartLimitInterval=60s
# 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
# Comment TasksMax if your systemd version does not support it.
# Only systemd 226 and above support this option.
TasksMax=infinity
# 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
OOMScoreAdjust=-500
[Install]
WantedBy=multi-user.target
was able to solve the problem by adding a Service value to the [socket] block.
[Unit]
Description=Docker Socket for the API
[Socket]
ListenStream=/var/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker
Service=docker-ce.service
[Install]
WantedBy=sockets.target
We have some application that use Docker in Azure Vm (centos7). We use systemd in order to manage their lifecycle in case of failure. A typical example of this is this service unit:
[Unit]
Description=Service app-subs
After=docker.service
Requires=docker.service
[Service]
Environment="JAVA_OPTS=-XX:+UseContainerSupport -XX:MaxRAMPercentage=70 -XshowSettings:vm"
TimeoutStartSec=0
Restart=always
ExecStartPre=-/usr/bin/docker stop app-subs
ExecStartPre=-/usr/bin/docker rm app-subs
ExecStartPre=/usr/bin/docker login registry.azure.io -u USER -p PASSWORD
ExecStart=/usr/bin/docker run \
--init \
--rm \
-p 8236:8080 \
registry.azure.io /app-subs:0.2.22
[Install]
WantedBy=multi-user.target
We work like this for all our docker app since 2 year and we never had problem with this type of service and we do not make any update. Today one of our vm trigger this error:
Apr 11 04:46:20 vm22 systemd: Found dependency on docker.service/start
Apr 11 04:46:20 vm22 systemd: Breaking ordering cycle by deleting job app-subs.service/start
Apr 11 04:46:20 vm22 systemd: Job app-subs.service/start deleted to break ordering cycle starting with docker.service/start
This make the service inactive that launch our application. We don't make any change since a long time and do not update this service recently. So we tried to figure out why we have an "ordering cycle" in our systemd services with these commands:
sudo systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After app-subs.service
Result:
Requires=docker.service system.slice basic.target
Requisite=
Wants=
BindsTo=
PartOf=
Before=shutdown.target multi-user.target
After=basic.target docker.service systemd-journald.socket system.slice
Docker service:
sudo systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After docker.service
Result:
Requires=basic.target docker.socket containerd.service system.slice
Requisite=
Wants=network-online.target
BindsTo=
PartOf=
Before= shutdown.target app-subs.service
After=basic.target docker.socket network-online.target multi-user.target systemd-journald.socket system.slice firewalld.service containerd.service
If i understand well Docker have to be launch before app-subs.service but after multi-user.target and our app have to be launch before multi-user.target but after docker.service. But multi-user.target seem to be a step trigger by this in our services.
[Install]
WantedBy=multi-user.target
that allow our service to be launch at startup.
We have the same configuration in multiple machine and app. Only one machine trigger this error and i cannot find out what happened for this. The machine reboot in the night without explanation.
Does anyone have any idea what might have happened or how to make sure it doesn't happen again?
I have managed to install daemon service in /etc/systemd/system, however I am not sure about 2 things:
Whether the daemon services should reside there
How can I elegantly check whether a daemon service is installed or not in systemd?
1.If the daemon services should reside there
yes, it is the .service location. The file that you should put here is:
mydeamon.service
[Unit]
Description=ROT13 demo service
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
User=**YourUser**
ExecStart=**pathToYourScript**
[Install]
WantedBy=multi-user.target
You’ll need to:
set your actual username after User=
set the proper path to your script in ExecStart= (usually /usr/bin/ You can put your script here)
creating-a-linux-service-with-systemd
2.How can I elegantly check if a daemon service is installed or not in systemd?
systemctl has an is-active subcommand for this:
systemctl is-active --quiet service
will exit with status zero if service is active, non-zero otherwise, making it ideal for scripts:
systemctl is-active --quiet service && echo Service is running
test Service is running
Followed the documentation for Installing orientdb on Linux/Ubuntu on the following location, http://orientdb.com/docs/2.1/Unix-Service.html
Set the following variables : JAVA_HOME, JRE_HOME, ORIENTDB_HOME and the following changes in the below files,
orientdb.sh
#!/bin/sh
# OrientDB service script
#
# Copyright (c) Orient Technologies LTD (http://www.orientechnologies.com)
# chkconfig: 2345 20 80
# description: OrientDb init script
# processname: orientdb.sh
# You have to SET the OrientDB installation directory here
ORIENTDB_DIR="/local/some-location"
ORIENTDB_USER="some-user"
Installing for systemmd
/etc/systemd/system/orientdb.service
[Unit]
Description=OrientDB Server
After=network.target
After=syslog.target
[Install]
WantedBy=multi-user.target
[Service]
Type=forking
ExecStart=/local/some-location/bin/orientdb.sh start
ExecStop=/local/some-location/bin/orientdb.sh stop
ExecStatus=/local/some-location/bin/orientdb.sh status
It is possible to start the service by the following command
systemctl start orientdb.service
But the service will not stop after giving the following command
systemctl stop orientdb.service
Machine Info :
Java 8.0_31
Orientdb 2.1.12
Ubuntu 15.04 on Virtual Box VM
modify your service file according to this:
$ cat /etc/systemd/system/orientdb.service
[Unit]
Description=OrientDB Server
After=network.target
After=syslog.target
[Install]
WantedBy=multi-user.target
[Service]
User=<USER>
Group=<GROUP>
ExecStart=<ORIENTDB_INSTALL_PATH>/bin/server.sh
SuccessExitStatus=143
modifying with your user,group and path.
than reload the service systemctl daemon-reload
Using this is working for me on Fedora23.
Let me know.
Ivan
EDIT
Tried on Ubuntu 15.04 and it works.
There is an issue with shutdown on 2.1.x See: Joe Taras comment. You should update to the latest 2.2.x version.
The default DNS for Docker (e.g. 8.8.8.8) is blocked where I work, so I want to change the default. I've been able to do this using
$ docker daemon --dns <mydnsaddress>
but I want to do this using a systemd drop-in instead, since the official Docker docs recommend this way. I've made a /etc/systemd/system/docker.service.d/dns.conf file, and used things like this:
[Service]
DNS=<mydnsaddress>
But I just have no idea what the variable name is supposed to be. How do I set this? More importantly, is there a page that documents all config variables that can be used in systemd drop-ins for Docker?
(btw, this is Docker 1.9 on Ubuntu 15.10, although I don't suspect any bugs)
All .conf files in /etc/systemd/system/docker.service.d overrule the settings from the /usr/lib/systemd/system/docker.service file, which is almost what you tried.
Instead of putting a DNS=.. line in, you need to copy the ExecStart= part from the /usr/lib/systemd/system/docker.service file to dns.conf (or mydocker.conf). Add --dns $ip after the daemon part of the ExecStart. E.g.:
[Service]
ExecStart=
ExecStart=/usr/bin/docker daemon --dns 192.168.1.1 -H fd://
Where the 192.168.1.1 is the ip of the dns server.
Now restart docker via systemctl and docker should now restart with your own dns. (Checkable via systemctl status docker.service | grep dns).
Note that the empty ExecStart= is required, as systemctl only will overrule the ExecStart if it is cleared first.
Also note that a systemctl daemon-reload is needed after editing files in /etc/systemd/system/.
Last remark is that on some systems docker.service is not located in /usr/lib/systemd/system/, but in /lib/systemd/system/.
Yes I agreed to previous answer given by #steviethecat but this changes overwrite to default when docker restart so I followed below steps. Using Docker version 18.09.2,
I followed link https://success.docker.com/article/using-systemd-to-control-the-docker-daemon
sudo systemctl edit docker //this opens new file use as overwrite file.
add below lines. Make sure you have ExecStart= before setting this value. Above given link having details.
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd --dns 192.168.1.1 -H fd://
once above lines added to file, execute below lines.
sudo systemctl daemon-reload
systemctl restart docker
systemctl status docker