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
Related
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 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
I am using systemd services on an embedded system. I have a web service that needs to restart bluetooth everytime it restarts. How do I write the unit file for this. Also the service I have is put into systemd/user and not systemd/system.
I tried using PartOf=bluetooth.service but that didn't work.
[Unit]
# Human readable name of the unit
Description=Python User Service
#Link it to bluetooth
After=bluetooth.service
Requires=bluetooth.service
PartOf=bluetooth.service
[Service]
# Command to execute when the service is started
ExecStart=/usr/bin/python3 /home/root/MyServ.py
# Disable Python's buffering of STDOUT and STDERR, so that output from the
# service shows up immediately in systemd's logs
Environment=PYTHONUNBUFFERED=1
# Automatically restart the service if it crashes
Restart=on-failure
# Our service will notify systemd once it is up and running
#Type=notify
Type=simple
# Use a dedicated user to run our service
User=root
[Install]
# Tell systemd to automatically start this service when the system boots
# (assuming the service is enabled)
WantedBy=default.target
On [Unit] section you can reload services
PropagatesReloadTo=, ReloadPropagatedFrom=
A space-separated list of one or more units where reload requests on this unit will be propagated to, or reload requests on the
other unit will be propagated to this unit, respectively. Issuing a
reload request on a unit
will automatically also enqueue a reload request on all units that the reload request shall be propagated to via these two settings.
It sends bluetoothd command to reload via dbus. Not kill daemon, just reread configuration.
Or on [Service] section
ExecStopPost=/usr/bin/systemctl restart bluetooth.service
Or use override.conf on bluetooth.service
systemctl edit bluetooth.service
And here put
[Unit]
BindsTo=MyServ.service
All my unix host use the ldap backend.
docker group is existing on the ldap, this is also why docker.service must start after nslcd.service.
I have tried to edit systemctl startup configuration for docker.service:
$ sudo systemctl edit --full docker.service
And I add nslcd.service to After, Wants, Requires:
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service nslcd.service
Wants=network-online.target nslcd.service
Requires=docker.socket nslcd.service
I still can't get docker to run after that service:
sudo service docker status
● docker.service - Docker Application Container Engine
Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Docs: https://docs.docker.com
Oct 10 19:35:02 dev-08 systemd[1]: Dependency failed for Docker Application Container Engine.
There is no problem to start container manually after starts, since I login through ldap.
docker group is existing on the ldap, this is also why docker.service must start after nslcd.service.
It is generally a bad idea to have system services depend on users and groups in a remote directory service (because problems with the directory service can impact service availability on your host).
And I add nslcd.service to After, Wants, Requires
Specifying both a Wants= and a Requires= relationship is redundant. The Requires= relationship is simply a stronger version of Wants=: using Requires= means that if you start the docker service, and nslcd is not already running, it will be started as well. Using Wants= in the same situation, docker would start without starting nslcd.
I still can't get docker to run after that service
Is is entirely likely that nslcd takes a moment to connect to the directory service. In this case, it's possible that the process has started, which satisfies the After= dependency, so docker starts even though your groups are not yet available.
There are a few ways of addressing this situation:
In light of my initial comment, just create a local docker group. This is by far the simplest and most robust solution.
Create a new oneshot unit that spins until the docker group exists. Make this unit depend on nslcd, and make docker depend on the new unit.
Possibly replacing nslcd with something that implements local caching (e.g., sssd) would also resolve this problem.
On a different note, it is a bad idea to directly edit the unit files as you have done in this example, because if you've installed Docker via packaging tools (apt/yum/etc), your modifications will be overwritten next time you upgrade the package. A better solution is to create drop-in files to augment the unit configuration.
Update
Option 2 might look like this:
[Unit]
Requires=nslcd.service docker.service
After=nslcd.service
Before=docker.service
[Service]
Type=oneshot
ExecStart=/bin/sh -c "while ! getent group docker; do sleep 1; done"
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