Skip to content

Conversation

@thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Nov 4, 2020

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 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.

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]>
@thaJeztah
Copy link
Member Author

Copy link
Member

@chris-crone chris-crone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM but I don't know systemd well enough to make a call on this

Copy link
Contributor

@tianon tianon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going to comment that it should also be in After= but it already is 😄

LGTM

Copy link
Contributor

@silvin-lubecki silvin-lubecki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@thaJeztah
Copy link
Member Author

I was going to comment that it should also be in After= but it already is 😄

Thanks for checking; yes, I checked that.

I want to look at investigating the Wants= as an option in a follow-up, but that definitely requires some double-checking, so I didn't want to roll that change into this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants