91d149cfb4
We have a number of components these days that are split into multiple binaries, i.e. a primary one, and a worker callout usually. These binaries are closely related, they typically speak a protocol that is internal, and not safe to mix and match. Examples for this: - homed and its worker binary homework - userdbd and its worker binary userwork - import and the various pull/import/export handlers - sysupdate the same - the service manager and the executor binary Running any of these daemons directly from the meson build tree is messy, since the implementations will typically invoke the installed callout binaries, not the ones from the build tree. This is very annoying, and not obvious at first. Now, we could always invoke relevant binaries from $(dirname /proc/self/exe) first, before using the OS installed ones. But that's typically not what is desired, because this means in the installed case (i.e. the usual one) we'll look for these callout binaries at a place they typically will not be found (because these callouts generally are located in libexecdir, not bindir when installed). Hence, let's try to do things a bit smarter, and follow what build systems such as meson have already been doing to make sure dynamic library discovery works correctly when binaries are run from a build directory: let's start looking at rpath/runpath in the main binary that is executed: if there's an rpath/runpath set, then we'll look for the callout binaries next to the main binary, otherwise we won't. This should generally be the right thing to do as meson strips the rpath during installation, and thus we'll look for the callouts in the build dir if in build dir mode, and in the OS otherwise.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.