Package: systemd-container
Version: 242-4
Severity: minor
Due to IFNAMSIZ, nspawn's network interfaces names are truncated.
The possibility of collisions should be clearly documented.
My test containers have reasonably long names:
root@not-omega:~# ls -l /var/lib/machines/
total 75
drwxr-xr-x 2 root root 2 May 15 13:59 alamo
drwxr-xr-x 21 1087766528 1087766528 21 Aug 8 13:25 dns-test
drwxr-xr-x 21 1075707904 1075707904 21 Jan 1 2019 my-new-container
-rw-r--r-- 1 root root 0 Aug 8 17:55 my-new-container.nspawn~
drwxr-xr-x 21 root root 21 Aug 7 19:46 nft-test-downstream
drwxr-xr-x 21 1242628096 1242628096 21 Aug 7 19:48 nft-test-upstream
drwxr-xr-x 21 1486684160 1486684160 21 May 15 15:32 not-alamo
drwxr-xr-x 21 1669005312 1669005312 21 Jan 1 2019 test-alloc-1566986334
drwxr-xr-x 21 1024851968 1024851968 21 Jan 1 2019 test-alloc-1566988389
drwxr-xr-x 21 1678049280 1678049280 21 Aug 9 01:36 upstream-container
-rw-rw-r-- 1 root root 0 Aug 8 17:55
upstream-container.nspawn
I noticed that the interfaces created by systemd-nspawn do not use the full
name:
root@not-omega:~# machinectl status test-alloc-1566986334 | grep Iface
Iface: ve-test-alloc-
root@not-omega:~# ip -o l | grep alloc
11: ve-test-alloc-@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP mode DEFAULT group default qlen 1000\ link/ether
26:b1:44:74:31:e8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
I wondered what would happen if the "unique" interface happened to
already be in use by another container.
The answer is that systemd-nspawn just crashes with a dumb error:
+ machinectl start test-alloc-1566988389
Job for [email protected] failed because the
control process exited with error code.
See "systemctl status [email protected]" and
"journalctl -xe" for details.
root@not-omega:~# journalctl -u [email protected]
-- Logs begin at Wed 2019-05-01 20:15:10 AEST, end at Wed 2019-08-28
20:36:53 AEST. --
Aug 28 20:36:53 not-omega systemd[1]: Starting Container
test-alloc-1566988389...
Aug 28 20:36:53 not-omega systemd-nspawn[5357]: Failed to add new veth
interfaces (ve-test-alloc-:host0): File exists
Aug 28 20:36:53 not-omega systemd[1]:
[email protected]: Main process exited, code=exited,
status=1/FAILURE
Aug 28 20:36:53 not-omega systemd[1]:
[email protected]: Failed with result 'exit-code'.
Aug 28 20:36:53 not-omega systemd[1]: Failed to start Container
test-alloc-1566988389.
Aug 28 20:36:53 not-omega systemd[1]:
[email protected]: Consumed 339ms CPU time, no IP
traffic.
This limitation is not obvious (to me).
In the systemd-nspawn manpage, it indicates ve-X should machine the machine
name.
I THINK this is happening due to IFNAMSIZ in
src/nspawn/nspawn-network.c:setup_veth(), which is:
src/basic/linux/if.h:32:#define IFNAMSIZ 16
If this is an unavoidable limitation due to Linux, please at least
warn about it in the systemd-nspawn manpage.
Maybe systemd-nspawn or machinectl could even look for this collision
and specifically warn about it, e.g.
systemd-nspawn: cannot create interface "ve-X" for container X-2, because
another container (X-1) is already using it. Either rename a container, or use
non-default networking (i.e. don't use --network-veth).
A quick test of a (non-systemd) client suggests this is indeed a fundamental
constraint:
root@not-omega:~# ip link add waffle type veth peer jaffa
root@not-omega:~# ip link set waffle name wafflexxxxxxxxxxxxxx
Error: argument "wafflexxxxxxxxxxxxxx" is wrong: "name" not a valid ifname
root@not-omega:~# ip link set waffle name wafflexxxxxxxxxxx
Error: argument "wafflexxxxxxxxxxx" is wrong: "name" not a valid ifname
root@not-omega:~# ip link set waffle name wafflexxxxxxxx
root@not-omega:~#
PS: systemd-nspawn is picky about container names (e.g. can't have a
underscore). If this is ultimately based on RFC 952, note that
RFC 952 allows up to 24 bytes (longer than IFNAMSIZ).
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
