fix(systemd): start Docker engine *after* DNS resolution is ready#48812
fix(systemd): start Docker engine *after* DNS resolution is ready#48812thaJeztah merged 1 commit intomoby:masterfrom Octol1ttle:patch-1
Conversation
On systems using systemd to autostart Docker on boot, containers might encounter a problem where they will not have any DNS access until the container is restarted manually. This PR fixes this issue by requiring that the Docker engine service starts after nss-lookup.target. This target is reached when DNS resolution is available. See https://wiki.archlinux.org/title/Systemd#Running_services_after_the_network_is_up (paragraph "If a service needs to perform DNS queries...") Signed-off-by: Octol1ttle <[email protected]>
thaJeztah
left a comment
thaJeztah
left a comment
There was a problem hiding this comment.
Thanks! LGTM from reading those docs, and systemd's own reference (nss-lookup.target). I could use some extra eyes to be sure though (we had some targets that were added at some point that caused severe delays when running in headless situations, but not sure if that applies here).
Looking at these, I'm also wondering if we should have nss-user-lookup.target (definitely not for this PR though).
|
cc @tianon 🤗 |
|
My reading is that this is technically a subset of From that perspective, it should be mostly harmless to add, but I do wonder how one might reproduce the issue this purportedly fixes? In other words, in what situations would |
|
My theory is that this happens on systems where two different services are responsible for network connectivity and DNS configuration respectively. This is the case on our machine, where we (my team) use We encountered this issue while using a WireGuard image: https://github.com/jordanpotter/docker-wireguard Upon machine restart, WireGuard was unable to connect using its configuration, throwing "Failed to connect to external DNS server". Restarting the container manually would fix this. Adding |
|
The failure is unrelated to this PR. Opened a separate ticket: #48818 |
There was a problem hiding this comment.
Looking at systemd repo, it seems there's no particular relationship between nss-lookup.target and network-online.target (see here). It's up to each distro / user to define which service should be started before nss-lookup.target. That's what systemd-resolved.service does.
I wonder if this would be worth bringing up to the systemd maintainers; my train of thought there is that |
|
In either case, I think this change is fine to bring in, so let me merge it |
When the Engine starts up, it starts all containers marked as Since the engine unit wasn't targeting So I think |
5 participants
On systems using systemd to autostart Docker on boot, containers might encounter a problem where they will not have any DNS access until the container is restarted manually.
- What I did
Added an additional target for the Docker Engine service:
nss-lookup.target. This target is reached when DNS resolution is ready (see https://wiki.archlinux.org/title/Systemd#Running_services_after_the_network_is_up, paragraph "If a service needs to perform DNS queries...")- How I did it
Using a text editor.
- How to verify it
Check that containers launched during Docker Engine's
systemdautostart can successfully perform DNS queries.- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)
