3aa5765843
The general idea is that when a unit file is "linked" (i.e. installed by symlinking from outside of the search paths), the *destination* name is irrelevant. It doesn't even have to be a valid unit name, or to match the type or instance value. The obvious collorary is that we shouldn't look at the symlink destination name to derive the unit name, instance value, or anything else at all. When building the name map, when we find a linked unit (possibly at the end of a series of alias redirects), store the *source* of the final symlink as the fragment path. This has two effects: - we stop looking at the *target* file name to derive unit info, i.e. actually implement the stuff described in the first paragraph. - we load the unit fragment through the symlink. If someone were to remove the symlink, we'll not load the unit. This seems like the right thing. Fixes #18058. Before this change, we were generally quite confused about unit alises for linked units. Fortunately most poeple use the same symlink source and target, so in practice we wouldn't hit this too often. In unit_load_fragment() a comment is added to explain what we're doing there. |
||
|---|---|---|
| .github | ||
| .lgtm/cpp-queries | ||
| .mkosi | ||
| .semaphore | ||
| catalog | ||
| coccinelle | ||
| docs | ||
| factory/etc | ||
| hwdb.d | ||
| man | ||
| mkosi.default.d | ||
| modprobe.d | ||
| network | ||
| po | ||
| presets | ||
| rules.d | ||
| shell-completion | ||
| src | ||
| sysctl.d | ||
| sysusers.d | ||
| test | ||
| tmpfiles.d | ||
| tools | ||
| units | ||
| xorg | ||
| .clang-format | ||
| .ctags | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .lgtm.yml | ||
| .mailmap | ||
| .packit.yml | ||
| .vimrc | ||
| .ycm_extra_conf.py | ||
| configure | ||
| LICENSE.GPL2 | ||
| LICENSE.LGPL2.1 | ||
| Makefile | ||
| meson_options.txt | ||
| meson.build | ||
| mkosi.build | ||
| NEWS | ||
| README | ||
| README.md | ||
| TODO | ||
| zanata.xml | ||
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 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 or join our IRC channel.
Stable branches with backported patches are available in the stable repo.