1da37e58ff
We close fds in two phases, first some and then the some more. When passing a list of fds to exclude from closing to the closing function, we would pass some in an array and the rest as separate arguments. For the fds which should be excluded in both closing phases, let's always create the array and put the relevant fds there. This has the advantage that if more fds to exclude in both phases are added later, we don't need to add more positional arguments. The list passed to setup_pam() is not changed. I think we could pass more fds to close there, but I'm leaving that unchanged. The setting of FD_CLOEXEC on an already open fds is dropped. The fd is opened in service_allocate_exec_fd() and there is no reason to suspect that it might have been opened incorrectly. If some rogue code is unsetting our FD_CLOEXEC bits, then it might flip any fd, no reason to single this one out. |
||
|---|---|---|
| .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.