Consult our [NEWS file](NEWS) for information about what's new in the most recent systemd versions.
-Please see the [Code Map](docs/ARCHITECTURE.md) for information about this repository's layout and content.
+Please see the [Code Map](docs/_contributing/ARCHITECTURE.md) for information about this repository's layout and content.
-Please see the [Hacking guide](docs/HACKING.md) for information on how to hack on systemd and test your modifications.
+Please see the [Hacking guide](docs/_contributing/HACKING.md) for information on how to hack on systemd and test your modifications.
-Please see our [Contribution Guidelines](docs/CONTRIBUTING.md) for more information about filing GitHub Issues and posting GitHub Pull Requests.
+Please see our [Contribution Guidelines](docs/_contributing/CONTRIBUTING.md) for more information about filing GitHub Issues and posting GitHub Pull Requests.
-When preparing patches for systemd, please follow our [Coding Style Guidelines](docs/CODING_STYLE.md).
+When preparing patches for systemd, please follow our [Coding Style Guidelines](docs/_contributing/CODING_STYLE.md).
If you are looking for support, please contact our [mailing list](https://lists.freedesktop.org/mailman/listinfo/systemd-devel), join our [IRC channel #systemd on libera.chat](https://web.libera.chat/#systemd) or [Matrix channel](https://matrix.to/#/#systemd-project:matrix.org)
* `1 << 1` → The boot loader honours `LoaderConfigTimeoutOneShot` when set.
* `1 << 2` → The boot loader honours `LoaderEntryDefault` when set.
* `1 << 3` → The boot loader honours `LoaderEntryOneShot` when set.
- * `1 << 4` → The boot loader supports boot counting as described in [Automatic Boot Assessment](AUTOMATIC_BOOT_ASSESSMENT.md).
+ * `1 << 4` → The boot loader supports boot counting as described in [Automatic Boot Assessment](AUTOMATIC_BOOT_ASSESSMENT).
* `1 << 5` → The boot loader supports looking for boot menu entries in the Extended Boot Loader Partition.
* `1 << 6` → The boot loader supports passing a random seed to the OS.
* `1 << 13` → The boot loader honours `menu-disabled` option when set.
8. Credentials are an effective way to pass parameters into services that run
with `RootImage=` or `RootDirectory=` and thus cannot read these resources
directly from the host directory tree.
- Specifically, [Portable Services](PORTABLE_SERVICES.md) may be
+ Specifically, [Portable Services](PORTABLE_SERVICES) may be
parameterized this way securely and robustly.
9. Credentials can be binary and relatively large (though currently an overall
invokes. [`systemd-nspawn(1)`](https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#Credentials)'s
`--set-credential=` and `--load-credential=` switches implement this, in
order to pass arbitrary credentials from host to container payload. Also see
- the [Container Interface](CONTAINER_INTERFACE.md) documentation.
+ the [Container Interface](CONTAINER_INTERFACE) documentation.
2. Quite similar, VMs can be passed credentials via SMBIOS OEM strings (example
qemu command line switch `-smbios
for an introduction why. That said, any boot loader can re-implement the
logic described above, and can pass a random seed that systemd as PID 1
will then upload into the kernel's entropy pool. For details see the
- [Boot Loader Interface](BOOT_LOADER_INTERFACE.md) documentation.
+ [Boot Loader Interface](BOOT_LOADER_INTERFACE) documentation.
11. *Why not pass the boot loader random seed via kernel command line instead
of as EFI variable?*
baseurl: "" # the subpath of your site, e.g. /blog/
url: "https://systemd.io" # the base hostname & protocol for your site
-permalink: /:title/
-
# Build settings
markdown: kramdown
+
+collections:
+ concepts:
+ title: 'Concepts'
+ output: true
+ contributing:
+ title: 'Contributing'
+ output: true
+ userdocs:
+ output: true
+ title: 'Documentation for Users and Administrators'
+ booting:
+ title: 'Booting'
+ output: true
+ interfaces:
+ title: 'Interfaces'
+ output: true
+ networking:
+ title: 'Networking'
+ output: true
+ groups:
+ title: 'Users, Groups and Home Directories'
+ output: true
+ devdocs:
+ title: 'Documentation for Developers'
+ output: true
+
with sanitizers and invoked as part of the test suite (if `-Dfuzz-tests=true`
is configured). Thirdly, fuzzers are executed through fuzzing engines that try
to find new "interesting" inputs through coverage feedback and massive
-parallelization; see the links for oss-fuzz in [Code quality](CODE_QUALITY.md).
+parallelization; see the links for oss-fuzz in [Code quality](CODE_QUALITY).
For testing and debugging, fuzzers can be executed as any other program,
including under `valgrind` or `gdb`.
15. Each PR is automatically tested with [Address Sanitizer](https://clang.llvm.org/docs/AddressSanitizer.html)
and [Undefined Behavior Sanitizer](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html).
- See [Testing systemd using sanitizers](TESTING_WITH_SANITIZERS.md)
+ See [Testing systemd using sanitizers](TESTING_WITH_SANITIZERS)
for more information.
16. Fossies provides [source code misspelling reports](https://fossies.org/features.html#codespell).
## Security vulnerability reports
-See [reporting of security vulnerabilities](SECURITY.md).
+See [reporting of security vulnerabilities](SECURITY).
## Posting Pull Requests
* Make sure to post PRs only relative to a recent tip of the `main` branch.
-* Follow our [Coding Style](CODING_STYLE.md) when contributing code. This is a requirement for all code we merge.
-* Please make sure to test your change before submitting the PR. See the [Hacking guide](HACKING.md) for details on how to do this.
+* Follow our [Coding Style](CODING_STYLE) when contributing code. This is a requirement for all code we merge.
+* Please make sure to test your change before submitting the PR. See the [Hacking guide](HACKING) for details on how to do this.
* Make sure to run the test suite locally, before posting your PR. We use a CI system, meaning we don't even look at your PR if the build and tests don't pass.
* If you need to update the code in an existing PR, force-push into the same branch, overriding old commits with new versions.
* After you have pushed a new version, add a comment explaining the latest changes. If you are a member of the systemd project on GitHub, remove the `reviewed/needs-rework`/`ci-fails/needs-rework`/`needs-rebase` labels.
feature, please feel invited to fix it, and submit your work as a
[GitHub Pull Request (PR)](https://github.com/systemd/systemd/pull/new).
-Please make sure to follow our [Coding Style](CODING_STYLE.md) when submitting
-patches. Also have a look at our [Contribution Guidelines](CONTRIBUTING.md).
+Please make sure to follow our [Coding Style](CODING_STYLE) when submitting
+patches. Also have a look at our [Contribution Guidelines](CONTRIBUTING).
When adding new functionality, tests should be added. For shared functionality
(in `src/basic/` and `src/shared/`) unit tests should be sufficient. The general
strongly recommended. If that is not possible, integration tests in `test/` are
encouraged.
-Please also have a look at our list of [code quality tools](CODE_QUALITY.md) we
+Please also have a look at our list of [code quality tools](CODE_QUALITY) we
have setup for systemd, to ensure our codebase stays in good shape.
Please always test your work before submitting a PR. For many of the components
## Sanitizers in mkosi
-See [Testing systemd using sanitizers](TESTING_WITH_SANITIZERS.md) for more information
+See [Testing systemd using sanitizers](TESTING_WITH_SANITIZERS) for more information
on how to build with sanitizers enabled in mkosi.
## Fuzzers
```
If you find a bug that impacts the security of systemd, please follow the
-guidance in [CONTRIBUTING.md](CONTRIBUTING.md) on how to report a security vulnerability.
+guidance in [CONTRIBUTING.md](CONTRIBUTING) on how to report a security vulnerability.
For more details on building fuzzers and integrating with OSS-Fuzz, visit:
[
- {
- "category": "Project",
- "title": "mkosi Project - Build Bespoke OS Images",
- "url": "https://mkosi.systemd.io/"
- },
- {
- "category": "Project",
- "title": "Brand",
- "url": "https://brand.systemd.io/"
- },
- {
- "category": "Project",
- "title": "Mailing List",
- "url": "https://lists.freedesktop.org/mailman/listinfo/systemd-devel"
- },
- {
- "category": "Project",
- "title": "Mastodon",
- "url": "https://mastodon.social/@pid_eins"
- },
- {
- "category": "Project",
- "title": "Releases",
- "url": "https://github.com/systemd/systemd/releases"
- },
- {
- "category": "Project",
- "title": "GitHub Project Page",
- "url": "https://github.com/systemd/systemd"
- },
- {
- "category": "Project",
- "title": "Issues",
- "url": "https://github.com/systemd/systemd/issues"
- },
- {
- "category": "Project",
- "title": "Pull Requests",
- "url": "https://github.com/systemd/systemd/pulls"
- },
{
"category": "Manual Pages",
"title": "Index",
--- /dev/null
+[
+ {
+ "category": "Project",
+ "title": "mkosi Project - Build Bespoke OS Images",
+ "url": "https://mkosi.systemd.io/"
+ },
+ {
+ "collection": "project",
+ "title": "Brand",
+ "url": "https://brand.systemd.io/"
+ },
+ {
+ "collection": "project",
+ "title": "Mailing List",
+ "url": "https://lists.freedesktop.org/mailman/listinfo/systemd-devel"
+ },
+ {
+ "collection": "project",
+ "title": "Mastodon",
+ "url": "https://mastodon.social/@pid_eins"
+ },
+ {
+ "collection": "project",
+ "title": "Releases",
+ "url": "https://github.com/systemd/systemd/releases"
+ },
+ {
+ "collection": "project",
+ "title": "GitHub Project Page",
+ "url": "https://github.com/systemd/systemd"
+ },
+ {
+ "collection": "project",
+ "title": "Issues",
+ "url": "https://github.com/systemd/systemd/issues"
+ },
+ {
+ "collection": "project",
+ "title": "Pull Requests",
+ "url": "https://github.com/systemd/systemd/pulls"
+ }
+]
Before continuing, please read up on these basic concepts:
-* [Home Directories](HOME_DIRECTORY.md)
-* [JSON User Records](USER_RECORD.md)
-* [JSON Group Records](GROUP_RECORD.md)
-* [User/Group Record Lookup API via Varlink](USER_GROUP_API.md)
+* [Home Directories](HOME_DIRECTORY)
+* [JSON User Records](USER_RECORD)
+* [JSON Group Records](GROUP_RECORD)
+* [User/Group Record Lookup API via Varlink](USER_GROUP_API)
## Caveat
# JSON Group Records
Long story short: JSON Group Records are to `struct group` what
-[JSON User Records](USER_RECORD.md) are to `struct passwd`.
+[JSON User Records](USER_RECORD) are to `struct passwd`.
Conceptually, much of what applies to JSON user records also applies to JSON
group records. They also consist of seven sections, with similar properties and
Inside of the home directory a file `~/.identity` contains the JSON formatted
user record of the user. It follows the format defined in
-[`JSON User Records`](USER_RECORD.md). It is recommended to bring the
+[`JSON User Records`](USER_RECORD). It is recommended to bring the
record into 'normalized' form (i.e. all objects should contain their fields
sorted alphabetically by their key) before storing it there, though this is not
required nor enforced. Since the user record is cryptographically signed, the
Before reading on, please read up on the basic concepts, specifically:
-* [Home Directories](HOME_DIRECTORY.md)
-* [JSON User Records](USER_RECORD.md)
-* [JSON Group Records](GROUP_RECORD.md)
-* [User/Group Record Lookup API via Varlink](USER_GROUP_API.md)
+* [Home Directories](HOME_DIRECTORY)
+* [JSON User Records](USER_RECORD)
+* [JSON Group Records](GROUP_RECORD)
+* [User/Group Record Lookup API via Varlink](USER_GROUP_API)
## Support for Suspending Home Directory Access during System Suspend
In case you wonder, there's no automatic mechanism for converting existing
users registered in `/etc/passwd` or LDAP to users managed by
`systemd-homed`. There's documentation for doing this manually though, see
-[Converting Existing Users to systemd-homed managed Users](CONVERTING_TO_HOMED.md).
+[Converting Existing Users to systemd-homed managed Users](CONVERTING_TO_HOMED).
## Future Additions
# User/Group Record Lookup API via Varlink
-JSON User/Group Records (as described in the [JSON User Records](USER_RECORD.md)
-and [JSON Group Records](GROUP_RECORD.md) documents) that are defined on the
+JSON User/Group Records (as described in the [JSON User Records](USER_RECORD)
+and [JSON Group Records](GROUP_RECORD) documents) that are defined on the
local system may be queried with a [Varlink](https://varlink.org/) API. This
API takes both the role of what
[`getpwnam(3)`](https://man7.org/linux/man-pages/man3/getpwnam.3.html) and
1. [`systemd-homed.service`](https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html)
manages `human` user home directories and embeds these JSON records
directly in the home directory images
- (see [Home Directories](HOME_DIRECTORY.md) for details).
+ (see [Home Directories](HOME_DIRECTORY) for details).
2. [`pam_systemd`](https://www.freedesktop.org/software/systemd/man/pam_systemd.html)
processes these JSON records for users that log in, and applies various
4. Default parameters for backup applications and similar
Similar to JSON User Records there are also
-[JSON Group Records](GROUP_RECORD.md) that encapsulate UNIX groups.
+[JSON Group Records](GROUP_RECORD) that encapsulate UNIX groups.
JSON User Records are not suitable for storing all identity information about
the user, such as binary data or large unstructured blobs of text. These parts
JSON User Records may be transferred or written to disk in various protocols
and formats. To inquire about such records defined on the local system use the
-[User/Group Lookup API via Varlink](USER_GROUP_API.md). User/group records may
+[User/Group Lookup API via Varlink](USER_GROUP_API). User/group records may
also be dropped in number of drop-in directories as files. See
[`nss-systemd(8)`](https://www.freedesktop.org/software/systemd/man/nss-systemd.html)
for details.
UNIX user name. This field is the only mandatory field, all others are
optional. Corresponds with the `pw_name` field of `struct passwd` and the
`sp_namp` field of `struct spwd` (i.e. the shadow user record stored in
-`/etc/shadow`). See [User/Group Name Syntax](USER_NAMES.md) for
+`/etc/shadow`). See [User/Group Name Syntax](USER_NAMES) for
the (relaxed) rules the various systemd components enforce on user/group names.
`realm` → The "realm" a user is defined in. This concept allows distinguishing
line options, for example `--log-level=` and similar.
* Storage daemons run from the initrd should follow the guide on
- [systemd and Storage Daemons for the Root File System](ROOT_STORAGE_DAEMONS.md)
+ [systemd and Storage Daemons for the Root File System](ROOT_STORAGE_DAEMONS)
to survive properly from the boot initrd all the way to the point where
systemd jumps back into the initrd for shutdown.
* The switch-root operation will result in a killing spree of all running
processes. Some processes might need to be excluded from that, see the guide
- on [systemd and Storage Daemons for the Root File System](ROOT_STORAGE_DAEMONS.md).
+ on [systemd and Storage Daemons for the Root File System](ROOT_STORAGE_DAEMONS).
_Note that this document describes the binary serialization format of journals only, as used for transfer across the network.
For interfacing with web technologies there's the Journal JSON Format, described below.
-The binary format on disk is documented as the [Journal File Format](JOURNAL_FILE_FORMAT.md)._
+The binary format on disk is documented as the [Journal File Format](JOURNAL_FILE_FORMAT)._
_Before reading on, please make sure you are aware of the [basic properties of journal entries](https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html), in particular realize that they may include binary non-text data (though usually don't), and the same field might have multiple values assigned within the same entry (though usually hasn't)._
_Note that this section describes the JSON serialization format of the journal only, as used for interfacing with web technologies.
For binary transfer of journal data across the network there's the Journal Export Format described above.
-The binary format on disk is documented as [Journal File Format](JOURNAL_FILE_FORMAT.md)._
+The binary format on disk is documented as [Journal File Format](JOURNAL_FILE_FORMAT)._
_Before reading on, please make sure you are aware of the [basic properties of journal entries](https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html), in particular realize that they may include binary non-text data (though usually don't), and the same field might have multiple values assigned within the same entry (though usually hasn't)._
you want to use as base of your project. You want our [C
API](https://www.freedesktop.org/software/systemd/man/sd-journal.html) instead!
And if you really don't want the C API, then you want the
-[Journal Export Format or Journal JSON Format](JOURNAL_EXPORT_FORMATS.md)
+[Journal Export Format or Journal JSON Format](JOURNAL_EXPORT_FORMATS)
instead! This document is primarily for your entertainment and education.
Thank you!_
| [hostnamed](https://www.freedesktop.org/software/systemd/man/org.freedesktop.hostname1.html) | D-Bus | yes | yes | GNOME | yes | [Ubuntu](https://launchpad.net/ubuntu/+source/ubuntu-system-service), [Gentoo](http://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml), [BSD](http://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary) | partially |
| [localed](https://www.freedesktop.org/software/systemd/man/org.freedesktop.locale1.html) | D-Bus | yes | yes | GNOME | yes | [Ubuntu](https://launchpad.net/ubuntu/+source/ubuntu-system-service), [Gentoo](http://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml), [BSD](http://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary) | partially |
| [timedated](https://www.freedesktop.org/software/systemd/man/org.freedesktop.timedate1.html) | D-Bus | yes | yes | GNOME | yes | [Gentoo](http://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml), [BSD](http://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary) | partially |
-| [initrd interface](INITRD_INTERFACE.md) | Environment, flag files | yes | yes | mkosi, dracut, ArchLinux | yes | ArchLinux | no |
-| [Container interface](CONTAINER_INTERFACE.md) | Environment, Mounts | yes | yes | libvirt/LXC | yes | - | no |
-| [Boot Loader interface](BOOT_LOADER_INTERFACE.md) | EFI variables | yes | yes | gummiboot | yes | - | no |
+| [initrd interface](INITRD_INTERFACE) | Environment, flag files | yes | yes | mkosi, dracut, ArchLinux | yes | ArchLinux | no |
+| [Container interface](CONTAINER_INTERFACE) | Environment, Mounts | yes | yes | libvirt/LXC | yes | - | no |
+| [Boot Loader interface](BOOT_LOADER_INTERFACE) | EFI variables | yes | yes | gummiboot | yes | - | no |
| [Service bus API](https://www.freedesktop.org/software/systemd/man/org.freedesktop.systemd1.html) | D-Bus | yes | yes | system-config-services | no | - | no |
| [logind](https://www.freedesktop.org/software/systemd/man/org.freedesktop.login1.html) | D-Bus | yes | yes | GNOME | no | - | no |
| [sd-bus.h API](https://www.freedesktop.org/software/systemd/man/sd-bus.html) | C Library | yes | yes | - | maybe | - | maybe |
| [$XDG_RUNTIME_DIR](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) | Environment | yes | yes | glib, GNOME | yes | - | no |
| [$LISTEN_FDS $LISTEN_PID FD Passing](https://www.freedesktop.org/software/systemd/man/sd_listen_fds.html) | Environment | yes | yes | numerous (via sd-daemon.h) | yes | - | no |
| [$NOTIFY_SOCKET Daemon Notifications](https://www.freedesktop.org/software/systemd/man/sd_notify.html) | Environment | yes | yes | a few, including udev | yes | - | no |
-| [argv[0][0]='@' Logic](ROOT_STORAGE_DAEMONS.md) | `/proc` marking | yes | yes | mdadm | yes | - | no |
+| [argv[0][0]='@' Logic](ROOT_STORAGE_DAEMONS) | `/proc` marking | yes | yes | mdadm | yes | - | no |
| [Unit file format](https://www.freedesktop.org/software/systemd/man/systemd.unit.html) | File format | yes | yes | numerous | no | - | no |
| [Network](https://www.freedesktop.org/software/systemd/man/systemd.network.html) & [Netdev file format](https://www.freedesktop.org/software/systemd/man/systemd.netdev.html) | File format | yes | yes | no | no | - | no |
| [Link file format](https://www.freedesktop.org/software/systemd/man/systemd.link.html) | File format | yes | yes | no | no | - | no |
-| [Journal File Format](JOURNAL_FILE_FORMAT.md) | File format | yes | yes | - | maybe | - | no |
+| [Journal File Format](JOURNAL_FILE_FORMAT) | File format | yes | yes | - | maybe | - | no |
| [Journal Export Format](JOURNAL_EXPORT_FORMATS.md#journal-export-format) | File format | yes | yes | - | yes | - | no |
| [Journal JSON Format](JOURNAL_EXPORT_FORMATS.md#journal-json-format) | File format | yes | yes | - | yes | - | no |
| [Cooperation in cgroup tree](https://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups) | Treaty | yes | yes | libvirt | yes | libvirt | no |
-| [Password Agents](PASSWORD_AGENTS.md) | Socket+Files | yes | yes | - | yes | - | no |
+| [Password Agents](PASSWORD_AGENTS) | Socket+Files | yes | yes | - | yes | - | no |
| [udev multi-seat properties](https://www.freedesktop.org/software/systemd/man/sd-login.html) | udev Property | yes | yes | X11, gdm | no | - | no |
| udev session switch ACL properties | udev Property | no | no | - | no | - | no |
| [CLI of systemctl,...](https://www.freedesktop.org/software/systemd/man/systemctl.html) | CLI | yes | yes | numerous | no | - | no |
The recommended way to distinguish between run-from-initrd and run-from-rootfs
for a daemon is to check for `/etc/initrd-release` (which exists on all modern
-initrd implementations, see the [initrd Interface](INITRD_INTERFACE.md) for
+initrd implementations, see the [initrd Interface](INITRD_INTERFACE) for
details) which when exists results in `argv[0][0]` being set to `@`, and
otherwise doesn't. Something like this:
program consult this blog story: [Socket
Activation](https://0pointer.de/blog/projects/socket-activation.html)
-* Consider having a look at the [initrd Interface of systemd](INITRD_INTERFACE.md).
+* Consider having a look at the [initrd Interface of systemd](INITRD_INTERFACE).
* LSB header dependency information matters. The SysV implementations on many distributions did not use the dependency information encoded in LSB init script headers, or used them only in very limited ways. Due to that they are often incorrect or incomplete. systemd however fully interprets these headers and follows them closely at runtime (and not at installation time like some implementations).
* Timeouts apply to all init script operations in systemd. While on SysV systems a hanging init script could freeze the system on systemd all init script operations are subject to a timeout of 5min.
* Services are executed in completely clean execution contexts, no context of the invoking user session is inherited. Not even $HOME or similar are set. Init scripts depending on these will not work correctly.
-* Services cannot read from stdin, as this will be connected to /dev/null. That means interactive init scripts are not supported (i.e. Debian's X-Interactive in the LSB header is not supported either.) Thankfully most distributions do not support interaction in init scripts anyway. If you need interaction to ask disk or SSL passphrases please consider using the minimal password querying framework systemd supports. ([details](../PASSWORD_AGENTS), [manual page](http://0pointer.de/public/systemd-man/systemd-ask-password.html))
+* Services cannot read from stdin, as this will be connected to /dev/null. That means interactive init scripts are not supported (i.e. Debian's X-Interactive in the LSB header is not supported either.) Thankfully most distributions do not support interaction in init scripts anyway. If you need interaction to ask disk or SSL passphrases please consider using the minimal password querying framework systemd supports. ([details](PASSWORD_AGENTS), [manual page](http://0pointer.de/public/systemd-man/systemd-ask-password.html))
* Additional verbs for init scripts are not supported. If your init script traditionally supported additional verbs for your init script simply move them to an auxiliary script.
* Additional parameters to the standard verbs (i.e. to "start", "stop" and "status") are not supported. This was an extension of SysV that never was standardized officially, and is not supported in systemd.
* Overriding the "restart" verb is not supported. This verb is always implemented by systemd itself, and consists of a "stop" followed by a "start".
Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.
---
+## Project
+{% for page in site.data.project %}
+* [{{ page.title }}]({{ page.url | relative_url }}){% endfor %}
+
+<!-- Collections -->
+{% for c in site.collections %}
+<!-- hide autegenerated posts collection -->
+{% if c.label != "posts" %}
+## {{ c.title }}
+{% for item in site[c.label] %}
+* [{{ item.title }}]({{ item.url | relative_url }}){% endfor %}
+{% endif %}
+{% endfor %}
-{% assign by_category = site.pages | group_by:"category" %}
-{% assign extra_pages = site.data.extra_pages | group_by:"category" %}
-{% assign merged = by_category | concat: extra_pages | sort:"name" %}
+<!-- external pages -->
+{% assign external_pages = site.data.extra_pages | group_by:"category" %}
-{% for pair in merged %}
- {% if pair.name != "" %}
-## {{ pair.name }}
-{% assign sorted = pair.items | sort:"title" %}{% for page in sorted %}
+{% for category in external_pages %}
+## {{ category.name }}
+{% assign sorted = category.items | sort:"title" %}{% for page in sorted %}
* [{{ page.title }}]({{ page.url | relative_url }}){% endfor %}
- {% endif %}
{% endfor %}
## See also
'LICENSE.LGPL2.1',
'NEWS',
'README',
- 'docs/CODING_STYLE.md',
- 'docs/DISTRO_PORTING.md',
- 'docs/ENVIRONMENT.md',
- 'docs/HACKING.md',
- 'docs/TRANSIENT-SETTINGS.md',
- 'docs/TRANSLATORS.md',
- 'docs/UIDS-GIDS.md',
+ 'docs/_contributing/CODING_STYLE.md',
+ 'docs/_concepts/DISTRO_PORTING.md',
+ 'docs/_interfaces/ENVIRONMENT.md',
+ 'docs/_contributing/HACKING.md',
+ 'docs/_interfaces/TRANSIENT-SETTINGS.md',
+ 'docs/_contributing/TRANSLATORS.md',
+ 'docs/_groups/UIDS-GIDS.md',
install_dir : docdir)
install_subdir('LICENSES',
export PAGER=
# Create a couple of user/group records to test io.systemd.DropIn
-# See docs/USER_RECORD.md and docs/GROUP_RECORD.md
+# See docs/_groups/USER_RECORD.md and docs/_groups/GROUP_RECORD.md
mkdir -p /run/userdb/
cat >"/run/userdb/dropingroup.group" <<\EOF
{
projects / thirdparty / systemd.git / commitdiff
