kotovalexarian-likes-github/moby--moby
1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Code Releases Activity
moby--moby/contrib/init/systemd/docker.service

48 lines
1.7 KiB
SYSTEMD
Raw Normal View History

Add initial init scripts library, including systemd, sysvinit, upstart, and openrc
2013-10-15 09:37:18 -06:00
[Unit]
ExecStartPre commands updated Docker-DCO-1.1-Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com> (github: lsm5) systemd service no longer does '/bin/mount/ --make-rprivate /'. Core issue fixed by Alex Larsson (commit 157d99a). ip forwarding enabled.
2014-01-09 12:09:25 -05:00
Description=Docker Application Container Engine
Fix docs URL in systemd service file. Fixes #13799. Signed-off-by: Eric-Olivier Lamey <eo@lamey.me>
2015-06-08 10:14:35 +00:00
Documentation=https://docs.docker.com
Merge remote-tracking branch 'packaging_tmp/master' into upstream_systemd_units Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2021-05-12 11:57:21 +02:00
After=network-online.target docker.socket firewalld.service containerd.service
Move containerd.service from Requires= to Wants= Per the systemd.unit documentation: > If this unit gets activated, the units listed will be activated as well. If one of the other units fails to activate, and an ordering dependency After= on the failing unit is set, this unit will not be started. Besides, with or without specifying After=, this unit will be stopped if one of the other units is explicitly stopped. > > Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services. This should also be generally "safe" given we added `--containerd=/run/containerd/containerd.sock` to the flags we pass to `dockerd`. Signed-off-by: Tianon Gravi <admwiggin@gmail.com> Signed-off-by: Anca Iordache <anca.iordache@docker.com>
2020-12-04 16:45:40 -08:00
Wants=network-online.target containerd.service
Requires=docker.socket
Add initial init scripts library, including systemd, sysvinit, upstart, and openrc
2013-10-15 09:37:18 -06:00
[Service]
systemd: set service type to notify. Currently the service type is 'simple', the default, meaning that docker.service is considered to be started straight after spawning. This is incorrect as there is significant amount of time between spawning and docker ready to accept connections on the passed sockets. Docker does implement systemd socket activate and notification protocol, and send the ready signal to systemd, once it is ready. However for systemd to take those notifications into account, the service file type should be set to notify. Signed-off-by: Dimitri John Ledkov <dimitri.j.ledkov@intel.com>
2015-07-29 13:59:36 +01:00
Type=notify
Add "Delegate=yes" to docker's service file We need to add delegate yes to docker's service file so that it can manage the cgroups of the processes that it launches without systemd interfering with them and moving the processes after it is reloaded. ``` Delegate= Turns on delegation of further resource control partitioning to processes of the unit. For unprivileged services (i.e. those using the User= setting), this allows processes to create a subhierarchy beneath its control group path. For privileged services and scopes, this ensures the processes will have all control group controllers enabled. ``` This is the proper fix for issue #20152 Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
2016-02-23 14:21:29 -08:00
# 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
systemd: set --containerd socket patch to prevent race-condition containerd is now running as a separate service, and should no longer be started as a managed child-process of dockerd. The dockerd service already specifies that it should be started `After` the containerd.service, but there is still a race condition, where containerd is started, but its socket is not yet created. In that situation, `dockerd` detects that the containerd socket is missing, and will start a new instance of containerd (as a managed child-process), which causes live-restore to fail. This patch explicitly sets the `--containerd` daemon option. If this option is set, `dockerd` will not start a new instance of containerd. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2019-02-11 14:28:03 +01:00
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
Add support for reloading daemon configuration through systemd This adds support for reloading the docker daemon (SIGHIUP) so that changes in '/etc/docker/daemon.json' can be loaded at runtime by reloading the service through systemd ('systemctl reload docker') Before this change, systemd would output an error that "reloading" is not supported for the docker service; systemctl reload docker Failed to reload docker.service: Job type reload is not applicable for unit docker.service. After this change, the docker daemon can be reloaded through 'systemctl reload docker', which reloads the configuration; journalctl -f -u docker.service May 02 03:49:20 testing systemd[1]: Reloading Docker Application Container Engine. May 02 03:49:20 testing docker[28496]: time="2016-05-02T03:49:20.143964103-04:00" level=info msg="Got signal to reload configuration, reloading from: /etc/docker/daemon.json" May 02 03:49:20 testing systemd[1]: Reloaded Docker Application Container Engine. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-05-02 10:27:07 +02:00
ExecReload=/bin/kill -s HUP $MAINPID
Merge remote-tracking branch 'packaging_tmp/master' into upstream_systemd_units Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2021-05-12 11:57:21 +02:00
TimeoutStartSec=0
added RestartSec Signed-off-by: Andrew Hsu <andrewhsu@docker.com> (cherry picked from commit 51879873897afe298cbb736acef34b5a0b500424) Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
2018-08-24 22:40:02 +00:00
RestartSec=2
Round out systemd for RPM packaging Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
2018-08-15 01:42:10 +00:00
Restart=always
systemd: set start burst limits Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229 (https://github.com/systemd/systemd/commit/6bf0f408e4833152197fb38fb10a9989c89f3a59) 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. StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230 (https://github.com/systemd/systemd/commit/f0367da7d1a61ad698a55d17b5c28ddce0dc265a) 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. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-08-31 12:58:50 +02:00
# 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
contrib: systemd: set Limit* to infinity There is a not-insignificant performance overhead for all containers (if containerd is a child of Docker, which is the current setup) if systemd sets rlimits on the main Docker daemon process (because the limits propogate to all children). Signed-off-by: Aleksa Sarai <asarai@suse.de>
2016-07-04 23:00:28 +10:00
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
systemd: set Limit* to infinity There is a not-insignificant performance overhead for all containers (if containerd is a child of Docker, which is the current setup) if systemd sets rlimits on the main Docker daemon process (because the limits propogate to all children). Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-08-31 12:45:07 +02:00
LimitNOFILE=infinity
contrib: systemd: set Limit* to infinity There is a not-insignificant performance overhead for all containers (if containerd is a child of Docker, which is the current setup) if systemd sets rlimits on the main Docker daemon process (because the limits propogate to all children). Signed-off-by: Aleksa Sarai <asarai@suse.de>
2016-07-04 23:00:28 +10:00
LimitNPROC=infinity
no limit on core size set LimitCORE=infinity to ensure complete core creation, allows extraction of as much information as possible. Thanks to Ulrich Obergfell <uobergfe@redhat.com> and Jeremy Eder <jeder@redhat.com> Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
2015-02-09 19:03:07 +00:00
LimitCORE=infinity
systemd: no limit on core size set LimitCORE=infinity to ensure complete core creation, allows extraction of as much information as possible. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-08-31 12:43:32 +02:00
systemd: fix typo in TasksMax comment
2019-02-27 12:49:17 +13:00
# Comment TasksMax if your systemd version does not support it.
systemd: don't limit tasks Systemd sets a default of 512 tasks, which is far too low to run many containers. Note that TasksMax is only supported on systemd 226 and above. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-08-31 12:50:05 +02:00
# Only systemd 226 and above support this option.
TasksMax=infinity
Add "Delegate=yes" to docker's service file We need to add delegate yes to docker's service file so that it can manage the cgroups of the processes that it launches without systemd interfering with them and moving the processes after it is reloaded. ``` Delegate= Turns on delegation of further resource control partitioning to processes of the unit. For unprivileged services (i.e. those using the User= setting), this allows processes to create a subhierarchy beneath its control group path. For privileged services and scopes, this ensures the processes will have all control group controllers enabled. ``` This is the proper fix for issue #20152 Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
2016-02-23 14:21:29 -08:00
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
systemd: add "Delegate=yes" to docker's service file We need to add delegate yes to docker's service file so that it can manage the cgroups of the processes that it launches without systemd interfering with them and moving the processes after it is reloaded. Delegate= Turns on delegation of further resource control partitioning to processes of the unit. For unprivileged services (i.e. those using the User= setting), this allows processes to create a subhierarchy beneath its control group path. For privileged services and scopes, this ensures the processes will have all control group controllers enabled. This is the proper fix for issue moby/moby#20152 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-08-31 12:53:49 +02:00
Set systemd KillMode Change the kill mode to process so that systemd does not kill container processes when the daemon is shutdown but only the docker daemon Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
2016-06-16 11:46:04 -07:00
# kill only the docker process, not all processes in the cgroup
KillMode=process
systemd: set OOMScoreAdjust for dockerd dockerd currently sets the oom-score-adjust itself. This functionality was added when we did not yet run dockerd as a systemd service. Now that we do, it's better to instead have systemd handle this. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-10-05 18:52:35 +02:00
OOMScoreAdjust=-500
Add initial init scripts library, including systemd, sysvinit, upstart, and openrc
2013-10-15 09:37:18 -06:00
[Install]
Fix system socket/service unit files Two problems how they are today: In the current systemd unit files it is impossible to have the docker.service started at system boot. Instead enableing docker.service will actually enable docker.socket. This is a problem, as that means any container with --restart=always will not launch on reboot. And of course as soon as you log in and type docker ps, docker.service will be launched and now your images are running. Talk about a PITA to debug! The fix is to just install docker.service when people ask docker.service to be enabled. If an admin wants to enable docker.socket instead, that is fine and will work just as it does today. The second problem is a common docker devel workflow, although not something normal admins would hit. In this case consider a dev doing the following: systemctl stop docker.service docker -d [run commands] [^C] systemctl start docker.service Running docker -d (without -F fd://) will clean up the /var/run/docker.sock when it exits. Remember, you just ran the docker daemon not telling it about socket actviation, so cleaning up its socket makes sense! The new docker, started by systemd will expect socket activation, but the last one cleaned up the docker.sock. So things are just broken. You can, today, work around this by restarting docker.socket. This fixes it by telling docker.socket that it is PartOf=docker.service. So when docker.service is started/stopped/restarted docker.socket will also be started/stopped/restarted. So the above semi-common devel workflow will be fine. When docker.service is stopped, so is docker.socket, docker -d (without -F fd://) will create and delete /var/run/docker.sock. Starting docker.service again will restart docker.socket, which will create the file an all is happy in the word. Signed-off-by: Eric Paris <eparis@redhat.com>
2014-10-07 14:09:08 -04:00
WantedBy=multi-user.target
Copy permalink