SymbX/systemd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: fix stale links

Browse Source 
(cherry picked from commit 26bde2b760ade0f73d3fbe90d12a492c1a5348ba)
This commit is contained in:
cksrb63
2026-10-16 11:36:33 +01:00
committed by Luca Boccassi
parent db049fc898
commit 5f73eab263
3 changed files with 3 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/CONTROL_GROUP_INTERFACE.md
+1 -1
View File
@@ -26,7 +26,7 @@ That means explicitly, that:
1. The root control group may only be written to by systemd (PID 1). Services that create and manipulate control groups in the top level cgroup are in direct conflict with the kernel's requirement that each control group should have a single-writer only.
2. Services must set Delegate=yes for the units they intend to manage subcgroups of. If they create and manipulate cgroups outside of units that have Delegate=yes set, they violate the access contract for control groups.
For a more high-level background story, please have a look at this [Linux Foundation News Story](https://www.linuxfoundation.jp/blog/2013/08/all-about-the-linux-kernel-cgroups-redesign/).
For a more high-level background story, please have a look at this [Linux.com News Story](https://www.linux.com/news/all-about-linux-kernel-cgroups-redesign/).
### Why this all again?
docs/FACTORY_RESET.md
+1 -2
View File
@@ -41,8 +41,7 @@ Specifically, the following concepts are available:
invalidating all prior keys associated with the security chip and generating
a new seed key.
* The
[`systemd-factory-reset-reboot.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-factory-reset-reboot.service.html)
* The `systemd-factory-reset-reboot.service`
unit automatically reboots the system as part of `factory-reset.target`. It
is ordered after `systemd-tpm2-clear.service` and
`systemd-factory-reset-request.service` in order to initiate the reboot that
docs/OPTIMIZATIONS.md
+1 -1
View File
@@ -9,7 +9,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
_So you are working on a Linux distribution or appliance and need very fast boot-ups?_
systemd can already offer boot times of < 1s for the Core OS (userspace only, i.e. only the bits controlled by systemd) and < 2s for a complete up-to-date desktop environments on simpler (but modern, i.e. SSDs) laptops if configured properly (examples: [http://git.fenrus.org/tmp/bootchart-20120512-1036.svg](http://git.fenrus.org/tmp/bootchart-20120512-1036.svg)).
systemd can already offer boot times of < 1s for the Core OS (userspace only, i.e. only the bits controlled by systemd) and < 2s for a complete up-to-date desktop environments on simpler (but modern, i.e. SSDs) laptops if configured properly.
In this page we want to suggest a couple of ideas how to achieve that, and if the resulting boot times do not suffice where we believe room for improvements are that we'd like to see implemented sooner or later.