--lines=1 means that we show the last message about the unit, whatever it is:
$ SYSTEMD_LOG_LEVEL=debug systemctl --verbose start demo2
...
Invoking 'journalctl -q --follow --no-pager --lines=1 --synchronize-on-exit=yes --unit=demo2.service' as child.
...
Directory /var/log/journal/7d16833bfa924410851e2a193bcfd4ba added.
Journal effective settings seal=no keyed_hash=yes compress=ZSTD compress_threshold_bytes=8B
...
Reiterating files to get inotify watches established.
Considering root directory '/run/log/journal'.
Considering root directory '/var/log/journal'.
Considering directory '/var/log/journal/7d16833bfa924410851e2a193bcfd4ba'.
Nov 26 17:24:35 rawhide systemd[1]: Finished demo2.service.
...
Executing dbus call org.freedesktop.systemd1.Manager StartUnit(demo2.service, replace)
...
Job for demo2.service finished.
Got result done/Success for job demo2.service.
journal: Sending message: {"method":"io.systemd.Journal.Synchronize","parameters":{"offline":false}}
Nov 27 13:05:30 rawhide systemd[1]: Starting demo2.service...
Nov 27 13:05:30 rawhide systemd[1]: demo2.service: Deactivated successfully.
Nov 27 13:05:30 rawhide systemd[1]: Finished demo2.service.
...
We obviously should only show _new_ messages, hence change to --lines=0.
This works properly after the fix in the previous commit.
Fixes#39048.
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
0fc45c8d20 are reverted by this commit.
Zbigniew Jędrzejewski-Szmek
DaanDeMeyer