From 833b8d98e04d368b05717d4fbbac7db5303cfbee Mon Sep 17 00:00:00 2001 From: =?utf8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Wed, 1 Jul 2026 21:02:42 +0200 Subject: [PATCH] NEWS,README: describe embedded files and static linking --- NEWS | 9 ++++++++ README | 70 ++++++++++++++++++++++++++++++++++++---------------------- 2 files changed, 53 insertions(+), 26 deletions(-) diff --git a/NEWS b/NEWS index ef3d070df19..80f83da2437 100644 --- a/NEWS +++ b/NEWS @@ -16,6 +16,15 @@ CHANGES WITH 262: have been provided. This clears the way for a new "systemd-sysupdate@.service" unit for varlink activation of sysupdate. + Changes in the system and service manager: + + * The manager now embeds a basic set of unit files (basic.target, + sysinit.target, multi-user.target, reboot.target, shutodown.target, + systemd-poweroff.service, etc.) and will use if files cannot be + loaded from disk. This makes the binary slightly more robust and + allows a container to be started with systemd as PID1 without + installing any unit files. + Changes in systemd-firstboot: * The "systemd.firstboot=" kernel command line option now accepts the diff --git a/README b/README index 5553915be00..279587367b8 100644 --- a/README +++ b/README @@ -328,42 +328,49 @@ POLICY FOR SUPPORT OF DISTRIBUTIONS AND ARCHITECTURES: which support has been added. systemd will emit warnings when architecture-specific constants are not defined. -STATIC COMPILATION AND "STANDALONE" BINARIES: - systemd provides a public shared libraries libsystemd.so and - libudev.so. The latter is deprecated, and the sd-device APIs in - libsystemd should be used instead for new code. In addition, systemd is - built with a private shared library, libsystemd-shared-.so, - that also includes the libsystemd code, and by default most systemd - binaries are linked to it. Using shared libraries saves disk space and - memory at runtime, because only one copy of the code is needed. +STATIC LIBRARIES AND "STANDALONE" BINARIES: + systemd provides public shared libraries libsystemd.so and libudev.so. + The latter is deprecated, and the sd-device APIs in libsystemd should + be used instead for new code. Normally systemd is built with a private + shared library, libsystemd-shared-.so, that also includes the + libsystemd code, and by default most systemd binaries are linked to it. + Using shared libraries saves disk space and memory at runtime, because + only one copy of the code is needed. It is possible to build static versions of systemd public shared libraries (via the configuration options '-Dstatic-libsystemd' and '-Dstatic-libudev'). This allows the libsystemd and libudev code to be linked statically into programs. Note that mixing & matching different versions of libsystemd and systemd is generally not recommended, since - various of its APIs wrap internal state and protocols of systemd - (e.g. logind and udev databases), which are not considered - stable. Hence, using static libraries is not recommended since it - generally means that version of the static libsystemd linked into - applications and the host systemd are not in sync, and will thus create - compatibility problems. + various of its APIs wrap internal state and protocols of systemd (e.g. + logind and udev databases), which are not considered stable. Hence, + using static libraries is not recommended since it generally means that + version of the static libsystemd linked into applications and the host + systemd may get out of sync, creating compatibility problems. In addition, it is possible to disable the use of libsystemd-shared-.so for various components (via the configuration options '-Dlink-*-shared'). In this mode, the libsystemd - and libsystemd-shared code is linked statically into selected - binaries. This option is intended for systems where some of the - components are intended to be delivered independently of the main - systemd package. Finally, some binaries can be compiled in a second - version (via the configuration option '-Dstandalone-binaries'). The - version suffixed with ".standalone" has the libsystemd and - libsystemd-shared code linked statically. Those binaries are intended - as replacements to be used in limited installations where the full - systemd suite is not installed. Yet another option is to rebuild - systemd with a different '-Dshared-lib-tag' setting, allowing different - systemd binaries to be linked to instances of the private shared - library that can be installed in parallel. + and libsystemd-shared code is linked statically into selected binaries. + This option is intended for systems where some of the components are + intended to be delivered independently of the main systemd package. + + In addition, some binaries can be compiled in a second version (via the + configuration option '-Dstandalone-binaries'). The version suffixed + with ".standalone" has the libsystemd and libsystemd-shared code linked + statically. Those binaries are intended as replacements to be used in + limited installations where the full systemd suite is not installed. An + alternative approach is to rebuild systemd with a different + '-Dshared-lib-tag' setting, allowing different systemd binaries to be + linked to instances of the private shared library that can be installed + in parallel. + + When compiled in one of the modes described in this section, the code + has identical functionality (apart from the potential compatibility + issues). + + Finally, fully static compilation of systemd (the program) is possible, + see next section. Again: Using the default shared linking is recommended, building static or "standalone" versions is not. Mixing versions of systemd components @@ -372,6 +379,17 @@ STATIC COMPILATION AND "STANDALONE" BINARIES: combinations upstream and cannot provide support. Distributors making use of those options are responsible if things do not work as expected. +STATIC BINARIES: + It is possible to compile systemd (the program) as a static binary with + the meson options: + --default-library=static --prefer-static -Dbuild-static=true -Dsystemd-multicall-binary=true + This results in a static 'systemd' binary that can be used as PID1 in a + container. This binary does not use dlopen(3), which means that it + cannot dynamically extend its functionality by loading other libraries, + even if they were available in the file system. It also does not + support NSS and instead uses simplified code that only supports static + passwd and group files to resolve users. + USERS AND GROUPS: Default udev rules use the following standard system group names, which need to be resolvable by getgrnam() at any time, even in the very early -- 2.47.3