mirror of
https://github.com/systemd/systemd
synced 2024-09-19 08:03:31 +00:00
934ef6a522
Upon an incoming connection for an accepting socket, we'd create a unit like foo@0.service, then figure out that the instance name should be e.g. "0-41-0", and then add the name foo@0-41-0.service to the unit. This obviously violates the rule that any service needs to have a constance instance part. So let's reverse the order: we first determine the instance name and then create the unit with the correct name from the start. There are two cases where we don't know the instance name: - analyze-verify: we just do a quick check that the instance unit can be created. So let's use a bogus instance string. - selinux: the code wants to load the service unit to extract the ExecStart path and query it for the selinux label. Do the same as above. Note that in both cases it is possible that the real unit that is loaded could be different than the one with the bogus instance value, for example if there is a dropin for a specific instance name. We can't do much about this, since we can't figure out the instance name in advance. The old code had the same shortcoming. |
||
---|---|---|
.github | ||
.lgtm/cpp-queries | ||
.mkosi | ||
catalog | ||
coccinelle | ||
docs | ||
factory/etc | ||
hwdb.d | ||
man | ||
modprobe.d | ||
network | ||
po | ||
presets | ||
rules.d | ||
semaphoreci | ||
shell-completion | ||
src | ||
sysctl.d | ||
sysusers.d | ||
test | ||
tmpfiles.d | ||
tools | ||
travis-ci | ||
units | ||
xorg | ||
.clang-format | ||
.ctags | ||
.dir-locals.el | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.lgtm.yml | ||
.mailmap | ||
.travis.yml | ||
.vimrc | ||
.ycm_extra_conf.py | ||
azure-pipelines.yml | ||
configure | ||
LICENSE.GPL2 | ||
LICENSE.LGPL2.1 | ||
Makefile | ||
meson.build | ||
meson_options.txt | ||
mkosi.build | ||
mkosi.default | ||
NEWS | ||
README | ||
README.md | ||
TODO | ||
zanata.xml |
System and Service Manager
Details
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.