From the outside it's difficult to determine whether (and when) the PID1
inside a container supports systemd's more complete set of UNIX process
signals or not. Let's make this easier, and simply send a notification
message when we are ready.
This new passive target is supposed to be pulled in by SSH
implementations and should be reached when remote SSH access is
possible. The idea is that this target can be used as indicator for
other components to determine if and when SSH access is possible.
One specific usecase for this is the new sd_notify() logic in PID 1 that
sends its own supervisor notifications whenever target units are
reached. This can be used to precisely schedule SSH connections from
host to VM/container, or just to identify systems where SSH is even
available.
Let's inform the the supervisor about various happenings of our service
manager, specifically the boot milestones we reach.
We so far have only a singular READY=1 message, to inform about bootup
completion. But sometimes it is interesting to have something for
finegrained, in particular something that indicates optional components
that have been activated.
Usecase for this: in a later PR I intend to introduce a generic
"ssh.target" that is supposed to be activated when SSH becomes available
on a host. A supervisor (i.e. a VMM/hypervisor/container mgr/…) can
watch for that, and know two things:
1. that SSH is generally available in the system
2. when it is available
In order to not flood the supervisor with events I only send these out
for target units. We could open this up later, in theory, but I think it
makes sense to tell people instead to define clear milestone target
units if they want a supervisor to be able to track system state.
Similar as the previous commit, it's useful for a supervisor to know
what machine ID we settlted on, in particular as various other things
are deterministically derived from it, for example MAC addresses and
such.
once we decided on a hostname, let's tell the supervisor about it. This
is useful for example in order to recognize the system via mDNS/LLMNR or
in a DHCP lease.
Debian packaging includes the exploded tarball, so scripts used to
detect files that should be in POTFILES.in, like intltool-update -m
used on https://l10n.gnome.org/module/systemd/, falsely detect its
files as needed to be translated. Avoid this behavior by putting
the whole submodule in POTFILES.skip.
The branch with configure_file() was broken: meson doesn't know that
this file is a prerequisite for other targets, so partial rebuilds were broken.
Easy reproducer:
git mv .git{,.no}
touch meson build && ninja -C build src/basic/libbasic.a
rm build/version.h
ninja -C build src/basic/libbasic.a
Using vcs_tag() also in that case makes meson always build the file.
(Combined with the issue fixed in previous commit, I was encountering
failed builds quite often.)
Fixes 3f6ce3d4f0.
With git-worktree, .git is just a file that specifies where
the parent git directory is. All the git information is available
in a git worktree, so it should be treated the same as a checkout
with a .git directory.
In mkosi, we've been having CI failures caused by
systemd-machine-id-commit.service timing out. Let's bump the timeout
for it and systemd-rfkill.service to 90s which we also use for other
oneshot services to avoid transient failures on slower systems.
Lennart Poettering
Yu Watanabe
Piotr Drąg
Mike Yuan
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Daan De Meyer
dependabot[bot]
Sam Leonard