Consult our [NEWS file](NEWS) for information about what's new in the most recent systemd versions.
-Please see the [Code Map](docs/_contributing/ARCHITECTURE.md) for information about this repository's layout and content.
+Please see the [Code Map](docs/ARCHITECTURE.md) for information about this repository's layout and content.
-Please see the [Hacking guide](docs/_contributing/HACKING.md) for information on how to hack on systemd and test your modifications.
+Please see the [Hacking guide](docs/HACKING.md) for information on how to hack on systemd and test your modifications.
-Please see our [Contribution Guidelines](docs/_contributing/CONTRIBUTING.md) for more information about filing GitHub Issues and posting GitHub Pull Requests.
+Please see our [Contribution Guidelines](docs/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/_contributing/CODING_STYLE.md).
+When preparing patches for systemd, please follow our [Coding Style Guidelines](docs/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. Disable any mounting on `/tmp` so that it resides on the same physical file system as the root directory. For that, execute `systemctl mask tmp.mount`
2. Mount a different, physical file system to `/tmp`. For that, simply create an entry for it in `/etc/fstab` as you would do for any other file system.
3. Keep `/tmp` but increase/decrease the size of it. For that, also just create an entry for it in `/etc/fstab` as you would do for any other `tmpfs` file system, and use the right `size=` option.
-
[https://github.com/systemd/systemd](https://github.com/systemd/systemd)
[http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/](http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/)
-
* Use the [native Journal logging APIs](http://0pointer.de/blog/projects/journal-submit.html) to generate your messages, and define message IDs for all messages you want to add catalog entries for. You may use `journalctl --new-id128` to allocate new message IDs.
* Write a catalog entry file for your messages and ship them in your package and install them to `/usr/lib/systemd/catalog/` (if you package your software with RPM use `%_journalcatalogdir`)
* Ensure that after installation of your application's RPM/DEB "`journalctl --update-catalog`" is executed, in order to update the binary catalog index. (if you package your software with RPM use the `%journal_catalog_update` macro to achieve that.)
-
sudo systemctl stop my-php-fpm-pool.socket my-php-fpm-pool.service
sudo systemctl start my-php-fpm-pool.socket
```
-
* ideally after booting with `systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on`
* The output of a systemd dump: `systemd-analyze dump > systemd-dump.txt`
* The output of `/usr/lib/systemd/systemd --test --system --log-level=debug > systemd-test.txt 2>&1`
-
**Q: My systemd system always comes up with `/tmp` as a tiny `tmpfs`. How do I get rid of this?**
A: That's also a long story, please have a look on [API File Systems](../API_FILE_SYSTEMS)
-
Note that this all only applies to services. By default, user applications run in the root cgroup of the "cpu" hierarchy, which avoids these problems for normal user applications.
In the long run we hope that the kernel is fixed to not require an RT budget to be assigned for any cgroup created before a process can acquire RT (i.e. a process' RT budget should be derived from the nearest ancestor cgroup which has a budget assigned, rather than unconditionally its own uninitialized budget.) Ideally, we'd also like to create a per-user cgroup by default, so that users with many processes get roughly the same amount of CPU as users with very few.
-
In this new definition of /usr, the directory can be mounted read-only by default, while the rootfs may be either read-write or read-only (for stateless systems) and contains only the empty mount point directories, compat-symlinks to /usr and the host-specific data like /etc, /root, /srv. In comparison to today's setups, the rootfs will be very small. The host-specific data will be properly separated from the installed operating system. The new /usr could also easily be shared read-only across several systems. Such a setup would be more efficient, can provide additional security, is more flexible to use, provides saner options for custom setups, and is much simpler to setup and maintain.
For more information on this please continue to [The Case for the /usr Merge](../THE_CASE_FOR_THE_USR_MERGE).
-
```
for a boot target foobar.target. Note that this is mostly a debugging tool that actually does a lot more than just calculate the initial transaction, so don't build scripts based on this.
-
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
-of a user's identity should be stored in the [Blob Directories](USER_RECORD_BLOB_DIRS.md).
+of a user's identity should be stored in the [Blob Directories](USER_RECORD_BLOB_DIRS).
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
see above) with a user record without one set, even if the `userName` field matches.
`blobDirectory` → The absolute path to a world-readable copy of the user's blob
-directory. See [Blob Directories](USER_RECORD_BLOB_DIRS.md) for more details.
+directory. See [Blob Directories](USER_RECORD_BLOB_DIRS) for more details.
`blobManifest` → An object, which maps valid blob directory filenames (see
-[Blob Directories](USER_RECORD_BLOB_DIRS.md) for requirements) to SHA256 hashes
+[Blob Directories](USER_RECORD_BLOB_DIRS) for requirements) to SHA256 hashes
formatted as hex strings. This exists for the purpose of including the contents
of the blob directory in the record's signature. Managers that support blob
directories and utilize signed user records (like `systemd-homed`) should use
# User Record Blob Directories
The blob directories are for storing binary or unstructured data that would
-otherwise be stored in [JSON User Records](USER_RECORD.md). For instance,
+otherwise be stored in [JSON User Records](USER_RECORD). For instance,
this includes image files such as the user's avatar picture. This data,
like most of the user record, will be made publicly available to the
system.
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
-
[
+ {
+ "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"
- }
-]
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 %}
-<!-- external pages -->
-{% assign external_pages = site.data.extra_pages | group_by:"category" %}
+{% 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" %}
-{% for category in external_pages %}
-## {{ category.name }}
-{% assign sorted = category.items | sort:"title" %}{% for page in sorted %}
+{% for pair in merged %}
+ {% if pair.name != "" %}
+## {{ pair.name }}
+{% assign sorted = pair.items | sort:"title" %}{% for page in sorted %}
* [{{ page.title }}]({{ page.url | relative_url }}){% endfor %}
+ {% endif %}
{% endfor %}
## See also
'LICENSE.LGPL2.1',
'NEWS',
'README',
- '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',
+ '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',
install_dir : docdir)
install_subdir('LICENSES',
export PAGER=
# Create a couple of user/group records to test io.systemd.DropIn
-# See docs/_groups/USER_RECORD.md and docs/_groups/GROUP_RECORD.md
+# See docs/USER_RECORD.md and docs/GROUP_RECORD.md
mkdir -p /run/userdb/
cat >"/run/userdb/dropingroup.group" <<\EOF
{