uevent when moving nic between network namespaces?
Eric W. Biederman
ebiederm at xmission.com
Fri Oct 12 03:26:46 UTC 2012
Serge Hallyn <serge.hallyn at canonical.com> writes:
> Dan Kegel (cc:d) found an interesting nuisance relating to upstart
> and network interfaces with lxc containers. In particular, when you
> start a container, two veths are created. A uevent for their creation
> is sent, and so a 'network-interface' upstart job is created for each.
> One of the veths is passed into the container. When the container
> shuts down, the veth in the init-net-ns gets a net-device-removed
> uevent, so the network-interface upstart job goes away. But the veth
> in the container doesn't cause a net-device-removed upstart uevent
> to be sent. So its network-interface upstart job sticks around.
> The details are at:
> I notice that when simply renaming a netdev (sudo ip link set veth1 name
> veth2) then udevadm monitor shows:
> KERNEL[17945.234850] move /devices/virtual/net/veth2 (net)
> UDEV [17945.235758] move /devices/virtual/net/veth2 (net)
> but when I do 'sudo ip link set veth2 netns 27689' then 'udevadm
> monitor' shows nothing.
> When I do
> sudo ip link set veth1 netns 32296
> (in process 32296) sudo ip link set veth1 name veth2
> then, again udevadm monitor shows nothing.
> So the question is, should the kernel be sending uevents for
> net-device-removed and then net-device-added when a nic is moved
> between network namespaces? Or should lxc just fake that?
To the best of my memory I wired up those events, and they should be
delivered. Now they uevents will only be delivered in the relevant
Hmm. But the relevant code in the kernel is device_rename, and it
happens after we switch the network namespace on the device.
Which probably means that in practice only the new network namespace is
More information about the Containers