-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add After=dbus.service to containerd.service #10798
Conversation
Hi @benjaminp. Thanks for your PR. I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/ok-to-test |
CI failing
Please try rebasing |
I've now rebased. |
containerd launches runc, which communicates via dbus with systemd to start transient units. Thus, containerd should have an `After` dependency on `dbus.service` to prevent dbus from being shut down concurrently with containerd. Signed-off-by: Benjamin Peterson <[email protected]>
I don't think this is needed, |
sidenote: the same thing can be said for |
The upstream dbus service file does not have a |
Actually, I don't think it matters that much that dbus has started before containerd has, as long as the dbus socket (https://gitlab.freedesktop.org/dbus/dbus/-/blob/a6df11430bfb813351ee25f3d9a734edbcd8dec3/bus/dbus.socket.in) has started (which, being a socket unit, has an implicit dep on sockets.target which basic.target depends on). Unless containerd or runc is doing something special with their dbus connection, systemd will accept connections on behalf of dbus, and pass the socket to dbus once it has started.
|
As the PR request message notes, the need for this dependency most is most acutely demonstrated in practice during shutdown. It's undesirable to have dbus shut down when containerd is still managing runc containers. |
I hadn't parsed that when reading for some reason (probably: distraction), makes sense for shutdown ordering.
Thanks 👍
|
Actually EL9 / Fedora use dbus-broker (https://github.com/bus1/dbus-broker/blob/main/src/units/system/dbus-broker.service.in) and not the original dbus, thus the difference in unit files. |
containerd launches runc, which communicates via dbus with systemd to start transient units. Thus, containerd should have an
After
dependency ondbus.service
to prevent dbus from being shut down concurrently with containerd.