From 66df80d8c37dce4b597dfa26e1050856a610cf7f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Wed, 3 Jul 2024 17:05:31 +0200 Subject: [PATCH 3/3] meson: add option to build systemd-executor "statically" 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. (cherry picked from commit d59cae6cebd0fc25a16a020bd28e5303901f1b19) --- meson_options.txt | 2 ++ src/core/meson.build | 16 ++++++++++++---- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/meson_options.txt b/meson_options.txt index d52ca4e4b5..3cce818392 100644 --- a/meson_options.txt +++ b/meson_options.txt @@ -21,6 +21,8 @@ option('rootprefix', type : 'string', deprecated: true, description : '''This option is deprecated and will be removed in a future release''') option('link-udev-shared', type : 'boolean', description : 'link systemd-udevd and its helpers to libsystemd-shared.so') +option('link-executor-shared', type : 'boolean', + description : 'link systemd-executor to libsystemd-shared.so and libsystemd-core.so') option('link-systemctl-shared', type: 'boolean', description : 'link systemctl against libsystemd-shared.so') option('link-networkd-shared', type: 'boolean', diff --git a/src/core/meson.build b/src/core/meson.build index 1ef31cc529..dbeb752977 100644 --- a/src/core/meson.build +++ b/src/core/meson.build @@ -156,6 +156,17 @@ systemd_executor_sources = files( 'exec-invoke.c', ) +executor_libs = get_option('link-executor-shared') ? \ + [ + libcore, + libshared, + ] : [ + libcore_static, + libshared_static, + libbasic_static, + libsystemd_static, + ] + executables += [ libexec_template + { 'name' : 'systemd', @@ -173,10 +184,7 @@ executables += [ 'public' : true, 'sources' : systemd_executor_sources, 'include_directories' : core_includes, - 'link_with' : [ - libcore, - libshared, - ], + 'link_with' : executor_libs, 'dependencies' : [ libapparmor, libpam,