Submission type

• Bug report

systemd version the issue has been seen with

systemd 238
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid

Actually, systemd 238 commit 738ab75 works just fine while the current branch 238-stable (most recent commit c58ab03) from systemd/systemd-stable has this problem.

Used distribution

Arch Linux (with package systemd version 238.51-1 installed which is based on 238-stable, commit c58ab03)

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

Multiple unprivileged systemd-nspawn containers can be running simultaneously

In case of bug report: Unexpected behaviour you saw

After an unprivileged systemd-nspawn container (e.g. container1) has been started, no subsequent container (e.g. container2) can be started and the journal shows:
mrt 28 08:42:56 localhost systemd[1]: Starting Container container2...
-- Subject: Unit [email protected] has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit [email protected] has begun starting up.
mrt 28 08:42:56 localhost systemd-nspawn[11295]: Selected user namespace base 201129984 and range 65536.
mrt 28 08:42:56 localhost systemd-nspawn[11295]: Failed to add new veth interfaces (ve-container2:host0): File exists
mrt 28 08:42:56 localhost systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
mrt 28 08:42:56 localhost systemd[1]: [email protected]: Failed with result 'exit-code'.
mrt 28 08:42:56 localhost systemd[1]: Failed to start Container container2.
-- Subject: Unit [email protected] has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit [email protected] has failed.
--
-- The result is RESULT.

After container1 has been started, an interface named host0 is listed by networkctl (executed on the host, so not within the container), which may be why it can't create it again:

[root@nuc machines]# networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eno1 ether routable configured
3 host0 ether off unmanaged
4 ve-container1 ether no-carrier configuring

Also, when container1 is stopped, interface host0 disappears and container2 can be started just fine (but again also results in a listed host0 interface). In that case container1 can't be started.

Could this be a side-effect of #8430 ?

In case of bug report: Steps to reproduce the problem

On Arch Linux as root:

chdir /var/lib/machines
# Create containers
mkdir container1
pacstrap -c container1 systemd
mkdir container2
pacstrap -c container2 systemd

# Start container1 unprivileged (by default)
machinectl start container1
# Observe a listed host0 interface
networkctl

# Try to start container2
machinectl start container2
# Observe the fasilure