systemd-networkd default "unmanaged" for docker*, br-*, veth* #28626
Comments
|
|
|
mkinitcpio hooks: It's a bug because Then, later, docker is started. Even later, docker containers are started. Yet systemd-network-generator messes with the docker interfaces. |
|
I assume |
|
Proposed fix:
|
|
@bf Thank you for the report and suggestion.
"visible at boot" is hard to define, but limiting to a class of interfaces sounds good.
That should be done by docker side. |
|
@yuwata thanks for quick reply. I've opened https://bugs.archlinux.org/task/79268 - maybe archlinux packagers will add the systemd-networkd config files in their package. With regards to limiting "systemd-network-generator" to a certain class of interfaces, is this possible? If yes, that'd be the best solution. My basic assumption for systemd-network-generator is to only cover interfaces with their catch-all rule which are present at boot time. The docker interfaces aren't, and therefore shouldn't be covered. |
|
The archlinux docker people refuse to fix the known issue [1] because there's a workaround documented in arch wiki [2] [1] : https://bugs.archlinux.org/task/79268 |
|
OK. Let's do in the way of the first suggestion. Note, workaround is simple, just disable systemd-network-generator.service (and reboot the system, or remove files under /run/systemd/network). |
…nly physical interfaces Otherwise, it also matches later created virtual devices, and that breaks networks generated and managed by container management services, like docker. Closes systemd#28626.
|
Fix is waiting in #28646. |
…nly physical interfaces Otherwise, it also matches later created virtual devices, and that breaks networks generated and managed by container management services, like docker. Closes systemd#28626.
|
Wow, thank you so much @yuwata! Please let me know if I should test this. |
Please, if possible. |
|
I compiled your PR: So no change by only restarting the service. Let's see how it looks after reboot: It seems to have worked! Please note that also loopback is unmanaged now. I'll start using docker and report back if the other interfaces are unmanaged as well. |
|
Seems to also work with other docker devices: |
|
@bf Thank you!!
Yeah, that's expected and intended. |
|
Thanks to you for the quick fix! |
…nly physical interfaces Otherwise, it also matches later created virtual devices, and that breaks networks generated and managed by container management services, like docker. Closes systemd#28626. (cherry picked from commit c25aa6c)
…nly physical interfaces Otherwise, it also matches later created virtual devices, and that breaks networks generated and managed by container management services, like docker. Closes systemd#28626. (cherry picked from commit c25aa6c) (cherry picked from commit d39bfd2) (cherry picked from commit 2c2b89a)
…nly physical interfaces Otherwise, it also matches later created virtual devices, and that breaks networks generated and managed by container management services, like docker. Closes systemd#28626. (cherry picked from commit c25aa6c) (cherry picked from commit d39bfd2)
systemd version the issue has been seen with
253.7-1
Used distribution
Arch
Linux kernel version used
6.4.6-hardened
CPU architectures issue was seen on
x86_64
Component
No response
Expected behaviour you didn't see
Docker containers cannot connect to unternet,
networkctl shows "configuring" for docker0 and br-* devices.
Unexpected behaviour you saw
systemd-networkd applying default route to docker network interfaces, thereby blocking docker containers from reaching internet.
This issue has cost me countless hours. I dont know why systemd-networkd decides to ship some "clever" defaults in /usr/lib/systemd/network but doesn't have a default for docker.
Steps to reproduce the problem
Install systemd-networkd, install docker, start container:
docker run busybox ping -c 1 1.1.1.1-> timeoutnetworkctl will show that systemd-networkd is busy "configuring" docker0 and all other docker virtual interfaces
Fix:
create /etc/systemd/network/{20-veth.network,21-docker.network,22-docker-br.network}
with contents:
I assume this issue has been reported here hundreds of times. I really dont know why it is still default behavior.
Additional program output to the terminal or log subsystem illustrating the issue
The text was updated successfully, but these errors were encountered: