From: Zbigniew Jędrzejewski-Szmek Date: Wed, 28 Jan 2026 15:29:37 +0000 (+0100) Subject: docs/PORTABILITY_AND_STABILITY: update the policy X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f4dd927e5cc47a88fa427a6e1ce210b1f2350978;p=thirdparty%2Fsystemd.git docs/PORTABILITY_AND_STABILITY: update the policy The kernel has a "don't break userspace" policy [1] which is very easy to understand and like (even if the details are complicated). We had a complicated policy statement, but the actual practice is that we'll generally avoid changes that cause problems for users. So the whole detailed table is more of a guideline than something that we can rely on. To improve public perception, and to align the docs with practice, let's make a general promise to keep stability, and change the existing table to a "guideline" that tells people which interfaces to use and which not to use so that use and development of systemd don't conflict or create pain. The existing document was very long, and I think it'll have a bigger impact if it shorter. In particular, the chart is dropped, because it was of limited use and severly outdated, because we have added many new interfaces and components without updating it. Adding the missing elements (and then keeping it updated) would be a lot of effort. The chart would be most useful to somebody trying to build a systemd reimplementation, but there haven't been many attempts like this, so let's save the work and drop it and make the document shorter. I also dropped the mentions of Debian. Back in the day, we did indeed adopt many Debian conventions for config files and such, but over the years the scope of the project has grown quite a bit and that part of systemd is a small fraction now. And we've adopted conventions and ideas from many other places too, so we don't mention Debian specifically. [1] https://docs.kernel.org/admin-guide/reporting-regressions.html --- diff --git a/docs/PORTABILITY_AND_STABILITY.md b/docs/PORTABILITY_AND_STABILITY.md index a5605f063b8..7de60066e45 100644 --- a/docs/PORTABILITY_AND_STABILITY.md +++ b/docs/PORTABILITY_AND_STABILITY.md @@ -1,82 +1,110 @@ --- -title: Interface Portability and Stability +title: Portability and Stability category: Interfaces layout: default SPDX-License-Identifier: LGPL-2.1-or-later --- -# Interface Portability and Stability Promise +# Portability and Stability Promise -systemd provides various interfaces developers and programs might rely on. -Starting with version 26 (the first version released with Fedora 15) we promise to keep a number of them stable and compatible for the future. +We try to keep backward compatibility for public interfaces, +and we try to avoid breaking them whenever possible, as described below. +We'll try to fix any reported regressions. -The stable interfaces are: +Occasionally we need to remove some interface or raise the minimum required version of a dependency. +In those cases, we'll announce the deprecation and removal plan in NEWS for a future release. +The feedback from users and distributions will be taken into account. -* **The unit configuration file format**. Unit files written now will stay compatible with future versions of systemd. - Extensions to the file format will happen in a way that existing files remain compatible. - -* **The command line interface** of `systemd`, `systemctl`, `loginctl`, `journalctl`, and all other command line utilities installed in `$PATH` and documented in a man page. - We will make sure that scripts invoking these commands will continue to work with future versions of systemd. - Note however that the output generated by these commands is generally not included in the promise, unless it is documented in the man page. - Example: the output of `systemctl status` is not stable, but that of `systemctl show` is, because the former is intended to be human-readable and the latter computer readable, and this is documented in the man page. - -* **The protocol spoken on the socket referred to by `$NOTIFY_SOCKET`**, as documented in - [sd_notify(3)](https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html). Note that, although using - libsystemd is a good choice, this protocol can also be reimplemented without external dependencies, as - demonstrated in the example listed in - [sd_notify(3)](https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html#Notes) - -* Some of the **"special" unit names** and their semantics. - To be precise the ones that are necessary for normal services, and not those required only for early boot and late shutdown, with very few exceptions. - To list them here: `basic.target`, `shutdown.target`, `sockets.target`, `network.target`, `getty.target`, `graphical.target`, `multi-user.target`, `rescue.target`, `emergency.target`, `poweroff.target`, `reboot.target`, `halt.target`, `runlevel[1-5].target`. - -* **The D-Bus interfaces of the main service daemon and other daemons**. We try to always preserve backwards compatibility, and intentional breakage is never introduced. - Nevertheless, when we find bugs that mean that the existing interface was not useful, or when the implementation did something different than stated by the documentation and the implemented behaviour is not useful, we will fix the implementation and thus introduce a change in behaviour. - But the API (parameter counts and types) is never changed, and existing attributes and methods will not be removed. +To allow systemd to add new features and improve existing functionality, +it constantly needs to evolve. +To make this process smooth, +users are encouraged to follow the categorization of interfaces below. +Interfaces listed as stable are intended for public consumption, +so it's explicitly OK to rely on their stability. +Interfaces listed as unstable are likely to change without notice, +so please do not use those in places where stability is required. -* For a more comprehensive and authoritative list, consult the chart below. +Note that the promise of stability applies only after an interface has been part of a release. -The following interfaces will not necessarily be kept stable for now, but we will eventually make a stability promise for these interfaces too. -In the meantime we will however try to keep breakage of these interfaces at a minimum: -* **The set of states of the various state machines used in systemd**, e.g. the high-level unit states inactive, active, deactivating, and so on, as well (and in particular) the low-level per-unit states. +## Stable interfaces -* **All "special" units that aren't listed above**. +* **The public interface of the `libsystemd` shared library**. -The following interfaces are considered private to systemd, and are not and will not be covered by any stability promise: +* **The D-Bus interfaces** of the manager and other daemons. -* **Undocumented switches** to `systemd`, `systemctl` and otherwise. +* **The Varlink interfaces** of the manager and other daemons. -* **The internal protocols** used on the various sockets such as the sockets `/run/systemd/shutdown`, `/run/systemd/private`. +* **The unit configuration file format**. + Unit files written now will stay compatible with future versions of systemd. + Extensions to the file format will happen in a way that existing files remain compatible. -One of the main goals of systemd is to unify basic Linux configurations and service behaviors across all distributions. -Systemd project does not contain any distribution-specific parts. -Distributions are expected to convert over time their individual configurations to the systemd format, or they will need to carry and maintain patches in their package if they still decide to stay different. +* **The command line interface** of `systemd`, `systemctl`, `loginctl`, `journalctl`, + and all other command line utilities documented in a man page. + Note however that the _output_ generated by these commands is generally not stable, + except in cases documented in the man page. + Example: the output of `systemctl status` is not stable, + but that of `systemctl show` is, + because the former is intended to be human-readable and the latter computer-readable, + and this is documented in the man page. -What does this mean for you? When developing with systemd, don't use any of the latter interfaces, or we will tell your mom, and she won't love you anymore. -You are welcome to use the other interfaces listed here, but if you use any of the second kind (i.e. those where we don't yet make a stability promise), then make sure to subscribe to our mailing list, where we will announce API changes, and be prepared to update your program eventually. +* **The protocol spoken on the socket referred to by `$NOTIFY_SOCKET`**, as documented in + [sd_notify(3)](https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html). + Although using libsystemd is a good choice, + this protocol can also be reimplemented without external dependencies, + as demonstrated in the example listed in + [sd_notify(3)](https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html#Notes). -Note that this is a promise, not an eternal guarantee. -These are our intentions, but if in the future there are very good reasons to change or get rid of an interface we have listed above as stable, then we might take the liberty to do so, despite this promise. -However, if we do this, then we'll do our best to provide a smooth and reasonably long transition phase. +* Some of the **"special" unit names** and their semantics. + To be precise the ones that are necessary for normal services, + and not those required only for early boot and late shutdown, + with very few exceptions. + To list them here: + `basic.target`, + `shutdown.target`, + `sockets.target`, + `network.target`, + `getty.target`, + `graphical.target`, + `multi-user.target`, + `rescue.target`, + `emergency.target`, + `poweroff.target`, + `reboot.target`, + `halt.target`, + `runlevel[1-5].target`. + +We try to always preserve backward compatibility in programmatic interfaces +and intentional breakage is never introduced. +Nevertheless, when we find bugs that mean that the existing interface was not useful, +or when the implementation did something different than stated by the documentation +and the implemented behaviour is not useful, +we will fix the implementation and thus introduce a change in behaviour. +But the API (parameter counts and types) is never changed incompatibly, +and existing attributes and methods are never removed. + + +## Unstable interfaces + +* **The set of states of the various state machines used in systemd**, + e.g. the high-level unit states `inactive`, `active`, `deactivating`, and so on, + as well as the low-level unit states. +* **All "special" units that aren't listed above**. -## Interface Portability And Stability Chart +* **The internal protocols** used on the various sockets such as + `/run/systemd/shutdown`, `/run/systemd/private`. -systemd provides a number of APIs to applications. -Below you'll find a table detailing which APIs are considered stable and how portable they are. +* **The private shared libraries** like `libsystemd-shared.so` which + are installed into a private systemd directory. -This list is intended to be useful for distribution and OS developers who are interested in maintaining a certain level of compatibility with the new interfaces systemd introduced, without relying on systemd itself. -In general it is our intention to cooperate through interfaces and not code with other distributions and OSes. -That means that the interfaces where this applies are best reimplemented in a compatible fashion on those other operating systems. -To make this easy we provide detailed interface documentation where necessary. -That said, it's all Open Source, hence you have the option to a) fork our code and maintain portable versions of the parts you are interested in independently for your OS, or b) build systemd for your distro, but leave out all components except the ones you are interested in and run them without the core of systemd involved. -We will try not to make this any more difficult than necessary. -Patches to allow systemd code to be more portable will be accepted on case-by-case basis (essentially, patches to follow well-established standards instead of e.g. glibc or linux extensions have a very high chance of being accepted, while patches which make the code ugly or exist solely to work around bugs in other projects have a low chance of being accepted). +## Portability -Many of these interfaces are already being used by applications and 3rd party code. -If you are interested in compatibility with these applications, please consider supporting these interfaces in your distribution, where possible. +One of the main goals of the systemd project +is to unify basic Linux configuration mechanism and service behaviour across distributions. +Systemd project does not contain any distribution-specific parts. +Distributions are expected over time to convert their individual configurations to the systemd format. ## General Portability of systemd and its Components @@ -84,106 +112,39 @@ If you are interested in compatibility with these applications, please consider **Portability to OSes:** systemd is not portable to non-Linux systems. It makes use of a large number of Linux-specific interfaces, including many that are used by its very core. We do not consider it feasible to port systemd to other Unixes (let alone non-Unix operating systems) and will not accept patches for systemd core implementing any such portability (but hey, it's git, so it's as easy as it can get to maintain your own fork...). -APIs that are supposed to be used as library code are exempted from this: it is important to us that these compile nicely on non-Linux and even non-Unix platforms, even if they might just become NOPs. - -**Portability to Architectures:** It is important to us that systemd is portable to little endian as well as big endian systems. -We will make sure to provide portability with all important architectures and hardware Linux runs on and are happy to accept patches for this. -**Portability to Distributions:** It is important to us that systemd is portable to all Linux distributions. -However, the goal is to unify many of the needless differences between the distributions, and hence will not accept patches for certain distribution-specific work-arounds. -Compatibility with the distribution's legacy should be maintained in the distribution's packaging, and not in the systemd source tree. - -**Compatibility with Specific Versions of Other packages:** We generally avoid adding compatibility kludges to systemd that work around bugs in certain versions of other software systemd interfaces with. We strongly encourage fixing bugs where they are, and if that's not systemd we rather not try to fix it there. +**Portability to Architectures:** Systemd is portable to little endian as well as big endian systems. +We maintain portability to all common architectures and hardware Linux runs on and are happy to accept patches for this. + +**Portability to Distributions:** +It is important to us that systemd is portable to all Linux distributions. +However, the goal is to unify many of the needless differences between the distributions, +and hence we will not accept patches for distribution-specific work-arounds. +Compatibility with the distribution's legacy should be maintained in the distribution's packaging, +and not in the systemd source tree. + +**Compatibility with Specific Versions of Other packages:** +We generally avoid adding compatibility kludges to systemd that +work around bugs in certain versions of other software systemd interfaces with. +We strongly encourage fixing bugs where they are, +and if that's not systemd we rather not try to fix it here. (There are very few exceptions to this rule possible, and you need an exceptionally strong case for it). ## General Portability of systemd's APIs systemd's APIs are available everywhere where systemd is available. -Some of the APIs we have defined are supposed to be generic enough to be implementable independently of systemd, thus allowing compatibility with systems systemd itself is not compatible with, i.e. other OSes, and distributions that are unwilling to fully adopt systemd. - -A number of systemd's APIs expose Linux or systemd-specific features that cannot sensibly be implemented elsewhere. -Please consult the table below for information about which ones these are. - -Note that not all of these interfaces are our invention (but most), we just adopted them in systemd to make them more prominently implemented. -For example, we adopted many Debian facilities in systemd to push it into the other distributions as well. +Some of the APIs we have defined are supposed to be generic enough +to be implementable independently of systemd, +thus allowing compatibility with systems systemd itself is not compatible with, +i.e. other OSes, and distributions that are unwilling to fully adopt systemd. +A number of systemd's APIs expose Linux or systemd-specific features +that cannot sensibly be implemented elsewhere. ---- - +Note that not all of these interfaces are our invention (but most), +we just adopted them in systemd to make them more prominently implemented. -And now, here's the list of (hopefully) all APIs that we have introduced with systemd: - -| API | Type | Covered by Interface Stability Promise | Fully documented | Known External Consumers | Reimplementable Independently | Known Other Implementations | systemd Implementation portable to other OSes or non-systemd distributions | -| --- | ---- | ----------------------------------------------------------------------------------------- | ---------------- | ------------------------ | ----------------------------- | --------------------------- | -------------------------------------------------------------------------- | -| [hostnamed](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.hostname1.html) | D-Bus | yes | yes | GNOME | yes | [Ubuntu](https://launchpad.net/ubuntu/+source/ubuntu-system-service), [Gentoo](https://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml), [BSD](http://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary) | partially | -| [localed](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.locale1.html) | D-Bus | yes | yes | GNOME | yes | [Ubuntu](https://launchpad.net/ubuntu/+source/ubuntu-system-service), [Gentoo](https://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml), [BSD](http://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary) | partially | -| [timedated](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.timedate1.html) | D-Bus | yes | yes | GNOME | yes | [Gentoo](https://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml), [BSD](http://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary) | partially | -| [initrd interface](/INITRD_INTERFACE) | Environment, flag files | yes | yes | mkosi, dracut, ArchLinux | yes | ArchLinux | no | -| [Container interface](/CONTAINER_INTERFACE) | Environment, Mounts | yes | yes | libvirt/LXC | yes | - | no | -| [Boot Loader interface](/BOOT_LOADER_INTERFACE) | EFI variables | yes | yes | gummiboot | yes | - | no | -| [Service bus API](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.systemd1.html) | D-Bus | yes | yes | system-config-services | no | - | no | -| [logind](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.login1.html) | D-Bus | yes | yes | GNOME | no | - | no | -| [sd-bus.h API](https://www.freedesktop.org/software/systemd/man/latest/sd-bus.html) | C Library | yes | yes | - | maybe | - | maybe | -| [sd-daemon.h API](https://www.freedesktop.org/software/systemd/man/latest/sd-daemon.html) | C Library or Drop-in | yes | yes | numerous | yes | - | yes | -| [sd-device.h API](https://www.freedesktop.org/software/systemd/man/latest/sd-device.html) | C Library | yes | no | numerous | yes | - | yes | -| [sd-event.h API](https://www.freedesktop.org/software/systemd/man/latest/sd-event.html) | C Library | yes | yes | - | maybe | - | maybe | -| [sd-gpt.h API](https://www.freedesktop.org/software/systemd/man/latest/libsystemd.html) | Header Library | yes | no | - | yes | - | yes | -| [sd-hwdb.h API](https://www.freedesktop.org/software/systemd/man/latest/sd-hwdb.html) | C Library | yes | yes | - | maybe | - | yes | -| [sd-id128.h API](https://www.freedesktop.org/software/systemd/man/latest/sd-id128.html) | C Library | yes | yes | - | yes | - | yes | -| [sd-journal.h API](https://www.freedesktop.org/software/systemd/man/latest/sd-journal.html) | C Library | yes | yes | - | maybe | - | no | -| [sd-login.h API](https://www.freedesktop.org/software/systemd/man/latest/sd-login.html) | C Library | yes | yes | GNOME, polkit, ... | no | - | no | -| [sd-messages.h API](https://www.freedesktop.org/software/systemd/man/latest/libsystemd.html) | Header Library | yes | yes | - | yes | python-systemd | yes | -| [sd-path.h API](https://www.freedesktop.org/software/systemd/man/latest/sd-path.html) | C Library | yes | no | - | maybe | - | maybe | -| [$XDG_RUNTIME_DIR](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) | Environment | yes | yes | glib, GNOME | yes | - | no | -| [$LISTEN_FDS $LISTEN_PID FD Passing](https://www.freedesktop.org/software/systemd/man/latest/sd_listen_fds.html) | Environment | yes | yes | numerous (via sd-daemon.h) | yes | - | no | -| [$NOTIFY_SOCKET Daemon Notifications](https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html) | Environment | yes | yes | a few, including udev | yes | - | no | -| [argv[0][0]='@' Logic](/ROOT_STORAGE_DAEMONS) | `/proc` marking | yes | yes | mdadm | yes | - | no | -| [Unit file format](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html) | File format | yes | yes | numerous | no | - | no | -| [Network](https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html) & [Netdev file format](https://www.freedesktop.org/software/systemd/man/latest/systemd.netdev.html) | File format | yes | yes | no | no | - | no | -| [Link file format](https://www.freedesktop.org/software/systemd/man/latest/systemd.link.html) | File format | yes | yes | no | no | - | no | -| [Journal File Format](/JOURNAL_FILE_FORMAT) | File format | yes | yes | - | maybe | - | no | -| [Journal Export Format](JOURNAL_EXPORT_FORMATS#journal-export-format) | File format | yes | yes | - | yes | - | no | -| [Journal JSON Format](JOURNAL_EXPORT_FORMATS#journal-json-format) | File format | yes | yes | - | yes | - | no | -| [Password Agents](/PASSWORD_AGENTS) | Socket+Files | yes | yes | - | yes | - | no | -| [udev multi-seat properties](https://www.freedesktop.org/software/systemd/man/latest/sd-login.html) | udev Property | yes | yes | X11, gdm | no | - | no | -| udev session switch ACL properties | udev Property | no | no | - | no | - | no | -| [CLI of systemctl,...](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) | CLI | yes | yes | numerous | no | - | no | -| [tmpfiles.d](https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html) | File format | yes | yes | numerous | yes | ArchLinux | partially | -| [sysusers.d](https://www.freedesktop.org/software/systemd/man/latest/sysusers.d.html) | File format | yes | yes | unknown | yes | | partially | -| [/etc/machine-id](https://www.freedesktop.org/software/systemd/man/latest/machine-id.html) | File format | yes | yes | D-Bus | yes | - | no | -| [binfmt.d](https://www.freedesktop.org/software/systemd/man/latest/binfmt.d.html) | File format | yes | yes | numerous | yes | - | partially | -| [/etc/hostname](https://www.freedesktop.org/software/systemd/man/latest/hostname.html) | File format | yes | yes | numerous (it's a Debian thing) | yes | Debian, ArchLinux | no | -| [/etc/locale.conf](https://www.freedesktop.org/software/systemd/man/latest/locale.conf.html) | File format | yes | yes | - | yes | ArchLinux | partially | -| [/etc/machine-info](https://www.freedesktop.org/software/systemd/man/latest/machine-info.html) | File format | yes | yes | - | yes | - | partially | -| [modules-load.d](https://www.freedesktop.org/software/systemd/man/latest/modules-load.d.html) | File format | yes | yes | numerous | yes | - | partially | -| [/usr/lib/os-release](https://www.freedesktop.org/software/systemd/man/latest/os-release.html) | File format | yes | yes | some | yes | Fedora, OpenSUSE, ArchLinux, Angstrom, Frugalware, others... | no | -| [sysctl.d](https://www.freedesktop.org/software/systemd/man/latest/sysctl.d.html) | File format | yes | yes | some (it's a Debian thing) | yes | procps/Debian, ArchLinux | partially | -| [/etc/vconsole.conf](https://www.freedesktop.org/software/systemd/man/latest/vconsole.conf.html) | File format | yes | yes | - | yes | ArchLinux | partially | -| `/run` | File hierarchy change | yes | yes | numerous | yes | OpenSUSE, Debian, ArchLinux | no | -| [Generators](https://www.freedesktop.org/software/systemd/man/latest/systemd.generator.html) | Subprocess | yes | yes | - | no | - | no | -| [System Updates](https://www.freedesktop.org/software/systemd/man/latest/systemd.offline-updates.html) | System Mode | yes | yes | - | no | - | no | -| [Presets](https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html) | File format | yes | yes | - | no | - | no | -| Udev rules | File format | yes | yes | numerous | no | no | partially | - - -### Explanations - -Items for which "systemd implementation portable to other OSes" is "partially" means that it is possible to run the respective tools that are included in the systemd tarball outside of systemd. -Note however that this is not officially supported, so you are more or less on your own if you do this. -If you are opting for this solution simply build systemd as you normally would but drop all files except those which you are interested in. - -Of course, it is our intention to eventually document all interfaces we defined. -If we haven't documented them for now, this is usually because we want the flexibility to still change things, or don't want 3rd party applications to make use of these interfaces already. -That said, our sources are quite readable and open source, so feel free to spelunk around in the sources if you want to know more. - -If you decide to reimplement one of the APIs for which "Reimplementable independently" is "no", then we won't stop you, but you are on your own. - -This is not an attempt to comprehensively list all users of these APIs. -We are just listing the most obvious/prominent ones which come to our mind. - -Of course, one last thing I can't make myself not ask you before we finish here, and before you start reimplementing these APIs in your distribution: -are you sure it's time well spent if you work on reimplementing all this code instead of just spending it on adopting systemd on your distro as well? ## Independent Operation of systemd Programs