335d2eadca
Instead of first becoming a controlling process of the payload pty as side effect of opening it (without O_NOCTTY), and then possibly dropping it again, let's do it cleanly an reverse the logic: let's open the pty without becoming its controller first. Only after everything went the way we wanted it to go become the controller explicitly. This has the benefit that the PID 1 stub process we run (as effect of --as-pid2) doesn't have to lose the tty explicitly, but can just continue running with things. And we explicitly make the tty controlling right before invoking actual payload. In order to make sure everything works as expected validate that the stub PID 1 in the container really has no conrolling tty by issuing the TIOCNOTTY tty and expecting ENOTTY, and log about it. This shouldn't change behaviour much, it just makes thins a bit cleaner, in particular as we'll not trigger SIGHUP on ourselves (since we are controller and session leader) due to TIOCNOTTY which we then have to explicitly ignore. |
||
---|---|---|
.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 | ||
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.