Do not "Bind" docker "To" containerd (carry #365)#508
Merged
thaJeztah merged 1 commit intodocker:masterfrom Nov 5, 2020
Merged
Do not "Bind" docker "To" containerd (carry #365)#508thaJeztah merged 1 commit intodocker:masterfrom
thaJeztah merged 1 commit intodocker:masterfrom
Conversation
relates to docker/for-linux#678 When using the BindTo directive, Docker is permanently stopped by systemd when containerd is temporarily killed and restarted; Using `Requires` achieves mostly the same, but defines a weaker dependency; https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires= > Requires= > > .. 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. We may want to look into using `Wants=` instead of `Requires=`, because that allows docker to continue running if containerd is restarted, quoting the systemd documentation: > 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. Given that docker will likely still fail if the containerd socket is not present, startup will fail if containerd is not running, but if containerd is restarted, the docker daemon may be able to try reconnecting. Signed-off-by: Sebastiaan van Stijn <[email protected]>
Member
Author
chris-crone
reviewed
Nov 4, 2020
Member
chris-crone
left a comment
chris-crone
left a comment
There was a problem hiding this comment.
SGTM but I don't know systemd well enough to make a call on this
tianon
approved these changes
Nov 4, 2020
Contributor
tianon
left a comment
tianon
left a comment
There was a problem hiding this comment.
I was going to comment that it should also be in After= but it already is 😄
LGTM
Member
Author
Thanks for checking; yes, I checked that. I want to look at investigating the |
This was referenced Dec 2, 2020
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
carries #365
closes #365
fixes to docker/for-linux#678
When using the BindTo directive, Docker is permanently stopped by systemd
when containerd is temporarily killed and restarted;
Using
Requiresachieves mostly the same, but defines a weaker dependency;https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires=
We may want to look into using
Wants=instead ofRequires=, becausethat allows docker to continue running if containerd is restarted, quoting
the systemd documentation:
Given that docker will likely still fail if the containerd socket is not
present, startup will fail if containerd is not running, but if containerd
is restarted, the docker daemon may be able to try reconnecting.