Units for interfaces in network namespaces

[Ekleog]

Submission type

• Bug report
• Request for enhancement (RFE)

systemd version the issue has been seen with

231

Used distribution

NixOS

In case of bug report: Expected behaviour you didn't see

With a device tun-netns-one in network namespace one, I expected a device such as sys-subsystem-net-devices-tun\x2dnetns\x2done.device to appear, potentially namespaced by the name of the network namespace.

In case of bug report: Unexpected behaviour you saw

Instead, no unit seems to match the device in a call to systemctl

In case of bug report: Steps to reproduce the problem

ip tuntap add tun-global mode tun
ip netns add one
ip netns exec one ip tuntap add tun-netns-one mode tun
ip netns exec one ip link
systemctl

Observe the device tun-netns-one is in the network namespace but does not appear in the unit list, while one appears for tun-global.

[evverx]

With a device tun-netns-one in network namespace one, I expected a device such as sys-subsystem-net-devices-tun\x2dnetns\x2done.device to appear

Why did you expect this?

https://www.freedesktop.org/software/systemd/man/systemd.device.html#

systemd will dynamically create device units for all kernel devices that are marked with the "systemd" udev tag

systemd-udevd doesn't receive events from the namespace "one" (try udevadm monitor --subsystem=net -k. You will see KERNEL[25854.050426] add /devices/virtual/net/tun-global (net) only).

This is how namespaces work

[Ekleog]

I must say I don't know anything about systemd internals, but this makes it impossible to have a service depend on a device inside a network namespace, or am I mistaken?

As for why I thought it should act this way, I think that as systemd provides an automatic unit for devices outside a network namespace it should be consistent and actually provide it for all interfaces ?

[poettering]

network namespaces are a kernel feature, and if used mean that network devices exist in precisely one network namespace (with exception of the loopback device). That means: systemd on the host knows nothing about and cannot see network devices inside of namespaces, and systemd running inside of one of those namespaces can't see the network devices of the host.

This is a by design of the kernel, and thus systemd cannot track the state of a device in another namespace, and really shouldn't even if it could.

Sorry, but this is a kernel design decision, we are just using here what the kernel lets us know.

[Ekleog]

Sorry, but saying systemd cannot see network devices inside of namespaces is wrong: systemd runs as root, which can see devices inside netns using eg. ip netns exec [netns] ip link.

Then, I understand that setting an inotify on /run/netns and spawning a udevfw-like may be too complex to implement.

In this case, is there no way of telling systemd a device is up even though it is not in the udev store? From a quick test, it seems that adding a foo.device with a description and systemctl start-ing it doesn't make systemd know about it, as it times out and fails… maybe I missed something?

[poettering]

udev is really only supposed to manage device in the main namespaces, it's not supposed to manage anything else. Similar with systemd: it should only recognize devices in its own namespace. I mean, generally namespaces are created precisely to separate stuff from the main host, and we should "reach over" there.

If you want to sync on netif device creation in other namespaces, then my suggestion would be to write a small tool that is started as service of type Type=oneshot and syncs on it. Then order against that service instead of the .device unit and you should have all you need...

I think systemd should honour network namespaces, and accept that it's not supposed to manage stuff within it. I am pretty sure if we started to ignore that and would actually watch devices in them too, people would hate us quite a bit more ;-)