]> git.ipfire.org Git - thirdparty/systemd.git/commit
vmspawn: Run auxiliary daemons inside scope instead of separate service 38047/head
authorDaanDeMeyer <daan.j.demeyer@gmail.com>
Thu, 3 Jul 2025 08:52:33 +0000 (10:52 +0200)
committerDaanDeMeyer <daan.j.demeyer@gmail.com>
Mon, 14 Jul 2025 13:07:48 +0000 (15:07 +0200)
commitc81fa16ddf5025abe20aa0cc38d9f983dd8e7156
tree99dddecb75cc1f461c52b94c58723af2a8f73558
parente4691ebb49fb8fd883727991c187b37a6fb8753f
vmspawn: Run auxiliary daemons inside scope instead of separate service

Currently, vmspawn is in this really weird state where vmspawn itself
and qemu will inherit the caller's execution environment but the auxiliary
daemons it spawn will run in a fully pristine environment in the service
manager. In practice, this causes issues as checks for whether auxiliary
daemons are installed happen in the caller's execution environment but they
might not exist in the spawned service's execution environment.

A good example of where this causes issues is trying to use systemd-vmspawn
in our CI. We use mkosi in CI to run systemd-vmspawn in a custom userspace
with all the necessary tools available, but systemd-vmspawn then tries to
spawn services that run these tools using the host userspace, where the
tools are not available or too old and hence systemd-vmspawn fails to start.

Let's make things more consistent and allow using systemd-vmspawn in CI at
the same time by having systemd-vmspawn spawn auxiliary daemons itself
instead of having the service manager spawn them. We use
systemd-socket-activate to still have socket activation for these services,
even though we now spawn them ourselves. To make sure we wait for
systemd-socket-activate to bind to its socket before continuing, we use the
new general fork_notify() helper.

Why not support both "online" and "offline" operation? systemd-vmspawn is not
well tested as is and supporting two completely separate modes for spawning
auxiliary daemons will drastically increase the surface area for bugs. Given
there doesn't seem to be a major benefit to running daemons in services, it
seems better to only support offline operation and not both. Should we want
separate resource control for the auxiliary daemons in the future, we can run
move them into separate scopes if needed.

As a bonus, this approach allows us to get rid of the extra complexity of
having to fork off the qemu process first so we can allocate a scope for it
that the other services bind to. This means large parts of
0fc45c8d20ad46ab9be0d8f29b16e606e0dd44ca are reverted by this commit.
src/shared/fork-notify.c
src/shared/fork-notify.h
src/vmspawn/vmspawn-scope.c
src/vmspawn/vmspawn-scope.h
src/vmspawn/vmspawn.c