It's time. sd-json was already done earlier in this cycle, let's now
make sd-varlink public too.
This is mostly just a search/replace job of epical proportions.
I left some functions internal (mostly IDL handling), and I turned some
static inline calls into regular calls.
Follow-up for 19a44dfe45
If a drop-in is set from upper level, e.g. global unit_type.d/,
even if a unit is masked, its dropin_paths would still be partially
populated. However, unit_need_daemon_reload() would always
compare u->dropin_paths with empty strv in case of masked units,
resulting in it always returning true. Instead, let's ignore
dropins entirely here.
Fixes#33672
We use this at various places, let's unify this in one global constant.
This changes flags in crash-handler.c in a tiny irrelevant way: we ask
syscalls to be continued on signal arrival, which we previously didn't.
But that shouldn't change anything, the only thing we'll do in the
relevant process is call raise(), and that's it, hence there definitely
are no syscalls to restart or not to restart.
It's usually how we do this: make the functions robust to be called in
any context, and validate the context in the functions themselves early,
instead of in the caller.
We'll *always* hit ENEOENT when iterating through SMBIOS type #11
fields, on the last one. it's very confusing to debug log about that,
let's just not do it.
When watching a given pathspec, systemd unconditionally installs
IN_ATTRIB watches to track the link count of the resolved file. This
way, we are notified if the watched path disappears, even if the
resolved file inode is not removed.
Similarly, systemd installs inotify watches on each parent directory, to
be notified when the specified path appears. However, for these watches
IN_ATTRIB is an unnecessary addition to the mask. In inotify, IN_ATTRIB
on a directory is emitted whenever the attributes of any child changes,
which, for many paths, has the potential to cause a high number of
spurious wakeups in systemd. Let's remove IN_ATTRIB from the mask when
installing watches on the parent directories of the specified path.
For MountImages=, if the source is a block device, it will most likely reside
in /dev. It should be also possible to mount a static device file system in
place of (or part of) /dev. So let's allow paths starting with /dev as an
exception for MountImages=.
The new link-executor-shared option is similar to the existing
link-udev-shared: when set to false, we link to the static versions of our
internal libraries.
The resulting exuctor binary is fairly large, about as large as libsystemd-core
(14 MB without lto, 8 with lto).
This is intended as a workaround for the fuckup with the pinned executor
binary:
when an upgrade is performed, the package manager will install new version of
the libraries and new version of the code, and some time later reexecute the
managers. This creates a window when the pinned executor binary will fail to
execute. There are two factors which make the issue easier to hit:
- when the distribution uses a finely-grained shared-lib-tag. E.g. Fedora
uses version-release as the tag, which means that the issue occurs on
every package upgrade. This is the right thing to do, because the
ABI of our internal libraries is not stable at all, so replacing the
library from a different version in place creates a window where our
programs may crash or misbehave.
- when the distribution doesn't immediately reexec all the managers after
upgrade. In early versions of systemd, we used to hammer the machine during
upgrade, doing daemon-reexecs repeatedly. This works, but is ugly and
wasteful. Doing the reexecs while the upgrade is in progres also creates a
window where a mix of old and new configs or both is loaded. Users are
particularly annoyed by those reloads if there is some issue in the
configuration causing us to emit warnings on every reexec. Doing the
reexecs once after the new configuration and libraries have been put
in place is nicer.
The pinning of the executor binary breaks upgrades and in particular
it penalizes the distributions which make use of the features which
were previously added to avoid bugs and inefficiency during upgrades.
When the executor is linked statically, there is a smaller chance that it'll
fail to load libraries. The issue can still occur because other libraries, not
our own, are linked dynamically.
By itself, this is not useful. I'm making this a separate commit to
make debugging easier. It turns out that meson does static libraries
using references, so the "static library" a tiny stub stub that refers
to the object files on disk and this has negligible cost:
$ ls -lhd build/src/core/libsystemd-core-257.{a,so}
-rw-r--r-- 1 zbyszek zbyszek 36K Jul 3 16:54 build/src/core/libsystemd-core-257.a
-rwxr-xr-x 1 zbyszek zbyszek 6.1M Jul 3 16:54 build/src/core/libsystemd-core-257.so
If the destination mount point is on a shared filesystem and is
missing on the first attempt, we try to create it, but then
fail with -EEXIST if something else created it in the meanwhile.
Enter the retry logic on EEXIST, as we can just use the mount
point if it was already created.
Fixes https://github.com/systemd/systemd/issues/29690
Currently, we only follow merged units for unit_load_dropin() call.
But if the unit is an alias, we should always perform operations
on the "canonical" unit.
Use the new function `hashmap_ensure_replace()` where we're using
`hashmap_ensure_allocated()` and `hashmap_ensure_replace()`.
Signed-off-by: Matteo Croce <teknoraver@meta.com>
Mike Yuan
Matteo Croce
Lennart Poettering
Merlin Jehli
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Ronan Pigott
Topi Miettinen
Daan De Meyer