Compare commits
No commits in common. "992045686b5cac4f0b878b29f4765d1c8d227a0c" and "4f187dc7c1d4808b3878a1231016b7d4e7cc660f" have entirely different histories.
992045686b
...
4f187dc7c1
@ -20,7 +20,8 @@
|
||||
(nxml-mode . ((nxml-child-indent . 2)
|
||||
(fill-column . 109)))
|
||||
(meson-mode . ((meson-indent-basic . 8)))
|
||||
(sh-mode . ((sh-indentation . 4)))
|
||||
(sh-mode . ((sh-basic-offset . 4)
|
||||
(sh-indentation . 4)))
|
||||
(awk-mode . ((c-basic-offset . 8)))
|
||||
(nil . ((indent-tabs-mode . nil)
|
||||
(tab-width . 8)
|
||||
|
||||
2
.github/ISSUE_TEMPLATE/bug_report.yml
vendored
@ -18,8 +18,6 @@ body:
|
||||
If a distro build is used, please just paste the package version, e.g. `systemd-257.3-7.fc42.x86_64`.
|
||||
See https://github.com/systemd/systemd-stable/tags for the list of most recent releases.
|
||||
For older version please use distribution trackers (see https://systemd.io/CONTRIBUTING#filing-issues).
|
||||
A repository with packages built from latest main for the major distributions and architectures is available from our
|
||||
[OBS project for testing purposes.](https://software.opensuse.org//download.html?project=system%3Asystemd&package=systemd)
|
||||
placeholder: '257.x'
|
||||
validations:
|
||||
required: true
|
||||
|
||||
4
.github/workflows/build-test.yml
vendored
@ -51,9 +51,9 @@ jobs:
|
||||
env: ${{ matrix.env }}
|
||||
steps:
|
||||
- name: Repository checkout
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
- name: Setup python
|
||||
uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405
|
||||
uses: actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065
|
||||
with:
|
||||
python-version: ${{ matrix.python-version }}
|
||||
- name: Build check
|
||||
|
||||
4
.github/workflows/cifuzz.yml
vendored
@ -60,14 +60,14 @@ jobs:
|
||||
sanitizer: ${{ matrix.sanitizer }}
|
||||
output-sarif: true
|
||||
- name: Upload Crash
|
||||
uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f
|
||||
uses: actions/upload-artifact@5d5d22a31266ced268874388b861e4b58bb5c2f3
|
||||
if: failure() && steps.build.outcome == 'success'
|
||||
with:
|
||||
name: ${{ matrix.sanitizer }}-${{ matrix.architecture }}-artifacts
|
||||
path: ./out/artifacts
|
||||
- name: Upload Sarif
|
||||
if: always() && steps.build.outcome == 'success'
|
||||
uses: github/codeql-action/upload-sarif@b20883b0cd1f46c72ae0ba6d1090936928f9fa30
|
||||
uses: github/codeql-action/upload-sarif@51f77329afa6477de8c49fc9c7046c15b9a4e79d
|
||||
with:
|
||||
# Path to SARIF file relative to the root of the repository
|
||||
sarif_file: cifuzz-sarif/results.sarif
|
||||
|
||||
8
.github/workflows/codeql.yml
vendored
@ -42,10 +42,10 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
|
||||
- name: Initialize CodeQL
|
||||
uses: github/codeql-action/init@b20883b0cd1f46c72ae0ba6d1090936928f9fa30
|
||||
uses: github/codeql-action/init@51f77329afa6477de8c49fc9c7046c15b9a4e79d
|
||||
with:
|
||||
languages: ${{ matrix.language }}
|
||||
config-file: ./.github/codeql-config.yml
|
||||
@ -60,7 +60,7 @@ jobs:
|
||||
fi
|
||||
|
||||
- name: Autobuild
|
||||
uses: github/codeql-action/autobuild@b20883b0cd1f46c72ae0ba6d1090936928f9fa30
|
||||
uses: github/codeql-action/autobuild@51f77329afa6477de8c49fc9c7046c15b9a4e79d
|
||||
|
||||
- name: Perform CodeQL Analysis
|
||||
uses: github/codeql-action/analyze@b20883b0cd1f46c72ae0ba6d1090936928f9fa30
|
||||
uses: github/codeql-action/analyze@51f77329afa6477de8c49fc9c7046c15b9a4e79d
|
||||
|
||||
6
.github/workflows/coverage.yml
vendored
@ -24,8 +24,8 @@ jobs:
|
||||
if: github.repository == 'systemd/systemd' || github.repository == 'systemd/systemd-stable'
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
- uses: systemd/mkosi@14d2d37a1923c03062f55454b2b61d0c64db6238
|
||||
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
- uses: systemd/mkosi@9e31235211d975bae25622d6205a8396d104335e
|
||||
|
||||
# Freeing up disk space with rm -rf can take multiple minutes. Since we don't need the extra free space
|
||||
# immediately, we remove the files in the background. However, we first move them to a different location
|
||||
@ -128,7 +128,7 @@ jobs:
|
||||
--quiet
|
||||
|
||||
- name: Archive failed test journals
|
||||
uses: actions/upload-artifact@v6
|
||||
uses: actions/upload-artifact@v4
|
||||
if: failure() && (github.repository == 'systemd/systemd' || github.repository == 'systemd/systemd-stable')
|
||||
with:
|
||||
name: ci-coverage-${{ github.run_id }}-${{ github.run_attempt }}-arch-rolling-failed-test-journals
|
||||
|
||||
2
.github/workflows/coverity.yml
vendored
@ -22,7 +22,7 @@ jobs:
|
||||
COVERITY_SCAN_NOTIFICATION_EMAIL: "${{ secrets.COVERITY_SCAN_NOTIFICATION_EMAIL }}"
|
||||
steps:
|
||||
- name: Repository checkout
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
# Reuse the setup phase of the unit test script to avoid code duplication
|
||||
- name: Install build dependencies
|
||||
run: |
|
||||
|
||||
2
.github/workflows/development-freeze.yml
vendored
@ -30,7 +30,7 @@ jobs:
|
||||
name: Pull Request Metadata
|
||||
|
||||
- name: Repository checkout
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
|
||||
@ -23,12 +23,12 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Repository checkout
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Differential ShellCheck
|
||||
uses: redhat-plumbers-in-action/differential-shellcheck@d965e66ec0b3b2f821f75c8eff9b12442d9a7d1e
|
||||
uses: redhat-plumbers-in-action/differential-shellcheck@dd551ce780d8af741f8cd8bab6982667b906b457
|
||||
with:
|
||||
# exclude all `.in` files because they may contain unsupported syntax, and they have to be preprocessed first
|
||||
# TEMPORARY: exclude bash completion files, they would generate too many defects in Code scanning dashboard (600+)
|
||||
|
||||
6
.github/workflows/gather-pr-metadata.yml
vendored
@ -16,14 +16,14 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Repository checkout
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
|
||||
- id: metadata
|
||||
name: Gather Pull Request Metadata
|
||||
uses: redhat-plumbers-in-action/gather-pull-request-metadata@b86d1eaf7038cf88a56b26ba3e504f10e07b0ce5
|
||||
uses: redhat-plumbers-in-action/gather-pull-request-metadata@5da2967931dd7c4b9ccd22f49b045e2c1f05165b
|
||||
|
||||
- name: Upload Pull Request Metadata artifact
|
||||
uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f
|
||||
uses: actions/upload-artifact@5d5d22a31266ced268874388b861e4b58bb5c2f3
|
||||
with:
|
||||
name: Pull Request Metadata
|
||||
path: ${{ steps.metadata.outputs.metadata-file }}
|
||||
|
||||
4
.github/workflows/issue-labeler.yml
vendored
@ -20,7 +20,7 @@ jobs:
|
||||
template: [ bug_report.yml, feature_request.yml ]
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
|
||||
- name: Parse issue form
|
||||
uses: stefanbuck/github-issue-parser@1e5bdee70d4b3e066a33aa0669ab782943825f94
|
||||
@ -29,7 +29,7 @@ jobs:
|
||||
template-path: .github/ISSUE_TEMPLATE/${{ matrix.template }}
|
||||
|
||||
- name: Set labels based on component field
|
||||
uses: redhat-plumbers-in-action/advanced-issue-labeler@b80ae64e3e156e9c111b075bfa04b295d54e8e2e
|
||||
uses: redhat-plumbers-in-action/advanced-issue-labeler@e38e6809c5420d038eed380d49ee9a6ca7c92dbf
|
||||
with:
|
||||
issue-form: ${{ steps.issue-parser.outputs.jsonString }}
|
||||
template: ${{ matrix.template }}
|
||||
|
||||
10
.github/workflows/labeler.yml
vendored
@ -30,11 +30,11 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Repository checkout
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
if: github.event_name == 'pull_request'
|
||||
|
||||
- name: Label PR based on policy in labeler.yml
|
||||
uses: actions/labeler@634933edcd8ababfe52f92936142cc22ac488b1b
|
||||
uses: actions/labeler@8558fd74291d67161a8a78ce36a881fa63b766a9
|
||||
if: startsWith(github.event_name, 'pull_request') && github.base_ref == 'main' && github.event.action != 'closed'
|
||||
with:
|
||||
repo-token: "${{ secrets.GITHUB_TOKEN }}"
|
||||
@ -42,7 +42,7 @@ jobs:
|
||||
sync-labels: false
|
||||
|
||||
- name: Set or remove labels based on systemd development workflow
|
||||
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd
|
||||
uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea
|
||||
if: startsWith(github.event_name, 'pull_request') && github.event.action != 'closed' && !github.event.pull_request.draft
|
||||
with:
|
||||
script: |
|
||||
@ -83,7 +83,7 @@ jobs:
|
||||
}
|
||||
|
||||
- name: Add please-review label on command in issue comment
|
||||
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd
|
||||
uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea
|
||||
if: github.event_name == 'issue_comment' && github.event.issue.pull_request && startsWith(github.event.comment.body, '/please-review')
|
||||
with:
|
||||
script: |
|
||||
@ -95,7 +95,7 @@ jobs:
|
||||
})
|
||||
|
||||
- name: Remove specific labels when PR is closed or merged
|
||||
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd
|
||||
uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea
|
||||
if: startsWith(github.event_name, 'pull_request') && github.event.action == 'closed'
|
||||
with:
|
||||
script: |
|
||||
|
||||
7
.github/workflows/linter.yml
vendored
@ -23,13 +23,13 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Repo checkout
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
with:
|
||||
# We need a full repo clone
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Lint Code Base
|
||||
uses: super-linter/super-linter/slim@12562e48d7059cf666c43a4ecb0d3b5a2b31bd9e
|
||||
uses: super-linter/super-linter/slim@502f4fe48a81a392756e173e39a861f8c8efe056
|
||||
env:
|
||||
DEFAULT_BRANCH: main
|
||||
MULTI_STATUS: false
|
||||
@ -37,9 +37,8 @@ jobs:
|
||||
VALIDATE_GITHUB_ACTIONS: true
|
||||
LINTER_RULES_PATH: .github/linters
|
||||
GITHUB_ACTIONS_CONFIG_FILE: actionlint.yml
|
||||
ENABLE_GITHUB_PULL_REQUEST_SUMMARY_COMMENT: false
|
||||
|
||||
- uses: systemd/mkosi@14d2d37a1923c03062f55454b2b61d0c64db6238
|
||||
- uses: systemd/mkosi@9e31235211d975bae25622d6205a8396d104335e
|
||||
|
||||
- name: Check that tabs are not used in Python code
|
||||
run: sh -c '! git grep -P "\\t" -- src/core/generate-bpf-delegate-configs.py src/boot/generate-hwids-section.py src/ukify/ukify.py test/integration-tests/integration-test-wrapper.py'
|
||||
|
||||
6
.github/workflows/mkosi.yml
vendored
@ -166,8 +166,8 @@ jobs:
|
||||
shim: 0
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
- uses: systemd/mkosi@14d2d37a1923c03062f55454b2b61d0c64db6238
|
||||
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
- uses: systemd/mkosi@9e31235211d975bae25622d6205a8396d104335e
|
||||
|
||||
# Freeing up disk space with rm -rf can take multiple minutes. Since we don't need the extra free space
|
||||
# immediately, we remove the files in the background. However, we first move them to a different location
|
||||
@ -311,7 +311,7 @@ jobs:
|
||||
"${MAX_LINES[@]}"
|
||||
|
||||
- name: Archive failed test journals
|
||||
uses: actions/upload-artifact@v6
|
||||
uses: actions/upload-artifact@v4
|
||||
if: failure() && (github.repository == 'systemd/systemd' || github.repository == 'systemd/systemd-stable')
|
||||
with:
|
||||
name: ci-mkosi-${{ github.run_id }}-${{ github.run_attempt }}-${{ matrix.distro }}-${{ matrix.release }}-${{ matrix.runner }}-failed-test-journals
|
||||
|
||||
5
.github/workflows/requirements.txt
vendored
@ -1,6 +1,5 @@
|
||||
meson==1.10.1 \
|
||||
--hash=sha256:c42296f12db316a4515b9375a5df330f2e751ccdd4f608430d41d7d6210e4317 \
|
||||
--hash=sha256:fe43d1cc2e6de146fbea78f3a062194bcc0e779efc8a0f0d7c35544dfb86731f
|
||||
meson==1.9.1 \
|
||||
--hash=sha256:f824ab770c041a202f532f69e114c971918ed2daff7ea56583d80642564598d0
|
||||
ninja==1.11.1.4 \
|
||||
--hash=sha256:055f386fb550c2c9d6157e45e20a84d29c47968876b9c5794ae2aec46f952306 \
|
||||
--hash=sha256:096487995473320de7f65d622c3f1d16c3ad174797602218ca8c967f51ec38a0 \
|
||||
|
||||
2
.github/workflows/scorecards.yml
vendored
@ -29,7 +29,7 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
|
||||
with:
|
||||
persist-credentials: false
|
||||
|
||||
|
||||
2
.github/workflows/unit-tests-musl.yml
vendored
@ -20,7 +20,7 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Repository checkout
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
|
||||
- name: Install build dependencies
|
||||
uses: jirutka/setup-alpine@v1
|
||||
|
||||
2
.github/workflows/unit-tests.yml
vendored
@ -40,7 +40,7 @@ jobs:
|
||||
runner: ubuntu-24.04-s390x
|
||||
steps:
|
||||
- name: Repository checkout
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
||||
- name: Install build dependencies
|
||||
run: |
|
||||
# Drop XDG_* stuff from /etc/environment, so we don't get the user
|
||||
|
||||
5
.mailmap
@ -36,9 +36,6 @@ Daniel Stekloff <dsteklof@us.ibm.com>
|
||||
Daniel Șerbănescu <dasj19@users.noreply.github.com>
|
||||
Dann Frazier <dann.frazier@canonical.com>
|
||||
Dave Reisner <dreisner@archlinux.org> <d@falconindy.com>
|
||||
David Rheinsberg <david@readahead.eu>
|
||||
David Rheinsberg <dh.herrmann@gmail.com>
|
||||
David Rheinsberg <dh.herrmann@googlemail.com>
|
||||
David Santamaría Rogado <howl.nsp@gmail.com>
|
||||
David Zeuthen <david@fubar.dk>
|
||||
David Zeuthen <david@fubar.dk> <davidz@redhat.com>
|
||||
@ -94,9 +91,7 @@ José Bollo <jose.bollo@iot.bzh> <jobol@nonadev.net>
|
||||
Jun Bo Bi <jambonmcyeah@gmail.com>
|
||||
Justin Capella <justincapella@gmail.com> <b1tninja@users.noreply.github.com>
|
||||
Jérémy Rosen <jeremy.rosen@enst-bretagne.fr>
|
||||
Jörg Behrmann <behrmann@physik.fu-berlin.de>
|
||||
Jürg Billeter <j@bitron.ch>
|
||||
Kai Lüke <kailuke@microsoft.com>
|
||||
Karl Kraus <karl.kraus@tum.de> <laqueray@gmail.com>
|
||||
Kay Sievers <kay@vrfy.org>
|
||||
Kay Sievers <kay@vrfy.org> <kay.sievers@suse.de>
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
rebuild:
|
||||
steps:
|
||||
- trigger_services:
|
||||
project: system:systemd:stable
|
||||
project: system:systemd
|
||||
package: systemd
|
||||
filters:
|
||||
event: push
|
||||
branches:
|
||||
only:
|
||||
- v259-stable
|
||||
- main
|
||||
|
||||
2
NEWS
@ -4624,7 +4624,7 @@ CHANGES WITH 255:
|
||||
* A new component "systemd-storagetm" has been added, which exposes all
|
||||
local block devices as NVMe-TCP devices, fully automatically. It's
|
||||
hooked into a new target unit storage-target-mode.target that is
|
||||
supposed to be booted into via
|
||||
suppsoed to be booted into via
|
||||
rd.systemd.unit=storage-target-mode.target on the kernel command
|
||||
line. This is intended to be used for installers and debugging to
|
||||
quickly get access to the local disk. It's inspired by MacOS "target
|
||||
|
||||
5
README
@ -124,8 +124,7 @@ REQUIREMENTS:
|
||||
CONFIG_SECCOMP
|
||||
CONFIG_SECCOMP_FILTER (required for seccomp support)
|
||||
CONFIG_KCMP (for the kcmp() syscall, used to be under
|
||||
CONFIG_CHECKPOINT_RESTORE before ~5.12;
|
||||
not needed after 6.10)
|
||||
CONFIG_CHECKPOINT_RESTORE before ~5.12)
|
||||
CONFIG_NET_SCHED
|
||||
CONFIG_NET_SCH_FQ_CODEL
|
||||
|
||||
@ -193,7 +192,7 @@ REQUIREMENTS:
|
||||
This is shipped by default, see modprobe.d/systemd.conf.
|
||||
|
||||
Required for systemd-nspawn:
|
||||
CONFIG_DEVPTS_MULTIPLE_INSTANCES (removed and unneeded since 4.7)
|
||||
CONFIG_DEVPTS_MULTIPLE_INSTANCES or Linux kernel >= 4.7
|
||||
|
||||
Required for systemd-oomd:
|
||||
CONFIG_PSI
|
||||
|
||||
@ -55,9 +55,9 @@ systemctl mask dev-hugepages.mount
|
||||
```
|
||||
|
||||
This has the effect that the huge memory page API FS is not mounted by default, starting with the next boot.
|
||||
See [Three Levels of Off](https://0pointer.de/blog/projects/three-levels-of-off.html) for more information on masking.
|
||||
See [Three Levels of Off](http://0pointer.de/blog/projects/three-levels-of-off.html) for more information on masking.
|
||||
|
||||
The systemd service [systemd-remount-fs.service](https://www.freedesktop.org/software/systemd/man/latest/systemd-remount-fs.service.html)
|
||||
The systemd service [systemd-remount-fs.service](http://www.freedesktop.org/software/systemd/man/systemd-remount-fs.service.html)
|
||||
is responsible for applying mount parameters from `/etc/fstab` to the actual mounts.
|
||||
|
||||
## Why are you telling me all this? I just want to get rid of the tmpfs backed /tmp!
|
||||
|
||||
@ -42,7 +42,7 @@ Thus code that is used by "higher-level" components (e.g. our binaries which are
|
||||
would go to a subdirectory specific to that component if it is only used there.
|
||||
If the code is to be shared between components, it'd go to `src/shared/`.
|
||||
Shared code that is used by multiple components that do not link to `libsystemd-shared-<nnn>.so` may live either in `src/libsystemd/`, `src/basic/`, or `src/fundamental/`.
|
||||
Any code that is used only for EFI goes under `src/boot/efi/`, and in `src/fundamental/` if it is shared with non-EFI components.
|
||||
Any code that is used only for EFI goes under `src/boot/efi/`, and `src/fundamental/` if is shared with non-EFI components.
|
||||
|
||||
To summarize:
|
||||
|
||||
@ -121,7 +121,7 @@ Names of meson tests include the input file name and output looks awkward if the
|
||||
Fuzzers are invoked primarily in three ways:
|
||||
firstly, each fuzzer is compiled as a normal executable and executed for each of the input samples under `test/fuzz/` as part of the test suite.
|
||||
Secondly, fuzzers may be instrumented 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).
|
||||
Thirdly, fuzzers are executed through fuzzing engines that tryto find new "interesting" inputs through coverage feedback and massive 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`.
|
||||
|
||||
## Integration Tests
|
||||
|
||||
@ -21,12 +21,12 @@ other boot loaders or take actions outside of the boot loader.
|
||||
Here's a brief overview of the complete set of components:
|
||||
|
||||
* The
|
||||
[`kernel-install(8)`](https://www.freedesktop.org/software/systemd/man/latest/kernel-install.html)
|
||||
[`kernel-install(8)`](https://www.freedesktop.org/software/systemd/man/kernel-install.html)
|
||||
script can optionally create boot loader entries that carry an initial boot
|
||||
counter (the initial counter is configurable in `/etc/kernel/tries`).
|
||||
|
||||
* The
|
||||
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html)
|
||||
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)
|
||||
boot loader optionally maintains a per-boot-loader-entry counter described by
|
||||
the [UAPI.1 Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting)
|
||||
that is decreased by one on each attempt to boot the entry, prioritizing
|
||||
@ -34,27 +34,27 @@ Here's a brief overview of the complete set of components:
|
||||
counter of zero when choosing the entry to boot.
|
||||
|
||||
* The `boot-complete.target` target unit (see
|
||||
[`systemd.special(7)`](https://www.freedesktop.org/software/systemd/man/latest/systemd.special.html))
|
||||
[`systemd.special(7)`](https://www.freedesktop.org/software/systemd/man/systemd.special.html))
|
||||
serves as a generic extension point both for units that are necessary to
|
||||
consider a boot successful (e.g. `systemd-boot-check-no-failures.service`
|
||||
described below), and units that want to act only if the boot is
|
||||
successful (e.g. `systemd-bless-boot.service` described below).
|
||||
|
||||
* The
|
||||
[`systemd-boot-check-no-failures.service(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-boot-check-no-failures.service.html)
|
||||
[`systemd-boot-check-no-failures.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-boot-check-no-failures.service.html)
|
||||
service is a simple service health check tool. When enabled it becomes an
|
||||
indirect dependency of `systemd-bless-boot.service` (by means of
|
||||
`boot-complete.target`, see below), ensuring that the boot will not be
|
||||
considered successful if there are any failed services.
|
||||
|
||||
* The
|
||||
[`systemd-bless-boot.service(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-bless-boot.service.html)
|
||||
[`systemd-bless-boot.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-bless-boot.service.html)
|
||||
service automatically marks a boot loader entry, for which boot counting as
|
||||
mentioned above is enabled, as "good" when a boot has been determined to be
|
||||
successful, thus turning off boot counting for it.
|
||||
|
||||
* The
|
||||
[`systemd-bless-boot-generator(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-bless-boot-generator.html)
|
||||
[`systemd-bless-boot-generator(8)`](https://www.freedesktop.org/software/systemd/man/systemd-bless-boot-generator.html)
|
||||
generator automatically pulls in `systemd-bless-boot.service` when use of
|
||||
`systemd-boot` with boot counting enabled is detected.
|
||||
|
||||
@ -189,7 +189,7 @@ are a couple of recommendations.
|
||||
|
||||
Depending on the setup, it may be most convenient to pull in such units
|
||||
through normal enablement symlinks, or during early boot using a
|
||||
[`generator`](https://www.freedesktop.org/software/systemd/man/latest/systemd.generator.html),
|
||||
[`generator`](https://www.freedesktop.org/software/systemd/man/systemd.generator.html),
|
||||
or even during later boot. In the last case, care must be taken to ensure
|
||||
that the start job is created before `boot-complete.target` has been
|
||||
reached.
|
||||
@ -199,9 +199,9 @@ are a couple of recommendations.
|
||||
in.
|
||||
|
||||
Such unit would be typically wanted (or required) by one of the
|
||||
[`bootup`](https://www.freedesktop.org/software/systemd/man/latest/bootup.html) targets,
|
||||
[`bootup`](https://www.freedesktop.org/software/systemd/man/bootup.html) targets,
|
||||
for example, `multi-user.target`. To avoid potential loops due to conflicting
|
||||
[default dependencies](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#Default%20Dependencies)
|
||||
[default dependencies](https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Default%20Dependencies)
|
||||
ordering, it is recommended to also add an explicit dependency (e.g.
|
||||
`After=multi-user.target`) to the unit. This overrides the implicit ordering
|
||||
and allows `boot-complete.target` to start after the given bootup target.
|
||||
|
||||
@ -88,7 +88,7 @@ during normal operation, i.e. while file systems on it are mounted for
|
||||
application use.
|
||||
|
||||
The [`udevadm
|
||||
lock`](https://www.freedesktop.org/software/systemd/man/latest/udevadm.html) command
|
||||
lock`](https://www.freedesktop.org/software/systemd/man/udevadm.html) command
|
||||
is provided to lock block devices following this scheme from the command line,
|
||||
for the use in scripts and similar. (Note though that it's typically preferable
|
||||
to use native support for block device locking in tools where that's
|
||||
|
||||
@ -107,14 +107,14 @@ Variables will be listed below using the Linux efivarfs naming,
|
||||
* `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 << 7` → The boot loader supports loading of drop-in drivers from the `/EFI/systemd/drivers/` directory on the ESP,
|
||||
see [`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html).
|
||||
see [`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html).
|
||||
* `1 << 8` → The boot loader supports the `sort-key` field defined by the
|
||||
[Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification).
|
||||
* `1 << 9` → The boot loader supports the `@saved` pseudo-entry
|
||||
* `1 << 10` → The boot loader supports the `devicetree` field defined by the
|
||||
[Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification).
|
||||
* `1 << 11` → The boot loader support automatic enrollment of SecureBoot keys,
|
||||
see [`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html).
|
||||
see [`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html).
|
||||
* `1 << 12` → The boot loader will set EFI variable `ShimRetainProtocol-605dab50-e046-4300-abb6-3dd810dd8b23`
|
||||
for `shim` to make its protocol available to the booted binary.
|
||||
* `1 << 13` → The boot loader honours `menu-disabled` option when set.
|
||||
@ -166,7 +166,7 @@ variables.
|
||||
## Boot Loader Entry Identifiers
|
||||
|
||||
While boot loader entries may be named relatively freely,
|
||||
it's highly recommended to follow these rules when picking identifiers for the entries,
|
||||
it's highly recommended to follow the following rules when picking identifiers for the entries,
|
||||
so that programs (and users) can derive basic context and meaning from the identifiers
|
||||
as passed in `LoaderEntries`, `LoaderEntryDefault`, `LoaderEntryOneShot`, `LoaderEntrySelected`,
|
||||
and possibly show nicely localized names for them in UIs.
|
||||
@ -206,6 +206,6 @@ and possibly show nicely localized names for them in UIs.
|
||||
|
||||
[UAPI.1 Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification)<br>
|
||||
[UAPI.2 Discoverable Partitions Specification](https://uapi-group.org/specifications/specs/discoverable_partitions_specification)<br>
|
||||
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html)<br>
|
||||
[`bootctl(1)`](https://www.freedesktop.org/software/systemd/man/latest/bootctl.html)<br>
|
||||
[`systemd-gpt-auto-generator(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html)
|
||||
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br>
|
||||
[`bootctl(1)`](https://www.freedesktop.org/software/systemd/man/bootctl.html)<br>
|
||||
[`systemd-gpt-auto-generator(8)`](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html)
|
||||
|
||||
@ -26,7 +26,7 @@ Typically the same OS image shall be deployable in multiple instances, and each
|
||||
instance should automatically acquire its own identifying credentials on first
|
||||
boot. For that it's essential to:
|
||||
|
||||
1. Remove the [`/etc/machine-id`](https://www.freedesktop.org/software/systemd/man/latest/machine-id.html)
|
||||
1. Remove the [`/etc/machine-id`](https://www.freedesktop.org/software/systemd/man/machine-id.html)
|
||||
file or write the string `uninitialized\n` into it.
|
||||
This file is supposed to carry a 128-bit identifier unique to the system.
|
||||
Only when it is reset it will be auto-generated on first boot and thus be truly unique.
|
||||
@ -36,27 +36,27 @@ boot. For that it's essential to:
|
||||
for example, IPv6 addresses or transient MAC addresses.
|
||||
|
||||
2. Remove the `/var/lib/systemd/random-seed` file(see
|
||||
[`systemd-random-seed(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-random-seed.service.html)),
|
||||
[`systemd-random-seed(8)`](https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html)),
|
||||
which is used to seed the kernel's random pool on boot.
|
||||
If this file is shipped pre-initialized, every instance will seed its random pool with the
|
||||
same random data that is included in the image, and thus possibly generate
|
||||
random data that is more similar to other instances booted off the same image than advisable.
|
||||
|
||||
3. Remove the `/loader/random-seed` file (see
|
||||
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html))
|
||||
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html))
|
||||
from the UEFI System Partition (ESP), in case the `systemd-boot` boot loader is used in the image.
|
||||
|
||||
4. It might also make sense to remove
|
||||
[`/etc/hostname`](https://www.freedesktop.org/software/systemd/man/latest/hostname.html)
|
||||
[`/etc/hostname`](https://www.freedesktop.org/software/systemd/man/hostname.html)
|
||||
and
|
||||
[`/etc/machine-info`](https://www.freedesktop.org/software/systemd/man/latest/machine-info.html)
|
||||
[`/etc/machine-info`](https://www.freedesktop.org/software/systemd/man/machine-info.html)
|
||||
which carry additional identifying information about the OS image.
|
||||
|
||||
5. Remove `/var/lib/systemd/credential.secret` which is used for protecting
|
||||
service credentials, see
|
||||
[`systemd.exec(5)`](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#Credentials)
|
||||
[`systemd.exec(5)`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Credentials)
|
||||
and
|
||||
[`systemd-creds(1)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-creds.html)
|
||||
[`systemd-creds(1)`](https://www.freedesktop.org/software/systemd/man/systemd-creds.html)
|
||||
for details. Note that by removing this file access to previously encrypted
|
||||
credentials from this image is lost. The file is automatically generated if
|
||||
a new credential is encrypted and the file does not exist yet.
|
||||
@ -64,7 +64,7 @@ boot. For that it's essential to:
|
||||
## Boot Menu Entry Identifiers
|
||||
|
||||
The
|
||||
[`kernel-install(8)`](https://www.freedesktop.org/software/systemd/man/latest/kernel-install.html)
|
||||
[`kernel-install(8)`](https://www.freedesktop.org/software/systemd/man/kernel-install.html)
|
||||
logic used to generate
|
||||
[UAPI.1 Boot Loader Specification Type #1](https://uapi-group.org/specifications/specs/boot_loader_specification/#type-1-boot-loader-specification-entries)
|
||||
entries by default uses the machine ID as stored in `/etc/machine-id` for
|
||||
@ -84,7 +84,7 @@ If not configured explicitly it defaults to the machineID.
|
||||
The file `/etc/kernel/entry-token` may be used to configure this string explicitly.
|
||||
Thus, golden image builders should write a suitable identifier into
|
||||
this file, for example, the `IMAGE_ID=` or `ID=` field from
|
||||
[`/etc/os-release`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html)
|
||||
[`/etc/os-release`](https://www.freedesktop.org/software/systemd/man/os-release.html)
|
||||
(also see below).
|
||||
It is recommended to do this before the `kernel-install` functionality is invoked (i.e. before the package manager is used to install
|
||||
packages into the OS tree being prepared), so that the selected string is
|
||||
@ -111,17 +111,17 @@ Specifically, the following mechanisms are in place:
|
||||
(see above).
|
||||
|
||||
3. The
|
||||
[`nss-systemd(8)`](https://www.freedesktop.org/software/systemd/man/latest/nss-systemd.html)
|
||||
[`nss-systemd(8)`](https://www.freedesktop.org/software/systemd/man/nss-systemd.html)
|
||||
glibc NSS module ensures the `root` and `nobody` users and groups remain
|
||||
resolvable, even without `/etc/passwd` and `/etc/group` around.
|
||||
|
||||
4. The
|
||||
[`systemd-sysusers(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-sysusers.service.html)
|
||||
[`systemd-sysusers(8)`](https://www.freedesktop.org/software/systemd/man/systemd-sysusers.service.html)
|
||||
component will automatically populate `/etc/passwd` and `/etc/group` on
|
||||
first boot with further necessary system users.
|
||||
|
||||
5. The
|
||||
[`systemd-tmpfiles(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-tmpfiles-setup.service.html)
|
||||
[`systemd-tmpfiles(8)`](https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles-setup.service.html)
|
||||
component ensures that various files and directories below `/etc/`, `/var/`
|
||||
and other places are created automatically at boot if missing. Unlike the
|
||||
directories/symlinks created by the `switch-root` logic above this logic is
|
||||
@ -131,7 +131,7 @@ Specifically, the following mechanisms are in place:
|
||||
unconditionally accessible through `/etc/os-release`.
|
||||
|
||||
6. The
|
||||
[`nss-myhostname(8)`](https://www.freedesktop.org/software/systemd/man/latest/nss-myhostname.html)
|
||||
[`nss-myhostname(8)`](https://www.freedesktop.org/software/systemd/man/nss-myhostname.html)
|
||||
glibc NSS module will ensure the local host name as well as `localhost`
|
||||
remains resolvable, even without `/etc/hosts` around.
|
||||
|
||||
@ -193,7 +193,7 @@ it, then format it.
|
||||
`systemd` provides multiple tools to implement the above logic:
|
||||
|
||||
1. The
|
||||
[`systemd-repart(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-repart.service.html)
|
||||
[`systemd-repart(8)`](https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html)
|
||||
component may manipulate GPT partition tables automatically on boot, growing
|
||||
partitions or adding in partitions taking the backing storage size into account.
|
||||
It can also encrypt partitions automatically it creates (even bind
|
||||
@ -202,7 +202,7 @@ it, then format it.
|
||||
incompletely set up partitions around.
|
||||
|
||||
2. The
|
||||
[`systemd-growfs@(8).service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-growfs.html)
|
||||
[`systemd-growfs@(8).service`](https://www.freedesktop.org/software/systemd/man/systemd-growfs.html)
|
||||
tool can automatically grow a file system to the partition it is contained
|
||||
in. The `x-systemd.growfs` mount option in `/etc/fstab` is sufficient to
|
||||
enable this logic for specific mounts. Alternatively appropriately set up
|
||||
@ -221,7 +221,7 @@ While a lot of work has gone into ensuring `systemd` systems can safely boot
|
||||
with unpopulated `/etc/` trees, it sometimes is desirable to set a couple of
|
||||
basic settings *after* `dd`-ing the image to disk, but *before* first boot.
|
||||
For this the tool
|
||||
[`systemd-firstboot(1)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-firstboot.html)
|
||||
[`systemd-firstboot(1)`](https://www.freedesktop.org/software/systemd/man/systemd-firstboot.html)
|
||||
can be useful, with its `--image=` switch. It may be used to set very basic
|
||||
settings, such as the root password or hostname on an OS disk image or
|
||||
installed block device.
|
||||
@ -232,7 +232,7 @@ For various purposes it's useful to be able to distinguish the first boot-up of
|
||||
the system from later boot-ups (for example, to set up TPM hardware specifically, or register a system somewhere).
|
||||
`systemd` provides mechanisms to implement that.
|
||||
Specifically, the `ConditionFirstBoot=` and `AssertFirstBoot=` settings may be used to conditionalize units to only run on first boot.
|
||||
See [`systemd.unit(5)`](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#ConditionFirstBoot=)
|
||||
See [`systemd.unit(5)`](https://www.freedesktop.org/software/systemd/man/systemd.unit.html#ConditionFirstBoot=)
|
||||
for details.
|
||||
|
||||
A special target unit `first-boot-complete.target` may be used as milestone to
|
||||
@ -247,14 +247,14 @@ Whether a system will come up in first boot state or not is derived from the
|
||||
initialization status of `/etc/machine-id`:
|
||||
if the file already carries a valid ID the system is already past the first boot.
|
||||
If it is not initialized yet it is still considered in the first boot state.
|
||||
For details see [`machine-id(5)`](https://www.freedesktop.org/software/systemd/man/latest/machine-id.html).
|
||||
For details see [`machine-id(5)`](https://www.freedesktop.org/software/systemd/man/machine-id.html).
|
||||
|
||||
## Image Metadata
|
||||
|
||||
Typically, when operating with golden disk images it is useful to be able to
|
||||
identify them and their version.
|
||||
For this the two fields `IMAGE_ID=` and `IMAGE_VERSION=` have been defined in
|
||||
[`os-release(5)`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html).
|
||||
[`os-release(5)`](https://www.freedesktop.org/software/systemd/man/os-release.html).
|
||||
These fields may be accessed from unit files and similar via the `%M` and `%A` specifiers.
|
||||
|
||||
Depending on how the images are put together it might make sense to leave the
|
||||
@ -265,12 +265,12 @@ fields.
|
||||
|
||||
## Links
|
||||
|
||||
[`machine-id(5)`](https://www.freedesktop.org/software/systemd/man/latest/machine-id.html)<br>
|
||||
[`systemd-random-seed(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-random-seed.service.html)<br>
|
||||
[`os-release(5)`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html)<br>
|
||||
[`machine-id(5)`](https://www.freedesktop.org/software/systemd/man/machine-id.html)<br>
|
||||
[`systemd-random-seed(8)`](https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html)<br>
|
||||
[`os-release(5)`](https://www.freedesktop.org/software/systemd/man/os-release.html)<br>
|
||||
[UAPI.1 Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification)<br>
|
||||
[UAPI.2 Discoverable Partitions Specification](https://uapi-group.org/specifications/specs/discoverable_partitions_specification)<br>
|
||||
[`mkosi`](https://github.com/systemd/mkosi)<br>
|
||||
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html)<br>
|
||||
[`systemd-repart(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-repart.service.html)<br>
|
||||
[`systemd-growfs@(8).service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-growfs.html)<br>
|
||||
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br>
|
||||
[`systemd-repart(8)`](https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html)<br>
|
||||
[`systemd-growfs@(8).service`](https://www.freedesktop.org/software/systemd/man/systemd-growfs.html)<br>
|
||||
|
||||
@ -21,7 +21,7 @@ The message catalog has a number of purposes:
|
||||
## Format
|
||||
|
||||
Message catalog source files are simple text files that follow an RFC822 inspired format.
|
||||
To get an understanding of the format [here's an example file](https://github.com/systemd/systemd/blob/main/catalog/systemd.catalog.in), which includes entries for many important messages systemd itself generates.
|
||||
To get an understanding of the format [here's an example file](http://cgit.freedesktop.org/systemd/systemd/plain/catalog/systemd.catalog), which includes entries for many important messages systemd itself generates.
|
||||
On installation of a package that includes message catalogs all installed message catalog source files get compiled into a binary index, which is then used to look up catalog data.
|
||||
|
||||
journalctl's `-x` command line parameter may be used to augment on display journal log messages with message catalog data when browsing.
|
||||
@ -36,8 +36,9 @@ Here's an example how a single catalog entry looks like in the text source forma
|
||||
-- fc2e22bc6ee647b6b90729ab34a250b1
|
||||
Subject: Process @COREDUMP_PID@ (@COREDUMP_COMM@) dumped core
|
||||
Defined-By: systemd
|
||||
Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
|
||||
Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
|
||||
Documentation: man:core(5)
|
||||
Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/@MESSAGE_ID@
|
||||
|
||||
Process @COREDUMP_PID@ (@COREDUMP_COMM@) crashed and dumped core.
|
||||
|
||||
@ -79,16 +80,16 @@ The text format of the .catalog files is as follows:
|
||||
* When a catalog entry is printed on screen for a specific log entry simple variable replacements are applied.
|
||||
Journal field names enclosed in @ will be replaced by their values, if such a field is available in an entry.
|
||||
If such a field is not defined in an entry the enclosing @ will be dropped but the variable name is kept.
|
||||
See [systemd's own message catalog](https://github.com/systemd/systemd/blob/main/catalog/systemd.catalog.in) for a complete example for a catalog file.
|
||||
See [systemd's own message catalog](http://cgit.freedesktop.org/systemd/systemd/plain/catalog/systemd.catalog) for a complete example for a catalog file.
|
||||
|
||||
## Adding Message Catalog Support to Your Program
|
||||
|
||||
Note that the message catalog is only available for messages generated with the MESSAGE\_ID= journal meta data field, as this is need to find the right entry for a message.
|
||||
For more information on the MESSAGE\_ID= journal entry field see [systemd.journal-fields(7)](https://www.freedesktop.org/software/systemd/man/latest/systemd.journal-fields.html).
|
||||
For more information on the MESSAGE\_ID= journal entry field see [systemd.journal-fields(7)](http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html).
|
||||
|
||||
To add message catalog entries for log messages your application generates, please follow these guidelines:
|
||||
To add message catalog entries for log messages your application generates, please follow the following guidelines:
|
||||
|
||||
* Use the [native Journal logging APIs](https://0pointer.de/blog/projects/journal-submit.html)
|
||||
* 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/`
|
||||
|
||||
@ -27,7 +27,7 @@ available functionality:
|
||||
using `systemd-nspawn` and `qemu`. Requires root.
|
||||
|
||||
3. Use `./coccinelle/run-coccinelle.sh` to run all
|
||||
[Coccinelle](https://coccinelle.gitlabpages.inria.fr/website/) semantic patch scripts we ship. The
|
||||
[Coccinelle](http://coccinelle.lip6.fr/) semantic patch scripts we ship. The
|
||||
output will show false positives, hence take it with a pinch of salt.
|
||||
|
||||
4. Use `./tools/find-double-newline.sh recdiff` to find double newlines. Use
|
||||
|
||||
@ -247,24 +247,6 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
const char *input);
|
||||
```
|
||||
|
||||
- When passing `NULL` or another value meaning "unset" to a function, use a comment
|
||||
to indicate the argument name to make it more clear where we're passing an "unset"
|
||||
value.
|
||||
|
||||
Bad:
|
||||
|
||||
```c
|
||||
myfunction(NULL, NULL, NULL);
|
||||
```
|
||||
|
||||
Good:
|
||||
|
||||
```c
|
||||
myfunction(/* a= */ NULL, /* b= */ NULL, /* c= */ NULL);
|
||||
```
|
||||
|
||||
This guidance should be applied tree-wide, including in test files.
|
||||
|
||||
- Please do not introduce new circular dependencies between header files.
|
||||
Effectively this means that if a.h includes b.h, then b.h cannot include a.h,
|
||||
directly or transitively via another header. Circular header dependencies can
|
||||
|
||||
@ -188,7 +188,7 @@ manager, please consider supporting the following interfaces.
|
||||
activation work. The protocol to hand sockets from systemd to services is
|
||||
hence the same as from the container manager to the container systemd. For
|
||||
further details see the explanations of
|
||||
[sd_listen_fds(1)](https://www.freedesktop.org/software/systemd/man/latest/sd_listen_fds.html)
|
||||
[sd_listen_fds(1)](https://0pointer.de/public/systemd-man/sd_listen_fds.html)
|
||||
and the [blog story for service
|
||||
developers](https://0pointer.de/blog/projects/socket-activation.html).
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
|
||||
# Contributing
|
||||
|
||||
We welcome contributions from everyone. However, please follow these guidelines when posting a GitHub Pull Request or filing a GitHub Issue on the systemd project:
|
||||
We welcome contributions from everyone. However, please follow the following guidelines when posting a GitHub Pull Request or filing a GitHub Issue on the systemd project:
|
||||
|
||||
## Filing Issues
|
||||
|
||||
|
||||
@ -58,9 +58,9 @@ On systemd systems use the systemd APIs as described below. At this time we are
|
||||
|
||||
Systemd provides three unit types that are useful for the purpose of resource control:
|
||||
|
||||
- [_Services_](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) encapsulate a number of processes that are started and stopped by systemd based on configuration. Services are named in the style of `quux.service`.
|
||||
- [_Scopes_](https://www.freedesktop.org/software/systemd/man/latest/systemd.scope.html) encapsulate a number of processes that are started and stopped by arbitrary processes via fork(), and then registered at runtime with PID1. Scopes are named in the style of `wuff.scope`.
|
||||
- [_Slices_](https://www.freedesktop.org/software/systemd/man/latest/systemd.slice.html) may be used to group a number of services and scopes together in a hierarchial tree. Slices do not contain processes themselves, but the services and scopes contained in them do. Slices are named in the style of `foobar-waldo.slice`, where the path to the location of the slice in the tree is encoded in the name with "-" as separator for the path components (`foobar-waldo.slice` is hence a subslice of `foobar.slice`). There's one special slices defined, `-.slice`, which is the root slice of all slices (`foobar.slice` is hence subslice of `-.slice`). This is similar how in regular file paths, "/" denotes the root directory.
|
||||
- [_Services_](http://www.freedesktop.org/software/systemd/man/systemd.service.html) encapsulate a number of processes that are started and stopped by systemd based on configuration. Services are named in the style of `quux.service`.
|
||||
- [_Scopes_](http://www.freedesktop.org/software/systemd/man/systemd.scope.html) encapsulate a number of processes that are started and stopped by arbitrary processes via fork(), and then registered at runtime with PID1. Scopes are named in the style of `wuff.scope`.
|
||||
- [_Slices_](http://www.freedesktop.org/software/systemd/man/systemd.slice.html) may be used to group a number of services and scopes together in a hierarchial tree. Slices do not contain processes themselves, but the services and scopes contained in them do. Slices are named in the style of `foobar-waldo.slice`, where the path to the location of the slice in the tree is encoded in the name with "-" as separator for the path components (`foobar-waldo.slice` is hence a subslice of `foobar.slice`). There's one special slices defined, `-.slice`, which is the root slice of all slices (`foobar.slice` is hence subslice of `-.slice`). This is similar how in regular file paths, "/" denotes the root directory.
|
||||
|
||||
Service, scope and slice units directly map to objects in the cgroup tree. When these units are activated they each map to directly (modulo some character escaping) to cgroup paths built from the unit names. For example, a service `quux.service` in a slice `foobar-waldo.slice` is found in the cgroup `foobar.slice/foobar-waldo.slice/quux.service/`.
|
||||
|
||||
@ -179,7 +179,7 @@ Resource limits may be set on services, scopes and slices the same way. All acti
|
||||
|
||||
Service and slice units may be configured via unit files on disk, or alternatively be created dynamically at runtime via API calls to PID 1. Scope units may only be created at runtime via API calls to PID 1, but not from unit files on disk. Units that are created dynamically at runtime via API calls are called _transient_ units. Transient units exist only during runtime and are released automatically as soon as they finished/got deactivated or the system is rebooted.
|
||||
|
||||
If a service/slice is configured via unit files on disk the resource controls may be configured with the settings documented in [systemd.resource-control(5)](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html). While the unit is started it may be reconfigured for services/slices/scopes (with changes applying instantly) with a command line such as:
|
||||
If a service/slice is configured via unit files on disk the resource controls may be configured with the settings documented in [systemd.resource-control(5)](http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html). While the unit are started they may be reconfigured for services/slices/scopes (with changes applying instantly) with the a command line such as:
|
||||
|
||||
```
|
||||
# systemctl set-property httpd.service CPUShares=500 MemoryLimit=500M
|
||||
@ -205,11 +205,11 @@ The properties array of `StartTransientUnit()` may take many of the settings tha
|
||||
|
||||
To alter resource control properties at runtime use the `SetUnitProperty()` call on the `Manager` object or `SetProperty()` on the individual Unit objects. This also takes an array of properties to set, in the same format as `StartTransientUnit()` takes. Note again that this is not a dictionary, and allows properties to be set multiple times with a single invocation. THis is useful for array properties: if a property is assigned the empty array it will be reset to the empty array itself, however if it is assigned a non-empty array then this array is appended to the previous array. This mimics behaviour of array settings in unit files. Note that most settings may only be set during creation of units with `StartTransientUnit()`, and may not be altered later on. The exception here are the resource control settings, more specifically `CPUAccounting`, `CPUShares`, `BlockIOAccounting`, `BlockIOWeight`, `BlockIOReadBandwidth`, `BlockIOWriteBandwidth`, `BlockIODeviceWeight`, `MemoryAccounting`, `MemoryLimit`, `DevicePolicy`, `DeviceAllow` for services/scopes/slices. Note that the standard D-Bus `org.freedesktop.DBus.Properties.Set()` call is currently not supported by any of the unit objects to set these properties, but might eventually (note however, that it is substantially less useful as it only allows setting a single property at a time, resulting in races).
|
||||
|
||||
The [`systemctl set-property`](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) command internally is little more than a wrapper around `SetUnitProperty()`. The [`systemd-run`](https://www.freedesktop.org/software/systemd/man/latest/systemd-run.html) tool is a wrapper around `StartTransientUnit()`. It may be used to either run a process as a transient service in the background, where it is invoked from PID 1, or alternatively as a scope unit in the foreground, where it is run from the `systemd-run` process itself.
|
||||
The [`systemctl set-property`](http://www.freedesktop.org/software/systemd/man/systemctl.html) command internally is little more than a wrapper around `SetUnitProperty()`. The [`systemd-run`](http://www.freedesktop.org/software/systemd/man/systemd-run.html) tool is a wrapper around `StartTransientUnit()`. It may be used to either run a process as a transient service in the background, where it is invoked from PID 1, or alternatively as a scope unit in the foreground, where it is run from the `systemd-run` process itself.
|
||||
|
||||
### Enumeration
|
||||
|
||||
To acquire a list of currently running units, use the `ListUnits()` call on the Manager bus object. To determine the scope/service unit and slice unit a process is running in use [`sd_pid_get_unit()`](https://www.freedesktop.org/software/systemd/man/latest/sd_pid_get_unit.html) and `sd_pid_get_slice()`. These two calls are implemented in `libsystemd-login.so`. These call bypass the system bus (which they can because they are passive and do not require privileges) and are hence very efficient to invoke.
|
||||
To acquire a list of currently running units, use the `ListUnits()` call on the Manager bus object. To determine the scope/service unit and slice unit a process is running in use [`sd_pid_get_unit()`](http://www.freedesktop.org/software/systemd/man/sd_pid_get_unit.html) and `sd_pid_get_slice()`. These two calls are implemented in `libsystemd-login.so`. These call bypass the system bus (which they can because they are passive and do not require privileges) and are hence very efficient to invoke.
|
||||
|
||||
### VM and Container Managers
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
Traditionally on most Linux distributions, regular (human) users are managed
|
||||
via entries in `/etc/passwd`, `/etc/shadow`, `/etc/group` and `/etc/gshadow`.
|
||||
With the advent of
|
||||
[`systemd-homed`](https://www.freedesktop.org/software/systemd/man/latest/systemd-homed.service.html)
|
||||
[`systemd-homed`](https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html)
|
||||
it might be desirable to convert an existing, traditional user account to a
|
||||
`systemd-homed` managed one.
|
||||
Below is a brief guide how to do that.
|
||||
@ -100,7 +100,7 @@ Here's the step-by-step guide:
|
||||
group as new primary group, but will have it as auxiliary group.
|
||||
|
||||
Consider reading through the
|
||||
[homectl(1)](https://www.freedesktop.org/software/systemd/man/latest/homectl.html)
|
||||
[homectl(1)](https://www.freedesktop.org/software/systemd/man/homectl.html)
|
||||
manual page at this point, maybe there are a couple of other settings you want to set for your new account.
|
||||
In particular, look at `--storage=` and `--disk-size=`, in order to change how your home directory shall be stored
|
||||
(the default `luks` storage is recommended).
|
||||
|
||||
@ -52,7 +52,7 @@ are required to collect and process a coredump successfully.
|
||||
## `systemd-coredump` Handler
|
||||
|
||||
The systemd suite provides a coredump handler
|
||||
[`systemd-coredump`](https://www.freedesktop.org/software/systemd/man/latest/systemd-coredump.html)
|
||||
[`systemd-coredump`](https://www.freedesktop.org/software/systemd/man/systemd-coredump.html)
|
||||
which can be enabled at build-time. It is activated during boot via the
|
||||
`/usr/lib/sysctl.d/50-coredump.conf` drop-in file for
|
||||
`systemd-sysctl.service`. It registers the `systemd-coredump` tool as
|
||||
@ -71,13 +71,13 @@ The `systemd-coredump` handler will extract a backtrace and
|
||||
[ELF packaging metadata](/PACKAGE_METADATA_FOR_EXECUTABLE_FILES)
|
||||
from any coredumps it receives and log both.
|
||||
The information about coredumps stored in the journal can be enumerated and queried with the
|
||||
[`coredumpctl`](https://www.freedesktop.org/software/systemd/man/latest/coredumpctl.html)
|
||||
[`coredumpctl`](https://www.freedesktop.org/software/systemd/man/coredumpctl.html)
|
||||
tool, for example for directly invoking a debugger such as `gdb` on a collected
|
||||
coredump.
|
||||
|
||||
The handler writes coredump files to `/var/lib/systemd/coredump/`.
|
||||
Old files are cleaned up periodically by
|
||||
[`systemd-tmpfiles(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-tmpfiles.html).
|
||||
[`systemd-tmpfiles(8)`](https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html).
|
||||
|
||||
## User Experience
|
||||
|
||||
|
||||
@ -96,7 +96,7 @@ for inclusion in a filename) in the unit file, under which the invoked service
|
||||
code can then retrieve it. Each name should only be specified once.
|
||||
|
||||
For details about these settings [see the man
|
||||
page](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#Credentials).
|
||||
page](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Credentials).
|
||||
|
||||
It is a good idea to also enable mount namespacing for services that process
|
||||
credentials configured this way. If so, the runtime credential directory of the
|
||||
@ -159,7 +159,7 @@ activation, so that service code only receives plaintext credentials.
|
||||
|
||||
## Programming Interface from Generator Code
|
||||
|
||||
[Generators](https://www.freedesktop.org/software/systemd/man/latest/systemd.generator.html)
|
||||
[Generators](https://www.freedesktop.org/software/systemd/man/systemd.generator.html)
|
||||
may generate native unit files from external configuration or system
|
||||
parameters, such as system credentials. Note that they run outside of service
|
||||
context, and hence will not receive encrypted credentials in plaintext
|
||||
@ -169,7 +169,7 @@ be placed as they are in a directory referenced by the
|
||||
plaintext form will be placed in `$CREDENTIALS_DIRECTORY`. Use a command such
|
||||
as `systemd-creds --system cat …` to access both forms of credentials, and
|
||||
decrypt them if needed (see
|
||||
[systemd-creds(1)](https://www.freedesktop.org/software/systemd/man/latest/systemd-creds.html)
|
||||
[systemd-creds(1)](https://www.freedesktop.org/software/systemd/man/systemd-creds.html)
|
||||
for details.
|
||||
|
||||
Note that generators typically run very early during boot (similar to initrd
|
||||
@ -184,7 +184,7 @@ For further details about encrypted credentials, see below.
|
||||
## Tools
|
||||
|
||||
The
|
||||
[`systemd-creds`](https://www.freedesktop.org/software/systemd/man/latest/systemd-creds.html)
|
||||
[`systemd-creds`](https://www.freedesktop.org/software/systemd/man/systemd-creds.html)
|
||||
tool is provided to work with system and service credentials. It may be used to
|
||||
access and enumerate system and service credentials, or to encrypt/decrypt credentials
|
||||
(for details about the latter, see below).
|
||||
@ -286,7 +286,7 @@ services where they are ultimately consumed.
|
||||
1. A container manager may set the `$CREDENTIALS_DIRECTORY` environment
|
||||
variable for systemd running as PID 1 in the container, the same way as
|
||||
systemd would set it for a service it invokes.
|
||||
[`systemd-nspawn(1)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-nspawn.html#Credentials)'s
|
||||
[`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) documentation.
|
||||
@ -311,7 +311,7 @@ services where they are ultimately consumed.
|
||||
|
||||
4. Credentials may also be passed from the UEFI environment to userspace, if
|
||||
the
|
||||
[`systemd-stub`](https://www.freedesktop.org/software/systemd/man/latest/systemd-stub.html)
|
||||
[`systemd-stub`](https://www.freedesktop.org/software/systemd/man/systemd-stub.html)
|
||||
UEFI kernel stub is used.
|
||||
This allows placing encrypted credentials in the EFI System Partition, which are then picked up by `systemd-stub` and passed to the kernel and ultimately userspace where systemd receives them.
|
||||
This is useful to implement secure parameterization of vendor-built and signed
|
||||
@ -370,7 +370,7 @@ systemd-run -p ImportCredential=mycred -P --wait systemd-creds cat mycred
|
||||
|
||||
Various services shipped with `systemd` consume credentials for tweaking behaviour:
|
||||
|
||||
* [`systemd(1)`](https://www.freedesktop.org/software/systemd/man/latest/systemd.html)
|
||||
* [`systemd(1)`](https://www.freedesktop.org/software/systemd/man/systemd.html)
|
||||
(I.E.: PID1, the system manager) will look for the credential `vmm.notify_socket`
|
||||
and will use it to send a `READY=1` datagram when the system has finished
|
||||
booting.
|
||||
@ -380,24 +380,24 @@ Various services shipped with `systemd` consume credentials for tweaking behavio
|
||||
The credential payload should be in the form: `vsock:<CID>:<PORT>`.
|
||||
Also note that this requires support for VSOCK to be built in both the guest and the host kernels, and the kernel modules to be loaded.
|
||||
|
||||
* [`systemd-sysusers(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-sysusers.html)
|
||||
* [`systemd-sysusers(8)`](https://www.freedesktop.org/software/systemd/man/systemd-sysusers.html)
|
||||
will look for the credentials `passwd.hashed-password.<username>`,
|
||||
`passwd.plaintext-password.<username>` and `passwd.shell.<username>` to
|
||||
configure the password (either in UNIX hashed form, or plaintext) or shell of
|
||||
system users created.
|
||||
Replace `<username>` with the system user of your choice, for example, `root`.
|
||||
|
||||
* [`systemd-firstboot(1)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-firstboot.html)
|
||||
* [`systemd-firstboot(1)`](https://www.freedesktop.org/software/systemd/man/systemd-firstboot.html)
|
||||
will look for the credentials `firstboot.locale`, `firstboot.locale-messages`,
|
||||
`firstboot.keymap`, `firstboot.timezone`, that configure locale, keymap or
|
||||
timezone settings in case the data is not yet set in `/etc/`.
|
||||
|
||||
* [`tmpfiles.d(5)`](https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html)
|
||||
* [`tmpfiles.d(5)`](https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html)
|
||||
will look for the credentials `tmpfiles.extra` with arbitrary tmpfiles.d lines.
|
||||
Can be encoded in base64 to allow easily passing it on the command line.
|
||||
|
||||
* Further well-known credentials are documented in
|
||||
[`systemd.system-credentials(7)`](https://www.freedesktop.org/software/systemd/man/latest/systemd.system-credentials.html).
|
||||
[`systemd.system-credentials(7)`](https://www.freedesktop.org/software/systemd/man/systemd.system-credentials.html).
|
||||
|
||||
In future more services are likely to gain support for consuming credentials.
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ you will need to do additional steps to get debugging information out of the mac
|
||||
|
||||
* Try CTRL+ALT+DEL to reboot.
|
||||
* If it does not reboot, mention it in your bugreport. Meanwhile force the reboot with
|
||||
[SysRq](https://fedoraproject.org/wiki/QA/Sysrq)
|
||||
[SysRq](http://fedoraproject.org/wiki/QA/Sysrq)
|
||||
or hard reset.
|
||||
* When booting the next time, you will have to add some kernel command line arguments depending on which of the debugging strategies you choose from the following options.
|
||||
|
||||
|
||||
@ -26,7 +26,7 @@ Currently nothing like this is supported or even planned.
|
||||
|
||||
## Pre-defined systemd units
|
||||
|
||||
[`systemd.special(7)`](https://www.freedesktop.org/software/systemd/man/latest/systemd.special.html)
|
||||
[`systemd.special(7)`](https://www.freedesktop.org/software/systemd/man/systemd.special.html)
|
||||
defines the `graphical-session.target` and `graphical-session-pre.target` to
|
||||
allow cross-desktop integration. Furthermore, systemd defines the three base
|
||||
slices `background`, `app` and `session`.
|
||||
|
||||
@ -56,7 +56,7 @@ If you prefer to use leap second steps, please register your own
|
||||
vendor pool at ntp.org and make it the built-in default by
|
||||
passing `-Dntp-servers=` to meson.
|
||||
Registering vendor pools is
|
||||
[free](https://www.pool.ntp.org/en/vendors.html).
|
||||
[free](http://www.pool.ntp.org/en/vendors.html).
|
||||
|
||||
Use `-Dntp-servers=` to direct systemd-timesyncd to different fallback
|
||||
NTP servers.
|
||||
|
||||
@ -62,8 +62,8 @@ A: Simply instantiate a new getty service for the port of your choice (internall
|
||||
# systemctl start serial-getty@ttyS2.service
|
||||
```
|
||||
|
||||
Note that gettys on the virtual console are started on demand. You can control how many you get via the NAutoVTs= setting in [logind.conf(7)](https://www.freedesktop.org/software/systemd/man/latest/systemd-logind.service.html).
|
||||
Also see [this blog story](https://0pointer.de/blog/projects/serial-console.html).
|
||||
Note that gettys on the virtual console are started on demand. You can control how many you get via the NAutoVTs= setting in [logind.conf(7)](http://www.freedesktop.org/software/systemd/man/systemd-logind.service).
|
||||
Also see [this blog story](http://0pointer.de/blog/projects/serial-console.html).
|
||||
|
||||
**Q: How to I figure out which service a process belongs to?**
|
||||
|
||||
@ -75,7 +75,7 @@ $ psc
|
||||
...
|
||||
```
|
||||
|
||||
Or you can even check /proc/$PID/cgroup directly. Also see [this blog story](https://0pointer.de/blog/projects/systemd-for-admins-2.html).
|
||||
Or you can even check /proc/$PID/cgroup directly. Also see [this blog story](http://0pointer.de/blog/projects/systemd-for-admins-2.html).
|
||||
|
||||
**Q: Why don't you use inotify to reload the unit files automatically on change?**
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@ mechanism: the service manager creates and listens on some sockets (and similar
|
||||
UNIX file descriptors) on behalf of a service, and then passes them to the
|
||||
service during activation of the service via UNIX file descriptor (short: *fd*)
|
||||
passing over `execve()`. This is primarily exposed in the
|
||||
[.socket](https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html)
|
||||
[.socket](https://www.freedesktop.org/software/systemd/man/systemd.socket.html)
|
||||
unit type.
|
||||
|
||||
The *file* *descriptor* *store* (short: *fdstore*) extends this concept, and
|
||||
@ -50,14 +50,14 @@ passed over.
|
||||
## Basic Mechanism
|
||||
|
||||
The fdstore is enabled per-service via the
|
||||
[`FileDescriptorStoreMax=`](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#FileDescriptorStoreMax=)
|
||||
[`FileDescriptorStoreMax=`](https://www.freedesktop.org/software/systemd/man/systemd.service.html#FileDescriptorStoreMax=)
|
||||
service setting. It defaults to zero (which means the fdstore logic is turned
|
||||
off), but can take an unsigned integer value that controls how many fds to
|
||||
permit the service to upload to the service manager to keep simultaneously.
|
||||
|
||||
If set to values > 0, the fdstore is enabled. When invoked the service may now
|
||||
(asynchronously) upload file descriptors to the fdstore via the
|
||||
[`sd_pid_notify_with_fds()`](https://www.freedesktop.org/software/systemd/man/latest/sd_pid_notify_with_fds.html)
|
||||
[`sd_pid_notify_with_fds()`](https://www.freedesktop.org/software/systemd/man/sd_pid_notify_with_fds.html)
|
||||
API call (or an equivalent re-implementation). When uploading the fds it is
|
||||
necessary to set the `FDSTORE=1` field in the message, to indicate what the fd
|
||||
is intended for. It's recommended to also set the `FDNAME=…` field to any
|
||||
@ -68,7 +68,7 @@ new instance following the same protocol as for socket activation fds. i.e. the
|
||||
`$LISTEN_FDS`, `$LISTEN_PID`, `$LISTEN_PIDFDID`, and `$LISTEN_FDNAMES`
|
||||
environment variables will be set (the latter will be populated from the
|
||||
`FDNAME=…` field mentioned above). See
|
||||
[`sd_listen_fds()`](https://www.freedesktop.org/software/systemd/man/latest/sd_listen_fds.html)
|
||||
[`sd_listen_fds()`](https://www.freedesktop.org/software/systemd/man/sd_listen_fds.html)
|
||||
for details on receiving such fds in a service. (Note that the name set in
|
||||
`FDNAME=…` does not need to be unique, which is useful when operating with
|
||||
multiple fully equivalent sockets or similar, for example for a service that
|
||||
@ -120,7 +120,7 @@ service will leave the fdstore intact, but a separate stop and start job for
|
||||
it — executed synchronously one after the other — will likely not.
|
||||
|
||||
This behavior can be modified via the
|
||||
[`FileDescriptorStorePreserve=`](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#FileDescriptorStorePreserve=)
|
||||
[`FileDescriptorStorePreserve=`](https://www.freedesktop.org/software/systemd/man/systemd.service.html#FileDescriptorStorePreserve=)
|
||||
setting in service unit files. If set to `yes` the fdstore will be kept as long
|
||||
as the service definition is loaded into memory by the service manager, i.e. as
|
||||
long as at least one other loaded unit has a reference to it.
|
||||
@ -138,7 +138,7 @@ to be unique, as mentioned, in which case *all* matching fds are
|
||||
closed). Generally it's a good idea to send such messages to the service
|
||||
manager during initialization of the service whenever an unrecognized fd is
|
||||
received, to make the service robust for code updates: if an old version
|
||||
uploaded an fd that the new version doesn't recognize anymore it's a good idea to
|
||||
uploaded an fd that the new version doesn't recognize anymore it's good idea to
|
||||
close it both in the service and in the fdstore.
|
||||
|
||||
Note that storing a duplicate of an fd in the fdstore means the resource pinned
|
||||
@ -154,7 +154,7 @@ Access to the fds in the file descriptor store is generally restricted to the
|
||||
service code itself. Pushing fds into or removing fds from the fdstore is
|
||||
subject to the access control restrictions of any other `sd_notify()` message,
|
||||
which is controlled via
|
||||
[`NotifyAccess=`](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#NotifyAccess=).
|
||||
[`NotifyAccess=`](https://www.freedesktop.org/software/systemd/man/systemd.service.html#NotifyAccess=).
|
||||
|
||||
By default only the main service process hence can push/remove fds, but by
|
||||
setting `NotifyAccess=all` this may be relaxed to allow arbitrary service
|
||||
@ -163,7 +163,7 @@ child processes to do the same.
|
||||
## Soft Reboot
|
||||
|
||||
The fdstore is particularly interesting in [soft
|
||||
reboot](https://www.freedesktop.org/software/systemd/man/latest/systemd-soft-reboot.service.html)
|
||||
reboot](https://www.freedesktop.org/software/systemd/man/systemd-soft-reboot.service.html)
|
||||
scenarios, as per `systemctl soft-reboot` (which restarts userspace like in a
|
||||
real reboot, but leaves the kernel running). File descriptor stores that remain
|
||||
loaded at the very end of the system cycle — just before the soft-reboot – are
|
||||
@ -179,7 +179,7 @@ or by setting `FileDescriptorStorePreserve=yes` (and referencing the unit
|
||||
continuously).
|
||||
|
||||
For further details see [Resource
|
||||
Pass-Through](https://www.freedesktop.org/software/systemd/man/latest/systemd-soft-reboot.service.html#Resource%20Pass-Through).
|
||||
Pass-Through](https://www.freedesktop.org/software/systemd/man/systemd-soft-reboot.service.html#Resource%20Pass-Through).
|
||||
|
||||
## Initrd Transitions
|
||||
|
||||
@ -201,12 +201,12 @@ recommended to use the fdstore if pinned resources shall be passed over.
|
||||
## Debugging
|
||||
|
||||
The
|
||||
[`systemd-analyze`](https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html#systemd-analyze%20fdstore%20%5BUNIT...%5D)
|
||||
[`systemd-analyze`](https://www.freedesktop.org/software/systemd/man/systemd-analyze.html#systemd-analyze%20fdstore%20%5BUNIT...%5D)
|
||||
tool may be used to list the current contents of the fdstore of any running
|
||||
service.
|
||||
|
||||
The
|
||||
[`systemd-run`](https://www.freedesktop.org/software/systemd/man/latest/systemd-run.html)
|
||||
[`systemd-run`](https://www.freedesktop.org/software/systemd/man/systemd-run.html)
|
||||
tool may be used to quickly start a testing binary or similar as a service. Use
|
||||
`-p FileDescriptorStoreMax=4711` to enable the fdstore from `systemd-run`'s
|
||||
command line. By using the `-t` switch you can even interactively communicate
|
||||
|
||||
@ -36,10 +36,6 @@ or via your distribution's package manager. Note that systemd regularly adopts
|
||||
newer mkosi features that are not in an official release yet so there's a good
|
||||
chance that your distribution's packaged version of mkosi will be too old.
|
||||
|
||||
Make sure to read the "Unprivileged User Namespaces" section in the mkosi documentation
|
||||
(run `mkosi documentation` to view the mkosi docs) and apply any necessary instructions
|
||||
to make sure unprivileged user namespaces work on your system.
|
||||
|
||||
Then, you can build, run and test systemd executables as follows:
|
||||
|
||||
```sh
|
||||
|
||||
@ -7,7 +7,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
|
||||
# Home Directories
|
||||
|
||||
[`systemd-homed.service(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-homed.service.html)
|
||||
[`systemd-homed.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html)
|
||||
manages home directories of regular ("human") users.
|
||||
Each directory it manages encapsulates both the data store and the user record of the user,
|
||||
so that it comprehensively describes the user account, and is thus naturally portable
|
||||
@ -34,7 +34,7 @@ the signature section itself.
|
||||
If the plain directory or `btrfs` subvolume storage mechanism of
|
||||
`systemd-homed` is used (i.e. `--storage=directory` or `--storage=subvolume` on
|
||||
the
|
||||
[`homectl(1)`](https://www.freedesktop.org/software/systemd/man/latest/homectl.html)
|
||||
[`homectl(1)`](https://www.freedesktop.org/software/systemd/man/homectl.html)
|
||||
command line) the home directory requires no special setup besides including
|
||||
the user record in the `~/.identity` file.
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@ Many of the incompatibilities are specific to distribution-specific extensions o
|
||||
* 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](https://www.freedesktop.org/software/systemd/man/latest/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".
|
||||
|
||||
@ -7,7 +7,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
|
||||
# Inhibitor Locks
|
||||
|
||||
systemd 183 and newer include a logic to inhibit system shutdowns and sleep states. This is implemented as part of [systemd-logind.daemon(8)](https://www.freedesktop.org/software/systemd/man/latest/systemd-logind.service.html) There are a couple of different use cases for this:
|
||||
systemd 183 and newer include a logic to inhibit system shutdowns and sleep states. This is implemented as part of [systemd-logind.daemon(8)](http://www.freedesktop.org/software/systemd/man/systemd-logind.service.html) There are a couple of different use cases for this:
|
||||
|
||||
- A CD burning application wants to ensure that the system is not turned off or suspended while the burn process is in progress.
|
||||
|
||||
@ -39,7 +39,7 @@ Two different modes of locks are supported:
|
||||
If such a lock is taken the operation will fail (but still may be overridden if the user possesses the necessary privileges).
|
||||
|
||||
2. _delay_ inhibits operations only temporarily, either until the lock is released or up to a certain amount of time.
|
||||
The InhibitDelayMaxSec= setting in [logind.conf(5)](https://www.freedesktop.org/software/systemd/man/latest/logind.conf.html) controls the timeout for this. This is intended to be used by applications which need a synchronous way to execute actions before system suspend but shall not be allowed to block suspend indefinitely.
|
||||
The InhibitDelayMaxSec= setting in [logind.conf(5)](http://www.freedesktop.org/software/systemd/man/logind.conf.html) controls the timeout for this. This is intended to be used by applications which need a synchronous way to execute actions before system suspend but shall not be allowed to block suspend indefinitely.
|
||||
This mode is only available for _sleep_ and _shutdown_ locks.
|
||||
|
||||
3. _block-weak_ is identical to _block_, but has no effect on operations
|
||||
@ -110,7 +110,7 @@ Note that this will only be sent out for suspend/resume cycles done via logind,
|
||||
|
||||
The **BlockInhibited** and **DelayInhibited** properties encode what types of locks are currently taken. These fields are a colon separated list of `shutdown`, `sleep`, `idle`, `handle-power-key`, `handle-suspend-key`, `handle-hibernate-key`, `handle-lid-switch`. The list is basically the union of the What fields of all currently active locks of the specific mode.
|
||||
|
||||
**InhibitDelayMaxUSec** contains the delay timeout value as configured in [logind.conf(5)](https://www.freedesktop.org/software/systemd/man/latest/logind.conf.html).
|
||||
**InhibitDelayMaxUSec** contains the delay timeout value as configured in [logind.conf(5)](http://www.freedesktop.org/software/systemd/man/logind.conf.html).
|
||||
|
||||
The **PreparingForShutdown** and **PreparingForSleep** boolean properties are true between the two PrepareForShutdown() resp PrepareForSleep() signals that are sent out.
|
||||
Note that these properties do not trigger PropertyChanged signals.
|
||||
@ -202,9 +202,9 @@ This can be quite detrimental for the battery.
|
||||
|
||||
If an application finds a lock denied it should not consider this much of an error and just continue its operation without the protecting lock.
|
||||
|
||||
The tool [systemd-inhibit(1)](https://www.freedesktop.org/software/systemd/man/latest/systemd-inhibit.html) may be used to take locks or list active locks from the command line.
|
||||
The tool [systemd-inhibit(1)](http://www.freedesktop.org/software/systemd/man/systemd-inhibit.html) may be used to take locks or list active locks from the command line.
|
||||
|
||||
Note that gnome-session also provides an [inhibitor API](https://gnome.pages.gitlab.gnome.org/gnome-session/re06.html), which is very similar to the one of systemd.
|
||||
Note that gnome-session also provides an [inhibitor API](http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.Inhibit), which is very similar to the one of systemd.
|
||||
Internally, locks taken on gnome-session's interface will be forwarded to logind, hence both APIs are supported.
|
||||
|
||||
While both offer similar functionality they do differ in some regards.
|
||||
|
||||
@ -13,7 +13,7 @@ _Note that this document describes the binary serialization format of journals o
|
||||
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)._
|
||||
|
||||
_Before reading on, please make sure you are aware of the [basic properties of journal entries](https://www.freedesktop.org/software/systemd/man/latest/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)._
|
||||
_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)._
|
||||
|
||||
When exporting journal data for other uses or transferring it via the network/local IPC the _journal export format_ is used.
|
||||
It's a simple serialization of journal entries, that is easy to read without any special tools, but still binary safe where necessary.
|
||||
@ -138,7 +138,7 @@ _Note that this section describes the JSON serialization format of the journal o
|
||||
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)._
|
||||
|
||||
_Before reading on, please make sure you are aware of the [basic properties of journal entries](https://www.freedesktop.org/software/systemd/man/latest/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)._
|
||||
_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)._
|
||||
|
||||
In most cases the Journal JSON serialization is the obvious mapping of the entry field names (as JSON strings) to the entry field values (also as JSON strings) encapsulated in one JSON object. However, there are a few special cases to handle:
|
||||
|
||||
|
||||
@ -30,7 +30,7 @@ so if this document and the code disagree, the code is right.
|
||||
That said we'll of course try hard to keep this document up-to-date and accurate.
|
||||
|
||||
Instead of implementing your own reader or writer for journal files we ask you to use the
|
||||
[Journal's native CAPI](https://www.freedesktop.org/software/systemd/man/latest/sd-journal.html)
|
||||
[Journal's native CAPI](https://www.freedesktop.org/software/systemd/man/sd-journal.html)
|
||||
to access these files.
|
||||
It provides you with full access to the files, and will not withhold any data.
|
||||
If you find a limitation, please ping us and we might add some additional interfaces for you.
|
||||
@ -42,7 +42,7 @@ The export format is much simpler to parse, but complete and accurate.
|
||||
Due to its stream-based nature it is not indexed.
|
||||
|
||||
_Or, to put this in other words: this low-level document is probably not what you want to use as base of your project.
|
||||
You want our [C API](https://www.freedesktop.org/software/systemd/man/latest/sd-journal.html) instead!
|
||||
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) instead!
|
||||
This document is primarily for your entertainment and education.
|
||||
@ -51,7 +51,7 @@ Thank you!_
|
||||
This document assumes you have a basic understanding of the journal concepts, the properties of a journal entry and so on.
|
||||
If not, please go and read up, then come back!
|
||||
This is a good opportunity to read about the
|
||||
[basic properties of journal entries](https://www.freedesktop.org/software/systemd/man/latest/systemd.journal-fields.html),
|
||||
[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.
|
||||
|
||||
@ -587,7 +587,7 @@ If the hash table fill level is increasing over a certain fill level (Learning
|
||||
from Java's Hashtable for example: > 75%), the writer should rotate the file
|
||||
and create a new one.
|
||||
|
||||
The DATA_HASH_TABLE should be sized taking into account the maximum size the
|
||||
The DATA_HASH_TABLE should be sized taking into account to the maximum size the
|
||||
file is expected to grow, as configured by the administrator or disk space
|
||||
considerations. The FIELD_HASH_TABLE should be sized to a fixed size; the
|
||||
number of fields should be pretty static as it depends only on developers'
|
||||
|
||||
@ -18,7 +18,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
The latter is what this document is about: if you are developing a program and
|
||||
want to pass structured log data to `journald`, it's the Journal's native
|
||||
protocol that you want to use. The systemd project provides the
|
||||
[`sd_journal_print(3)`](https://www.freedesktop.org/software/systemd/man/latest/sd_journal_print.html)
|
||||
[`sd_journal_print(3)`](https://www.freedesktop.org/software/systemd/man/sd_journal_print.html)
|
||||
API that implements the client side of this protocol. This document explains
|
||||
what this interface does behind the scenes, in case you'd like to implement a
|
||||
client for it yourself, without linking to `libsystemd` — for example because
|
||||
@ -96,7 +96,7 @@ actual log message text. Other relevant keys a client should send in most cases
|
||||
are `PRIORITY=`, `CODE_FILE=`, `CODE_LINE=`, `CODE_FUNC=`, `ERRNO=`. It's
|
||||
recommended to generate these fields implicitly on the client side. For further
|
||||
information see the [relevant documentation of these
|
||||
fields](https://www.freedesktop.org/software/systemd/man/latest/systemd.journal-fields.html).
|
||||
fields](https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html).
|
||||
|
||||
The order in which the fields are serialized within one datagram is undefined
|
||||
and may be freely chosen by the client. The server side might or might not
|
||||
|
||||
@ -71,7 +71,7 @@ service manager, and typically consumed by the service:
|
||||
service's cgroup. In order to make debugging easier, and allow later
|
||||
extension it is recommended for applications to also allow this path to refer
|
||||
to an `AF_UNIX` stream socket in the file system or a FIFO inode in the file
|
||||
system. Regardless of which of the three types of inodes this absolute path
|
||||
system. Regardless which of the three types of inodes this absolute path
|
||||
refers to, all three are `poll()`-able for memory pressure events. The
|
||||
variable can also be set to the literal string `/dev/null`. If so the service
|
||||
code should take this as indication that memory pressure monitoring is not
|
||||
@ -165,7 +165,7 @@ The service manager provides two per-service settings that control the memory
|
||||
pressure handling:
|
||||
|
||||
* The
|
||||
[`MemoryPressureWatch=`](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html#MemoryPressureWatch=)
|
||||
[`MemoryPressureWatch=`](https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#MemoryPressureWatch=)
|
||||
setting controls whether to enable the memory pressure protocol for the
|
||||
service in question.
|
||||
|
||||
@ -197,12 +197,12 @@ When memory pressure monitoring is enabled for a service via
|
||||
## Memory Pressure Events in `sd-event`
|
||||
|
||||
The
|
||||
[`sd-event`](https://www.freedesktop.org/software/systemd/man/latest/sd-event.html)
|
||||
[`sd-event`](https://www.freedesktop.org/software/systemd/man/sd-event.html)
|
||||
event loop library provides two API calls that encapsulate the
|
||||
functionality described above:
|
||||
|
||||
* The
|
||||
[`sd_event_add_memory_pressure()`](https://www.freedesktop.org/software/systemd/man/latest/sd_event_add_memory_pressure.html)
|
||||
[`sd_event_add_memory_pressure()`](https://www.freedesktop.org/software/systemd/man/sd_event_add_memory_pressure.html)
|
||||
call implements the service-side of the memory pressure protocol and
|
||||
integrates it with an `sd-event` event loop. It reads the two environment
|
||||
variables, connects/opens the specified file, writes the specified data to it,
|
||||
|
||||
@ -43,7 +43,7 @@ This overrides the default logic for this one service only,
|
||||
and places all its processes back in the root cgroup of the "cpu" hierarchy, which has the full RT budget assigned.
|
||||
* A third option is to simply assign your service a realtime budget.
|
||||
For that use `ControlGroupAttribute=cpu.rt_runtime_us 500000` in its `[Service]` or suchlike.
|
||||
See [the kernel documentation](https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt) for details.
|
||||
See [the kernel documentation](http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt) for details.
|
||||
The latter two options are not available for System V services.
|
||||
A possible solution is to write a small wrapper service file that simply calls the SysV script's start verb in `ExecStart=` and the stop verb in `ExecStop=`.
|
||||
(It also needs to set `RemainAfterExit=1` and `Type=forking`!)
|
||||
|
||||
@ -67,7 +67,7 @@ before any routable network interface is up). Its primary purpose is network
|
||||
client software that cannot operate without network.
|
||||
|
||||
For more details about those targets, see the
|
||||
[systemd.special(7)](https://www.freedesktop.org/software/systemd/man/latest/systemd.special.html)
|
||||
[systemd.special(7)](https://www.freedesktop.org/software/systemd/man/systemd.special.html)
|
||||
man page.
|
||||
|
||||
## Compatibility with SysV init
|
||||
@ -80,7 +80,7 @@ translate this to `Wants=` and `After=` dependencies on
|
||||
# Discussion
|
||||
|
||||
The meaning of `$network` is defined [only very
|
||||
unprecisely](https://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/facilname.html)
|
||||
unprecisely](http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/facilname.html)
|
||||
and people tend to have different ideas what it is supposed to mean. Here are a
|
||||
couple of ideas people came up with so far:
|
||||
|
||||
@ -99,7 +99,7 @@ couple of ideas people came up with so far:
|
||||
* And so on and so on.
|
||||
|
||||
All these are valid approaches to the question "When is the network up?", but
|
||||
none of them would be good as a generic default.
|
||||
none of them would be useful to be good as generic default.
|
||||
|
||||
Modern networking tends to be highly dynamic: machines are moved between
|
||||
networks, network configuration changes, hardware is added and removed, virtual
|
||||
@ -211,7 +211,7 @@ Here are a couple of possible approaches:
|
||||
actually (yet or ever) configured locally. This also makes your code robust
|
||||
towards network configuration changes. This is provided as `FreeBind=`
|
||||
for systemd services, see
|
||||
[systemd.socket(5)](https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html).
|
||||
[systemd.socket(5)](https://www.freedesktop.org/software/systemd/man/systemd.socket.html).
|
||||
|
||||
An exception to the above recommendations is services which require network
|
||||
connectivity, but do not delay system startup. An example may be a service
|
||||
@ -234,13 +234,13 @@ specific to those services.
|
||||
|
||||
For example, `systemd-networkd-wait-online.service` will wait until all
|
||||
interfaces that are present and managed by
|
||||
[systemd-networkd.service(8)](https://www.freedesktop.org/software/systemd/man/latest/systemd-networkd.service.html).
|
||||
[systemd-networkd.service(8)](https://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html).
|
||||
are fully configured or failed and at least one link is online; see
|
||||
[systemd-networkd-wait-online.service(8)](https://www.freedesktop.org/software/systemd/man/latest/systemd-networkd-wait-online.service.html)
|
||||
[systemd-networkd-wait-online.service(8)](https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html)
|
||||
for details. Those conditions are affected by the presence of configuration
|
||||
that matches various links, but also by settings like
|
||||
`Unmanaged=`, `RequiredForOnline=`, `RequiredFamilyForOnline=`; see
|
||||
[systemd.network(5)](https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html).
|
||||
[systemd.network(5)](https://www.freedesktop.org/software/systemd/man/systemd.network.html).
|
||||
|
||||
It is also possible to plug in additional checks for network state. For
|
||||
example, to delay `network-online.target` until a specific host is
|
||||
|
||||
@ -96,7 +96,7 @@ This requires introduction of a new kernel interface to get notifications for cg
|
||||
|
||||
19. Make use of EXT4_IOC_MOVE_EXT in systemd's readahead implementation.
|
||||
This allows reordering/defragmentation of the files needed for boot.
|
||||
According to the data from [https://e4rat.sourceforge.net/](https://e4rat.sourceforge.net/) this might shorten the boot time to 40%.
|
||||
According to the data from [http://e4rat.sourceforge.net/](http://e4rat.sourceforge.net/) this might shorten the boot time to 40%.
|
||||
Implementation is not trivial, but given that we already support btrfs defragmentation and example code for this exists (e4rat as linked) should be fairly straightforward.
|
||||
|
||||
20. Compress readahead pack files with XZ or so.Since boot these days tends to be clearly IO bound (and not CPU bound) it might make sense to reduce the IO load for the pack file by compressing it. Since we already have a dependency on XZ we'd recommend using XZ for this.
|
||||
|
||||
@ -1 +1,339 @@
|
||||
[This content has moved to the UAPI group website](https://uapi-group.org/specifications/specs/osc_context/)
|
||||
---
|
||||
title: OSC 3008: Hierarchical Context Signalling
|
||||
category: Interfaces
|
||||
layout: default
|
||||
SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
---
|
||||
|
||||
# OSC 3008: Hierarchical Context Signalling
|
||||
|
||||
A terminal connects a user with programs. Control of the program side of
|
||||
terminals is typically passed around to various different components while the
|
||||
user is active: a shell might pass control to a process it invokes. If that
|
||||
process is `run0` then primary control is passed to the privileged session of
|
||||
the target user. If `systemd-nspawn` is invoked to start a container, primary
|
||||
control is passed to that container, and so on.
|
||||
|
||||
A terminal emulator might be interested to know which component is currently in
|
||||
primary control of the program side of a terminal. OSC 3008 is a mechanism to
|
||||
inform it about such contexts. Each component taking over control can inform
|
||||
the terminal emulators that a new context begins now, and then use the terminal
|
||||
or pass control down to further apps, which can introduce contexts. Each
|
||||
context may carry various descriptive metadata fields.
|
||||
|
||||
## Status
|
||||
|
||||
This OSC sequence has been invented by the systemd project and is generated by
|
||||
systemd. Currently, no terminal application is known that consumes these
|
||||
sequences.
|
||||
|
||||
## Use Cases
|
||||
|
||||
Terminal emulators can use hierarchical context information:
|
||||
|
||||
1. To introduce markers/bookmarks in the output that the user can jump between.
|
||||
|
||||
2. To visually identify output from different contexts. For example the
|
||||
background of the associated output can be tinted in a reddish tone when
|
||||
privileges are acquired, and similar.
|
||||
|
||||
3. Meta information on specific output can be shown in a tooltip or similar
|
||||
|
||||
4. Programs (and all subcontexts) can be killed via a right-click menu on the
|
||||
output they generate.
|
||||
|
||||
5. Similar, a right-click menu might offer an item to offer opening a new
|
||||
interactive shell in the same working directory that was current on the
|
||||
selected context.
|
||||
|
||||
6. Failed commands or aborted sessions can be marked requesting user attention.
|
||||
|
||||
## Context Types
|
||||
|
||||
There are various types of contexts defined by this specification:
|
||||
|
||||
1. `boot` → a booted system initiates this context early at boot. (systemd's
|
||||
PID 1 generates this on `/dev/console`.)
|
||||
|
||||
2. `container` → a container manager initialized an interactive connection to a
|
||||
container. (`systemd-nspawn` generates this when interactively invoking a
|
||||
container. `machinectl login`, `machinectl shell` do this too.)
|
||||
|
||||
3. `vm` → a VM manager initialized a terminal connection to a
|
||||
VM. (`systemd-vmspawn` generates this when interactively invoking a VM, as
|
||||
one example.)
|
||||
|
||||
4. `elevate` → when the user interactively acquired higher privileges. (`run0`
|
||||
initiates a context of this type whenever the user invokes it to acquire
|
||||
root privileges.)
|
||||
|
||||
5. `chpriv` → similar, but when the user acquired *different* privileges, not
|
||||
necessarily higher ones. (`run0` initiates a context of this type whenever
|
||||
the user invokes it to acquire non-root privileges of another user.)
|
||||
|
||||
5. `subcontext` → similar, but the source and target privileges where
|
||||
identical. (`run0` initiates a context of this type whenever the user
|
||||
invokes it to acquire privileges of the user itself.)
|
||||
|
||||
6. `remote` → a user invoked a tool such as `ssh` to connect to a remote
|
||||
system.
|
||||
|
||||
7. `shell` → an interactive terminal shell initiates this context
|
||||
|
||||
8. `command` → a shell interactively invokes a new program.
|
||||
|
||||
9. `app` → an interactive program may initiate this context.
|
||||
|
||||
10. `service` → the service manager invokes an interactive service on the terminal
|
||||
|
||||
11. `session` → a login session of the user is initialized.
|
||||
|
||||
## Semantics
|
||||
|
||||
Contexts in the sense of OSC 3008 are hierarchical, and describe a tree
|
||||
structure: whenever a new context is opened it becomes the new active context,
|
||||
and the previously active context becomes its parent (if there is one). Only
|
||||
one context is currently active, but previously opened contexts remain valid in
|
||||
the background. Any other data written or read should be considered associated
|
||||
with the currently active context.
|
||||
|
||||
Each context carries an identifier, chosen by the component opening the
|
||||
context. The identifier can chosen freely, but must not be longer than 64
|
||||
characters. The characters may be in the 32…126 byte range. Identifiers should
|
||||
be universally unique, for example randomly generated. A freshly generated UUID
|
||||
would work well for this, but this could also be something like the Linux boot
|
||||
ID combined with the 64bit inode number of Linux pidfds, or something hashed
|
||||
from it.
|
||||
|
||||
Fundamentally, there are two OSC 3008 commands defined:
|
||||
|
||||
1. OSC "`3008;start=`" … (the *start sequence*) → this initiates, updates or
|
||||
indicates a return to a context. It carries a context identifier, and
|
||||
typically some metadata. This may be sent to first initiate a context. If
|
||||
sent again for the same context ID that was initiated already this indicates
|
||||
an update of the existing context. In this case, *any* previously set
|
||||
metadata fields for the context are flushed out, reset to their defaults,
|
||||
and then reinitialized from the newly supplied data. Also, in this case any
|
||||
subcontexts of the contexts are implicitly terminated.
|
||||
|
||||
2. OSC "`3008;end=`" … (the *end sequence*) → this terminates a context. It
|
||||
carries a context identifier to close, initiated before with OSC
|
||||
"`3008;start=`". It may also carry additional metadata.
|
||||
|
||||
## General Syntax
|
||||
|
||||
This builds on ECMA-48, and reuses the OSC and ST concepts introduced there.
|
||||
|
||||
For sequences following this specification it is recommended to encode OSC as
|
||||
0x1B 0x5D, and ST as 0x1B 0x5C.
|
||||
|
||||
ECMA-48 only allows characters from the range 0x20…0x7e (i.e. 32…126) inside
|
||||
OSC sequences. However, most terminal emulators nowadays allow the ASCII byte
|
||||
range > 0x7f in the OSC sequences they process, and so does this
|
||||
specification. Control characters (< 0x20 and 0x7f) are not allowed. The
|
||||
semicolon character ("`;`") – which is used as field separator by this
|
||||
specification – shall be replaced by "`\x3b`" and the backslash character
|
||||
("`\`") shall be replaced by "`\x5c`". All textual fields must be encoded in
|
||||
UTF-8, and then escaped with these two replacements.
|
||||
|
||||
The start sequence begins with OSC, followed by the string `3008;start=`,
|
||||
followed by the context ID. This is then followed by any number of metadata
|
||||
fields, including none. Metadata fields begin with a semicolon (`;`) followed
|
||||
by in a string identifying the type of field, followed by an equal sign (`=`),
|
||||
and the field value. The sequence ends in ST.
|
||||
|
||||
The end sequence begins with OSC, followed by the string `3008;end=`, followed
|
||||
by the context ID, and a series of metadata fields in the same syntax as for
|
||||
the start sequence. The sequence ends in ST.
|
||||
|
||||
## Metadata Fields
|
||||
|
||||
The following fields are currently defined for the start sequence:
|
||||
|
||||
| Field | Context Types | Description |
|
||||
|---------------|---------------|-------------------------------------------------------------------------------------------------------------|
|
||||
| `type=` | *all* | Declares the context type, one of the types described above |
|
||||
| `user=` | *all* | UNIX user name the process issuing the sequence runs as |
|
||||
| `hostname=` | *all* | UNIX host name of the system the process issuing the sequence runs on |
|
||||
| `machineid=` | *all* | The machine ID (i.e. `/etc/machine-id`) of the system the process issuing the sequence runs on |
|
||||
| `bootid=` | *all* | The boot ID (i.e. `/proc/sys/kernel/random/boot_id`) of the system the process issuing the sequence runs on |
|
||||
| `pid=` | *all* | The numeric PID of the process issuing the sequence, in decimal notation |
|
||||
| `pidfdid=` | *all* | The 64bit inode number of the pidfd of the process issuing the sequence, in decimal notation |
|
||||
| `comm=` | *all* | The process name (i.e. `/proc/$PID/comm`, `PR_GET_NAME`) of the process issuing the sequence |
|
||||
| `cwd=` | `shell`, `command` | The current working directory |
|
||||
| `cmdline=` | `command` | The full command line of the invoked command |
|
||||
| `vm=` | `vm` | The name of the VM being invoked |
|
||||
| `container=` | `container` | The name of the container being invoked |
|
||||
| `targetuser=` | `elevate`, `chpriv`, `vm`, `container`, `remote`, `session` | Target UNIX user name |
|
||||
| `targethost=` | `remote` | Target UNIX, DNS host name, or IP address |
|
||||
| `sessionid=` | `session` | New allocated session ID |
|
||||
|
||||
The following fields are currently defined for the end sequence:
|
||||
|
||||
| Field | Context Types | Description |
|
||||
|---------------|---------------|-------------------------------------------------------------------------------------------------------------|
|
||||
| `exit=` | `command` | One of `success`, `failure`, `crash`, `interrupt`, indicating how the program terminated |
|
||||
| `status=` | `command` | The command's numeric exit status, i.e. the 0…255 value a program returns |
|
||||
| `signal=` | `command` | The termination signal of the command, if it died abnormally. A symbolic signal name. (`SIGKILL`, …) |
|
||||
|
||||
All fields are optional, including the context type. However, it is generally
|
||||
recommended to always include the first 7 fields listed above, to make it easy
|
||||
to pinpoint the origin of a context in a race-free fashion, without any
|
||||
ambiguities.
|
||||
|
||||
The order of the metadata fields is undefined, they may appear in any order
|
||||
(including that `type=` is specified at the very end or in the middle!). Note
|
||||
that `start=` and `end=` are not considered metadata fields but part of the
|
||||
start sequence, and hence must always appear right after OSC.
|
||||
|
||||
## Processing, Limits, Security
|
||||
|
||||
All context information provided like this should be considered auxiliary and –
|
||||
to some degree – redundant information. Hence, it would be wise for a terminal
|
||||
to enforce limits on various resources, dropping additional data once these
|
||||
limits are hit. Most importantly, a maximum stacking depth should probably
|
||||
enforced: any attempts to initiate further contexts should be ignored once the
|
||||
stack limit is hit (i.e. the earlier contexts should be kept, the later
|
||||
contexts be discarded, not the opposite). Overly long fields should be
|
||||
discarded (or potentially truncated, depending on the field type). This
|
||||
specification does not recommend any specific stack or string limits for now.
|
||||
|
||||
The usual terminal reset sequences should *not* affect the stack of contexts
|
||||
(this is a safety feature: a program down the stack should not be able to
|
||||
affect the stack further up, possibly hiding relevant information). A temporary
|
||||
TTY hangup (`vhangup()`) should result in a full reset of the stack.
|
||||
|
||||
All provided data should be processed in a lenient, graceful fashion: if a
|
||||
sequence contains invalid fields, those fields should be ignored, but the rest
|
||||
of the fields should still be used. In particular, unknown fields should be
|
||||
ignored.
|
||||
|
||||
The fields provided in these sequences should not contain sensitive
|
||||
information. Context IDs should not be considered confidential, but it is
|
||||
strongly recommended to generate them in a fashion that guarantees their
|
||||
sufficient uniqueness and avoids accidental or intended clashes with other
|
||||
contents.
|
||||
|
||||
## Examples
|
||||
|
||||
1. A new container `foobar` has been invoked by user `lennart` on host `zeta`:
|
||||
`OSC "3008;start=bed86fab93af4328bbed0a1224af6d40;type=container;user=lennart;hostname=zeta;machineid=3deb5353d3ba43d08201c136a47ead7b;bootid=d4a3d0fdf2e24fdea6d971ce73f4fbf2;pid=1062862;pidfdid=1063162;comm=systemd-nspawn;container=foobar" ST`
|
||||
|
||||
2. This context ends: `OSC "3008;end=bed86fab93af4328bbed0a1224af6d40" ST`
|
||||
|
||||
## Syntax in ABNF
|
||||
|
||||
```abnf
|
||||
OSC = %x1B %x5D
|
||||
ST = %x1B %x5C
|
||||
|
||||
DECIMAL = "0"-"9"
|
||||
HEX = "0"-"9" / "A"-"F" / "a-f"
|
||||
ID128 = 32*36(HEX / "-")
|
||||
UINT64 = 1*20DECIMAL
|
||||
ESCSEMICOLON = "\x3b"
|
||||
ESCBACKSLASH = "\x5c"
|
||||
SAFE = %x20-3a / %x3c-5b / %x5d-7e / ESCSEMICOLON / ESCBACKSLASH
|
||||
|
||||
CTXID = 1*64SAFE
|
||||
TYPEENUM = "service" / "session" / "shell" / "command" / "vm" / "container" / "elevate" / "chpriv" / "subcontext" / "remote" / "boot" / "app"
|
||||
|
||||
TYPE = "type=" TYPEENUM
|
||||
USER = "user=" 1*255SAFE
|
||||
HOSTNAME = "hostname=" 1*255SAFE
|
||||
MACHINEID = "machineid=" 1D128
|
||||
BOOTID = "bootid=" ID128
|
||||
PID = "pid=" UINT64
|
||||
PIDFDID = "pidfdid=" UINT64
|
||||
COMM = "comm=" 1*255SAFE
|
||||
CWD = "cwd=" 1*255SAFE
|
||||
CMDLINE = "cmdline=" *255SAFE
|
||||
VM = "vm=" 1*255SAFE
|
||||
CONTAINER = "container=" 1*255SAFE
|
||||
TARGETUSER = "targetuser=" 1*255SAFE
|
||||
TARGETHOST = "targethost=" 1*255SAFE
|
||||
SESSIONID = "sessionid=" 1*255SAFE
|
||||
|
||||
STARTFIELD = TYPE / USER / HOSTNAME / MACHINEID / BOOTID / PID / PIDFDID / COMM / CWD / CMDLINE / VM / CONTAINER / TARGETUSER / TARGETHOST / SESSIONID
|
||||
STARTSEQ = OSC "3008;start=" CTXID *(";" STARTFIELD) ST
|
||||
|
||||
EXITENUM = "success" / "failure" / "crash" / "interrupt"
|
||||
SIGNALENUM = "SIGBUS" / "SIGTRAP" / "SIGABRT" / "SIGSEGV" / …
|
||||
|
||||
EXIT = "exit=" EXITENUM
|
||||
STATUS = "status=" UINT64
|
||||
SIGNAL = "signal=" SIGNALENUM
|
||||
|
||||
ENDFIELD = EXIT / STATUS / SIGNAL
|
||||
ENDSEQ = OSC "3008;end=" CTXID *(";" ENDFIELD) ST
|
||||
```
|
||||
|
||||
## Known OSC Prefixes
|
||||
|
||||
Here's a list of OSC prefixes used by the various sequences currently in public
|
||||
use in various terminal emulators. It's not going to be complete, but I tried
|
||||
to do some reasonably thorough research to avoid conflicts with the new OSC
|
||||
sequence defined above.
|
||||
|
||||
| OSC Prefix | Purpose |
|
||||
|----------------:|------------------------------------------------------------|
|
||||
| `OSC "0;…"` | Icon name + window title |
|
||||
| `OSC "1;…"` | Icon name |
|
||||
| `OSC "2;…"` | Window title |
|
||||
| `OSC "3;…"` | X11 property |
|
||||
| `OSC "4;…"` | Palette |
|
||||
| `OSC "5;…"` | Special palette |
|
||||
| `OSC "6;…"` | Disable special color |
|
||||
| `OSC "7;…"` | Report cwd |
|
||||
| `OSC "8;…"` | Hyperlink |
|
||||
| `OSC "9;…"` | Progress bar (conemu) [conflict: also growl notifications] |
|
||||
| `OSC "10;…"` | Change colors |
|
||||
| `OSC "11;…"` | " |
|
||||
| `OSC "12;…"` | " |
|
||||
| `OSC "13;…"` | " |
|
||||
| `OSC "14;…"` | " |
|
||||
| `OSC "15;…"` | " |
|
||||
| `OSC "16;…"` | " |
|
||||
| `OSC "17;…"` | " |
|
||||
| `OSC "18;…"` | " |
|
||||
| `OSC "19;…"` | " |
|
||||
| `OSC "21;…"` | Query colors (kitty) |
|
||||
| `OSC "22;…"` | Cursor shape |
|
||||
| `OSC "46;…"` | Log file |
|
||||
| `OSC "50;…"` | Set font |
|
||||
| `OSC "51;…"` | Emacs shell |
|
||||
| `OSC "52;…"` | Manipulate selection data (aka clipboard) |
|
||||
| `OSC "60;…"` | Query allowed |
|
||||
| `OSC "61;…"` | Query disallowed |
|
||||
| `OSC "99;…"` | Notifications (kitty) |
|
||||
| `OSC "104;…"` | Reset color |
|
||||
| `OSC "105;…"` | Enable/disable special color |
|
||||
| `OSC "110;…"` | Reset colors |
|
||||
| `OSC "111;…"` | " |
|
||||
| `OSC "112;…"` | " |
|
||||
| `OSC "113;…"` | " |
|
||||
| `OSC "114;…"` | " |
|
||||
| `OSC "115;…"` | " |
|
||||
| `OSC "116;…"` | " |
|
||||
| `OSC "117;…"` | " |
|
||||
| `OSC "118;…"` | " |
|
||||
| `OSC "119;…"` | " |
|
||||
| `OSC "133;…"` | Prompt/command begin/command end (finalterm/iterm2) |
|
||||
| `OSC "440;…"` | Audio (mintty) |
|
||||
| `OSC "633;…"` | vscode action (Windows Terminal) |
|
||||
| `OSC "666;…"` | "termprop" (vte) |
|
||||
| `OSC "701;…"` | Locale (mintty) |
|
||||
| `OSC "777;…"` | Notification (rxvt) |
|
||||
| `OSC "3008;…"` | This specification |
|
||||
| `OSC "7704;…"` | ANSI colors (mintty) |
|
||||
| `OSC "7750;…"` | Emoji style (mintty) |
|
||||
| `OSC "7770;…"` | Font size (mintty) |
|
||||
| `OSC "7771;…"` | Glyph coverage (mintty) |
|
||||
| `OSC "7721:…"` | Copy window title (mintty) |
|
||||
| `OSC "7777;…"` | Window size (mintty) |
|
||||
| `OSC "9001;…"` | Action (Windows Terminal) |
|
||||
| `OSC "1337;…"` | iterm2 multiplex seeuqnece |
|
||||
| `OSC "5522;…"` | Clipboard (kitty) |
|
||||
| `OSC "30001;…"` | Push color onto stack (kitty) |
|
||||
| `OSC "30101;…"` | Pop color from stack (kitty) |
|
||||
| `OSC "77119;…"` | Wide chars (mintty) |
|
||||
|
||||
@ -40,9 +40,7 @@ It is easy to write additional agents. The basic algorithm to follow looks like
|
||||
* You'll find the PID of the client asking the question in the `PID=` field in the `[Ask]` section
|
||||
(Before asking your question use `kill(PID, 0)` and ignore the file if this returns `ESRCH`;
|
||||
there's no need to show the data of this field but if you want to you may)
|
||||
* `Echo=` specifies whether the input should be obscured. If this field is missing or is `Echo=0`, the input should not be shown as-is.
|
||||
* `Silent=` specifies whether the input should have any indication. If this field is `Silent=1`, nothing should be printed for any input.
|
||||
* `AcceptCached=` specifies whether a cached password is acceptable or not. If this field is missing or is `AcceptCached=0`, the password should not be provided from a cache.
|
||||
* `Echo=` specifies whether the input should be obscured. If this field is missing or is `Echo=0`, the input should not be shown.
|
||||
* The socket to send the response to is configured via `Socket=` in the `[Ask]` section. It is a `AF_UNIX`/`SOCK_DGRAM` socket in the file system.
|
||||
* Ignore files where the time specified in the `NotAfter=` field in the `[Ask]` section is in the past.
|
||||
The time is specified in usecs, and refers to the `CLOCK_MONOTONIC` clock. If `NotAfter=` is `0`, no such check should take place.
|
||||
@ -102,4 +100,4 @@ now available, with the same protocol as the system-wide
|
||||
counterpart. Unprivileged, per-directory agents should watch this directory in
|
||||
parallel to the system-wide one. Unprivileged queriers (i.e. clients to these
|
||||
agents) should pick the per-user directory to place their password request
|
||||
files in. If the directory does not exist, agents may create it.
|
||||
files in.
|
||||
|
||||
@ -85,7 +85,7 @@ You should consider these recommendations if you are you working on one of the f
|
||||
Ignore EEXIST on mkdir.
|
||||
- Avoid renaming cgroups or similar fancier file operations.
|
||||
- Expect that other programs might readjust the attributes on your cgroups dynamically during runtime.
|
||||
- When creating a cgroup pick a descriptive name that is guessable and no surprise to the admin.
|
||||
- When creating a cgroup pick a nice a descriptive name that is guessable and no surprise to the admin.
|
||||
The admin will thank you for this if he has to read the output of "ps -eo pid,args,cgroups"
|
||||
- /sys/fs/cgroup is a tmpfs. If you create your own private named hierarchy then you are welcome to mount it into a subdirectory of this directory.
|
||||
This minimizes surprises for the user.
|
||||
|
||||
@ -1,110 +1,82 @@
|
||||
---
|
||||
title: Portability and Stability
|
||||
title: Interface Portability and Stability
|
||||
category: Interfaces
|
||||
layout: default
|
||||
SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
---
|
||||
|
||||
# Portability and Stability Promise
|
||||
# Interface Portability and Stability Promise
|
||||
|
||||
We try to keep backward compatibility for public interfaces,
|
||||
and we try to avoid breaking them whenever possible, as described below.
|
||||
We'll try to fix any reported regressions.
|
||||
systemd provides various interfaces developers and programs might rely on.
|
||||
Starting with version 26 (the first version released with Fedora 15) we promise to keep a number of them stable and compatible for the future.
|
||||
|
||||
Occasionally we need to remove some interface or raise the minimum required version of a dependency.
|
||||
In those cases, we'll announce the deprecation and removal plan in NEWS for a future release.
|
||||
The feedback from users and distributions will be taken into account.
|
||||
The stable interfaces are:
|
||||
|
||||
To allow systemd to add new features and improve existing functionality,
|
||||
it constantly needs to evolve.
|
||||
To make this process smooth,
|
||||
users are encouraged to follow the categorization of interfaces below.
|
||||
Interfaces listed as stable are intended for public consumption,
|
||||
so it's explicitly OK to rely on their stability.
|
||||
Interfaces listed as unstable are likely to change without notice,
|
||||
so please do not use those in places where stability is required.
|
||||
|
||||
Note that the promise of stability applies only after an interface has been part of a release.
|
||||
|
||||
|
||||
## Stable interfaces
|
||||
|
||||
* **The public interface of the `libsystemd` shared library**.
|
||||
|
||||
* **The D-Bus interfaces** of the manager and other daemons.
|
||||
|
||||
* **The Varlink interfaces** of the manager and other daemons.
|
||||
|
||||
* **The unit configuration file format**.
|
||||
Unit files written now will stay compatible with future versions of systemd.
|
||||
* **The unit configuration file format**. Unit files written now will stay compatible with future versions of systemd.
|
||||
Extensions to the file format will happen in a way that existing files remain compatible.
|
||||
|
||||
* **The command line interface** of `systemd`, `systemctl`, `loginctl`, `journalctl`,
|
||||
and all other command line utilities documented in a man page.
|
||||
Note however that the _output_ generated by these commands is generally not stable,
|
||||
except in cases documented in the man page.
|
||||
Example: the output of `systemctl status` is not stable,
|
||||
but that of `systemctl show` is,
|
||||
because the former is intended to be human-readable and the latter computer-readable,
|
||||
and this is documented in the man page.
|
||||
* **The command line interface** of `systemd`, `systemctl`, `loginctl`, `journalctl`, and all other command line utilities installed in `$PATH` and documented in a man page.
|
||||
We will make sure that scripts invoking these commands will continue to work with future versions of systemd.
|
||||
Note however that the output generated by these commands is generally not included in the promise, unless it is documented in the man page.
|
||||
Example: the output of `systemctl status` is not stable, but that of `systemctl show` is, because the former is intended to be human-readable and the latter computer readable, and this is documented in the man page.
|
||||
|
||||
* **The protocol spoken on the socket referred to by `$NOTIFY_SOCKET`**, as documented in
|
||||
[sd_notify(3)](https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html).
|
||||
Although using libsystemd is a good choice,
|
||||
this protocol can also be reimplemented without external dependencies,
|
||||
as demonstrated in the example listed in
|
||||
[sd_notify(3)](https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html#Notes).
|
||||
[sd_notify(3)](https://www.freedesktop.org/software/systemd/man/sd_notify.html). Note that, although using
|
||||
libsystemd is a good choice, this protocol can also be reimplemented without external dependencies, as
|
||||
demonstrated in the example listed in
|
||||
[sd_notify(3)](https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes)
|
||||
|
||||
* Some of the **"special" unit names** and their semantics.
|
||||
To be precise the ones that are necessary for normal services,
|
||||
and not those required only for early boot and late shutdown,
|
||||
with very few exceptions.
|
||||
To list them here:
|
||||
`basic.target`,
|
||||
`shutdown.target`,
|
||||
`sockets.target`,
|
||||
`network.target`,
|
||||
`getty.target`,
|
||||
`graphical.target`,
|
||||
`multi-user.target`,
|
||||
`rescue.target`,
|
||||
`emergency.target`,
|
||||
`poweroff.target`,
|
||||
`reboot.target`,
|
||||
`halt.target`,
|
||||
`runlevel[1-5].target`.
|
||||
To be precise the ones that are necessary for normal services, and not those required only for early boot and late shutdown, with very few exceptions.
|
||||
To list them here: `basic.target`, `shutdown.target`, `sockets.target`, `network.target`, `getty.target`, `graphical.target`, `multi-user.target`, `rescue.target`, `emergency.target`, `poweroff.target`, `reboot.target`, `halt.target`, `runlevel[1-5].target`.
|
||||
|
||||
We try to always preserve backward compatibility in programmatic interfaces
|
||||
and intentional breakage is never introduced.
|
||||
Nevertheless, when we find bugs that mean that the existing interface was not useful,
|
||||
or when the implementation did something different than stated by the documentation
|
||||
and the implemented behaviour is not useful,
|
||||
we will fix the implementation and thus introduce a change in behaviour.
|
||||
But the API (parameter counts and types) is never changed incompatibly,
|
||||
and existing attributes and methods are never removed.
|
||||
* **The D-Bus interfaces of the main service daemon and other daemons**. We try to always preserve backwards compatibility, and intentional breakage is never introduced.
|
||||
Nevertheless, when we find bugs that mean that the existing interface was not useful, or when the implementation did something different than stated by the documentation and the implemented behaviour is not useful, we will fix the implementation and thus introduce a change in behaviour.
|
||||
But the API (parameter counts and types) is never changed, and existing attributes and methods will not be removed.
|
||||
|
||||
* For a more comprehensive and authoritative list, consult the chart below.
|
||||
|
||||
## Unstable interfaces
|
||||
The following interfaces will not necessarily be kept stable for now, but we will eventually make a stability promise for these interfaces too.
|
||||
In the meantime we will however try to keep breakage of these interfaces at a minimum:
|
||||
|
||||
* **The set of states of the various state machines used in systemd**,
|
||||
e.g. the high-level unit states `inactive`, `active`, `deactivating`, and so on,
|
||||
as well as the low-level unit states.
|
||||
* **The set of states of the various state machines used in systemd**, e.g. the high-level unit states inactive, active, deactivating, and so on, as well (and in particular) the low-level per-unit states.
|
||||
|
||||
* **All "special" units that aren't listed above**.
|
||||
|
||||
* **The internal protocols** used on the various sockets such as
|
||||
`/run/systemd/shutdown`, `/run/systemd/private`.
|
||||
The following interfaces are considered private to systemd, and are not and will not be covered by any stability promise:
|
||||
|
||||
* **The private shared libraries** like `libsystemd-shared.so` which
|
||||
are installed into a private systemd directory.
|
||||
* **Undocumented switches** to `systemd`, `systemctl` and otherwise.
|
||||
|
||||
* **The internal protocols** used on the various sockets such as the sockets `/run/systemd/shutdown`, `/run/systemd/private`.
|
||||
|
||||
## Portability
|
||||
|
||||
One of the main goals of the systemd project
|
||||
is to unify basic Linux configuration mechanism and service behaviour across distributions.
|
||||
One of the main goals of systemd is to unify basic Linux configurations and service behaviors across all distributions.
|
||||
Systemd project does not contain any distribution-specific parts.
|
||||
Distributions are expected over time to convert their individual configurations to the systemd format.
|
||||
Distributions are expected to convert over time their individual configurations to the systemd format, or they will need to carry and maintain patches in their package if they still decide to stay different.
|
||||
|
||||
What does this mean for you? When developing with systemd, don't use any of the latter interfaces, or we will tell your mom, and she won't love you anymore.
|
||||
You are welcome to use the other interfaces listed here, but if you use any of the second kind (i.e. those where we don't yet make a stability promise), then make sure to subscribe to our mailing list, where we will announce API changes, and be prepared to update your program eventually.
|
||||
|
||||
Note that this is a promise, not an eternal guarantee.
|
||||
These are our intentions, but if in the future there are very good reasons to change or get rid of an interface we have listed above as stable, then we might take the liberty to do so, despite this promise.
|
||||
However, if we do this, then we'll do our best to provide a smooth and reasonably long transition phase.
|
||||
|
||||
|
||||
## Interface Portability And Stability Chart
|
||||
|
||||
systemd provides a number of APIs to applications.
|
||||
Below you'll find a table detailing which APIs are considered stable and how portable they are.
|
||||
|
||||
This list is intended to be useful for distribution and OS developers who are interested in maintaining a certain level of compatibility with the new interfaces systemd introduced, without relying on systemd itself.
|
||||
|
||||
In general it is our intention to cooperate through interfaces and not code with other distributions and OSes.
|
||||
That means that the interfaces where this applies are best reimplemented in a compatible fashion on those other operating systems.
|
||||
To make this easy we provide detailed interface documentation where necessary.
|
||||
That said, it's all Open Source, hence you have the option to a) fork our code and maintain portable versions of the parts you are interested in independently for your OS, or b) build systemd for your distro, but leave out all components except the ones you are interested in and run them without the core of systemd involved.
|
||||
We will try not to make this any more difficult than necessary.
|
||||
Patches to allow systemd code to be more portable will be accepted on case-by-case basis (essentially, patches to follow well-established standards instead of e.g. glibc or linux extensions have a very high chance of being accepted, while patches which make the code ugly or exist solely to work around bugs in other projects have a low chance of being accepted).
|
||||
|
||||
Many of these interfaces are already being used by applications and 3rd party code.
|
||||
If you are interested in compatibility with these applications, please consider supporting these interfaces in your distribution, where possible.
|
||||
|
||||
|
||||
## General Portability of systemd and its Components
|
||||
@ -112,40 +84,108 @@ Distributions are expected over time to convert their individual configurations
|
||||
**Portability to OSes:** systemd is not portable to non-Linux systems.
|
||||
It makes use of a large number of Linux-specific interfaces, including many that are used by its very core.
|
||||
We do not consider it feasible to port systemd to other Unixes (let alone non-Unix operating systems) and will not accept patches for systemd core implementing any such portability (but hey, it's git, so it's as easy as it can get to maintain your own fork...).
|
||||
APIs that are supposed to be used as library code are exempted from this: it is important to us that these compile nicely on non-Linux and even non-Unix platforms, even if they might just become NOPs.
|
||||
|
||||
**Portability to Architectures:** Systemd is portable to little endian as well as big endian systems.
|
||||
We maintain portability to all common architectures and hardware Linux runs on and are happy to accept patches for this.
|
||||
**Portability to Architectures:** It is important to us that systemd is portable to little endian as well as big endian systems.
|
||||
We will make sure to provide portability with all important architectures and hardware Linux runs on and are happy to accept patches for this.
|
||||
|
||||
**Portability to Distributions:**
|
||||
It is important to us that systemd is portable to all Linux distributions.
|
||||
However, the goal is to unify many of the needless differences between the distributions,
|
||||
and hence we will not accept patches for distribution-specific work-arounds.
|
||||
Compatibility with the distribution's legacy should be maintained in the distribution's packaging,
|
||||
and not in the systemd source tree.
|
||||
**Portability to Distributions:** It is important to us that systemd is portable to all Linux distributions.
|
||||
However, the goal is to unify many of the needless differences between the distributions, and hence will not accept patches for certain distribution-specific work-arounds.
|
||||
Compatibility with the distribution's legacy should be maintained in the distribution's packaging, and not in the systemd source tree.
|
||||
|
||||
**Compatibility with Specific Versions of Other packages:**
|
||||
We generally avoid adding compatibility kludges to systemd that
|
||||
work around bugs in certain versions of other software systemd interfaces with.
|
||||
We strongly encourage fixing bugs where they are,
|
||||
and if that's not systemd we rather not try to fix it here.
|
||||
**Compatibility with Specific Versions of Other packages:** We generally avoid adding compatibility kludges to systemd that work around bugs in certain versions of other software systemd interfaces with. We strongly encourage fixing bugs where they are, and if that's not systemd we rather not try to fix it there.
|
||||
(There are very few exceptions to this rule possible, and you need an exceptionally strong case for it).
|
||||
|
||||
|
||||
## General Portability of systemd's APIs
|
||||
|
||||
systemd's APIs are available everywhere where systemd is available.
|
||||
Some of the APIs we have defined are supposed to be generic enough
|
||||
to be implementable independently of systemd,
|
||||
thus allowing compatibility with systems systemd itself is not compatible with,
|
||||
i.e. other OSes, and distributions that are unwilling to fully adopt systemd.
|
||||
Some of the APIs we have defined are supposed to be generic enough to be implementable independently of systemd, thus allowing compatibility with systems systemd itself is not compatible with, i.e. other OSes, and distributions that are unwilling to fully adopt systemd.
|
||||
|
||||
A number of systemd's APIs expose Linux or systemd-specific features
|
||||
that cannot sensibly be implemented elsewhere.
|
||||
A number of systemd's APIs expose Linux or systemd-specific features that cannot sensibly be implemented elsewhere.
|
||||
Please consult the table below for information about which ones these are.
|
||||
|
||||
Note that not all of these interfaces are our invention (but most),
|
||||
we just adopted them in systemd to make them more prominently implemented.
|
||||
Note that not all of these interfaces are our invention (but most), we just adopted them in systemd to make them more prominently implemented.
|
||||
For example, we adopted many Debian facilities in systemd to push it into the other distributions as well.
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
And now, here's the list of (hopefully) all APIs that we have introduced with systemd:
|
||||
|
||||
| API | Type | Covered by Interface Stability Promise | Fully documented | Known External Consumers | Reimplementable Independently | Known Other Implementations | systemd Implementation portable to other OSes or non-systemd distributions |
|
||||
| --- | ---- | ----------------------------------------------------------------------------------------- | ---------------- | ------------------------ | ----------------------------- | --------------------------- | -------------------------------------------------------------------------- |
|
||||
| [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) | 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 |
|
||||
| [sd-daemon.h API](https://www.freedesktop.org/software/systemd/man/sd-daemon.html) | C Library or Drop-in | yes | yes | numerous | yes | - | yes |
|
||||
| [sd-device.h API](https://www.freedesktop.org/software/systemd/man/sd-device.html) | C Library | yes | no | numerous | yes | - | yes |
|
||||
| [sd-event.h API](https://www.freedesktop.org/software/systemd/man/sd-event.html) | C Library | yes | yes | - | maybe | - | maybe |
|
||||
| [sd-gpt.h API](https://www.freedesktop.org/software/systemd/man/sd-gpt.html) | Header Library | yes | no | - | yes | - | yes |
|
||||
| [sd-hwdb.h API](https://www.freedesktop.org/software/systemd/man/sd-hwdb.html) | C Library | yes | yes | - | maybe | - | yes |
|
||||
| [sd-id128.h API](https://www.freedesktop.org/software/systemd/man/sd-id128.html) | C Library | yes | yes | - | yes | - | yes |
|
||||
| [sd-journal.h API](https://www.freedesktop.org/software/systemd/man/sd-journal.html) | C Library | yes | yes | - | maybe | - | no |
|
||||
| [sd-login.h API](https://www.freedesktop.org/software/systemd/man/sd-login.html) | C Library | yes | yes | GNOME, polkit, ... | no | - | no |
|
||||
| [sd-messages.h API](https://www.freedesktop.org/software/systemd/man/sd-messages.html) | Header Library | yes | yes | - | yes | python-systemd | yes |
|
||||
| [sd-path.h API](https://www.freedesktop.org/software/systemd/man/sd-path.html) | C Library | yes | no | - | 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) | `/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) | File format | yes | yes | - | maybe | - | no |
|
||||
| [Journal Export Format](JOURNAL_EXPORT_FORMATS#journal-export-format) | File format | yes | yes | - | yes | - | no |
|
||||
| [Journal JSON Format](JOURNAL_EXPORT_FORMATS#journal-json-format) | File format | 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 |
|
||||
| [tmpfiles.d](https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html) | File format | yes | yes | numerous | yes | ArchLinux | partially |
|
||||
| [sysusers.d](https://www.freedesktop.org/software/systemd/man/sysusers.d.html) | File format | yes | yes | unknown | yes | | partially |
|
||||
| [/etc/machine-id](https://www.freedesktop.org/software/systemd/man/machine-id.html) | File format | yes | yes | D-Bus | yes | - | no |
|
||||
| [binfmt.d](https://www.freedesktop.org/software/systemd/man/binfmt.d.html) | File format | yes | yes | numerous | yes | - | partially |
|
||||
| [/etc/hostname](https://www.freedesktop.org/software/systemd/man/hostname.html) | File format | yes | yes | numerous (it's a Debian thing) | yes | Debian, ArchLinux | no |
|
||||
| [/etc/locale.conf](https://www.freedesktop.org/software/systemd/man/locale.conf.html) | File format | yes | yes | - | yes | ArchLinux | partially |
|
||||
| [/etc/machine-info](https://www.freedesktop.org/software/systemd/man/machine-info.html) | File format | yes | yes | - | yes | - | partially |
|
||||
| [modules-load.d](https://www.freedesktop.org/software/systemd/man/modules-load.d.html) | File format | yes | yes | numerous | yes | - | partially |
|
||||
| [/usr/lib/os-release](https://www.freedesktop.org/software/systemd/man/os-release.html) | File format | yes | yes | some | yes | Fedora, OpenSUSE, ArchLinux, Angstrom, Frugalware, others... | no |
|
||||
| [sysctl.d](https://www.freedesktop.org/software/systemd/man/sysctl.d.html) | File format | yes | yes | some (it's a Debian thing) | yes | procps/Debian, ArchLinux | partially |
|
||||
| [/etc/timezone](https://www.freedesktop.org/software/systemd/man/timezone.html) | File format | yes | yes | numerous (it's a Debian thing) | yes | Debian | partially |
|
||||
| [/etc/vconsole.conf](https://www.freedesktop.org/software/systemd/man/vconsole.conf.html) | File format | yes | yes | - | yes | ArchLinux | partially |
|
||||
| `/run` | File hierarchy change | yes | yes | numerous | yes | OpenSUSE, Debian, ArchLinux | no |
|
||||
| [Generators](https://www.freedesktop.org/software/systemd/man/systemd.generator.html) | Subprocess | yes | yes | - | no | - | no |
|
||||
| [System Updates](https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html) | System Mode | yes | yes | - | no | - | no |
|
||||
| [Presets](https://www.freedesktop.org/software/systemd/man/systemd.preset.html) | File format | yes | yes | - | no | - | no |
|
||||
| Udev rules | File format | yes | yes | numerous | no | no | partially |
|
||||
|
||||
|
||||
### Explanations
|
||||
|
||||
Items for which "systemd implementation portable to other OSes" is "partially" means that it is possible to run the respective tools that are included in the systemd tarball outside of systemd.
|
||||
Note however that this is not officially supported, so you are more or less on your own if you do this.
|
||||
If you are opting for this solution simply build systemd as you normally would but drop all files except those which you are interested in.
|
||||
|
||||
Of course, it is our intention to eventually document all interfaces we defined.
|
||||
If we haven't documented them for now, this is usually because we want the flexibility to still change things, or don't want 3rd party applications to make use of these interfaces already.
|
||||
That said, our sources are quite readable and open source, so feel free to spelunk around in the sources if you want to know more.
|
||||
|
||||
If you decide to reimplement one of the APIs for which "Reimplementable independently" is "no", then we won't stop you, but you are on your own.
|
||||
|
||||
This is not an attempt to comprehensively list all users of these APIs.
|
||||
We are just listing the most obvious/prominent ones which come to our mind.
|
||||
|
||||
Of course, one last thing I can't make myself not ask you before we finish here, and before you start reimplementing these APIs in your distribution:
|
||||
are you sure it's time well spent if you work on reimplementing all this code instead of just spending it on adopting systemd on your distro as well?
|
||||
|
||||
## Independent Operation of systemd Programs
|
||||
|
||||
Some programs in the systemd suite are intended to operate independently of the
|
||||
|
||||
@ -131,7 +131,7 @@ And that's already it.
|
||||
|
||||
Note that the images need to stay around (and in the same location) as long as the
|
||||
portable service is attached.
|
||||
If an image is moved, the `RootImage=` line written to the unit drop-in would point to a non-existent path, and break access to the image.
|
||||
If an image is moved, the `RootImage=` line written to the unit drop-in would point to an non-existent path, and break access to the image.
|
||||
|
||||
The `portablectl detach` command executes the reverse operation:
|
||||
it looks for the drop-ins and the unit files associated with the image, and removes them.
|
||||
@ -239,7 +239,7 @@ image.
|
||||
As mentioned, `mkosi -b` takes care of all of that for you, but any other image generator should work too.
|
||||
|
||||
The
|
||||
[os-release(5)](https://www.freedesktop.org/software/systemd/man/latest/os-release.html)
|
||||
[os-release(5)](https://www.freedesktop.org/software/systemd/man/os-release.html)
|
||||
file may optionally be extended with a `PORTABLE_PREFIXES=` field listing all
|
||||
supported portable service prefixes for the image (see above).
|
||||
This is useful for informational purposes (as it allows recognizing portable service images
|
||||
@ -361,7 +361,7 @@ PORTABLE_EXTENSION_NAME_AND_VERSION=app_1
|
||||
|
||||
## Links
|
||||
|
||||
[`portablectl(1)`](https://www.freedesktop.org/software/systemd/man/latest/portablectl.html)<br>
|
||||
[`systemd-portabled.service(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-portabled.service.html)<br>
|
||||
[`portablectl(1)`](https://www.freedesktop.org/software/systemd/man/portablectl.html)<br>
|
||||
[`systemd-portabled.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-portabled.service.html)<br>
|
||||
[Walkthrough for Portable Services](https://0pointer.net/blog/walkthrough-for-portable-services.html)<br>
|
||||
[Repo with examples](https://github.com/systemd/portable-walkthrough)
|
||||
|
||||
@ -81,10 +81,10 @@ With this new scheme in place, an administrator now has to check first what the
|
||||
You basically have three options:
|
||||
|
||||
1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: `ln -s /dev/null /etc/systemd/network/99-default.link`
|
||||
1. You create your own manual naming scheme, for example by naming your interfaces `internet0`, `dmz0` or `lan0`. For that create your own `.link` files in `/etc/systemd/network/`, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See [systemd.link(5)](https://www.freedesktop.org/software/systemd/man/latest/systemd.link.html) for more information.
|
||||
1. You create your own manual naming scheme, for example by naming your interfaces `internet0`, `dmz0` or `lan0`. For that create your own `.link` files in `/etc/systemd/network/`, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See [systemd.link(5)](https://www.freedesktop.org/software/systemd/man/systemd.link.html) for more information.
|
||||
1. You pass the `net.ifnames=0` on the kernel command line
|
||||
|
||||
## How does the new naming scheme look like, precisely?
|
||||
|
||||
That's documented in detail the [systemd.net-naming-scheme(7)](https://www.freedesktop.org/software/systemd/man/latest/systemd.net-naming-scheme.html) man page.
|
||||
That's documented in detail the [systemd.net-naming-scheme(7)](https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html) man page.
|
||||
Please refer to this in case you are wondering how to decode the new interface names.
|
||||
|
||||
@ -40,11 +40,11 @@ Preset files allow clean separation of enablement mechanism (inside the package
|
||||
|
||||
## Documentation
|
||||
|
||||
Documentation for the preset policy file format is available here: [https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html](https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html)
|
||||
Documentation for the preset policy file format is available here: [http://www.freedesktop.org/software/systemd/man/systemd.preset.html](http://www.freedesktop.org/software/systemd/man/systemd.preset.html)
|
||||
|
||||
Documentation for "systemctl preset" you find here: [https://www.freedesktop.org/software/systemd/man/latest/systemctl.html](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html)
|
||||
Documentation for "systemctl preset" you find here: [http://www.freedesktop.org/software/systemd/man/systemctl.html](http://www.freedesktop.org/software/systemd/man/systemctl.html)
|
||||
|
||||
Documentation for the recommended package scriptlets you find here: [https://www.freedesktop.org/software/systemd/man/latest/daemon.html](https://www.freedesktop.org/software/systemd/man/latest/daemon.html)
|
||||
Documentation for the recommended package scriptlets you find here: [http://www.freedesktop.org/software/systemd/man/daemon.html](http://www.freedesktop.org/software/systemd/man/daemon.html)
|
||||
|
||||
## How To
|
||||
|
||||
|
||||
@ -153,7 +153,7 @@ boot, in order to ensure the entropy pool is filled up quickly.
|
||||
provides virtualized RNG hardware (and VM environments really should!).
|
||||
|
||||
2. The
|
||||
[`systemd-random-seed.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-random-seed.service.html)
|
||||
[`systemd-random-seed.service`](https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html)
|
||||
system service will load a random seed from `/var/lib/systemd/random-seed`
|
||||
into the kernel entropy pool.
|
||||
By default it does not credit entropy for it though, since the seed is — more often than not — not reset when 'golden' master images of an OS are created, and thus replicated into every installation.
|
||||
@ -167,12 +167,12 @@ boot, in order to ensure the entropy pool is filled up quickly.
|
||||
require an initialized entropy pool to operate correctly.
|
||||
|
||||
3. The
|
||||
[`systemd-boot`](https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html)
|
||||
[`systemd-boot`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)
|
||||
EFI boot loader included in systemd is able to maintain and provide a random
|
||||
seed stored in the EFI System Partition (ESP) to the booted OS, which allows
|
||||
booting up with a fully initialized entropy pool from earliest boot on.
|
||||
During installation of the boot loader (or when invoking
|
||||
[`bootctlrandom-seed`](https://www.freedesktop.org/software/systemd/man/latest/bootctl.html#random-seed))
|
||||
[`bootctlrandom-seed`](https://www.freedesktop.org/software/systemd/man/bootctl.html#random-seed))
|
||||
a seed file with an initial seed is placed in a file `/loader/random-seed` in the ESP.
|
||||
In addition, an identically sized randomized EFI variable called the 'system token' is set, which is written to the machine's firmware NVRAM.
|
||||
|
||||
@ -301,8 +301,8 @@ This primarily leaves two kind of systems in the cold:
|
||||
|
||||
5. *Why don't you use
|
||||
[`rngd`](https://github.com/nhorman/rng-tools),
|
||||
[`haveged`](https://www.issihosts.com/haveged/),
|
||||
[`egd`](https://egd.sourceforge.net/)?
|
||||
[`haveged`](http://www.issihosts.com/haveged/),
|
||||
[`egd`](http://egd.sourceforge.net/)?
|
||||
That's all you need!*
|
||||
|
||||
Like `uuidd` above these are system services, hence come too late for our use-case.
|
||||
@ -362,7 +362,7 @@ This primarily leaves two kind of systems in the cold:
|
||||
loader random seeds too!*
|
||||
|
||||
Well, consider just switching to `systemd-boot`, it's worth it. See
|
||||
[systemd-boot(7)](https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html)
|
||||
[systemd-boot(7)](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)
|
||||
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
|
||||
|
||||
@ -14,7 +14,7 @@ interfaces.
|
||||
|
||||
For a verbose explanation of `systemd-resolved.service`'s domain routing logic,
|
||||
see its [man
|
||||
page](https://www.freedesktop.org/software/systemd/man/latest/systemd-resolved.service.html). This
|
||||
page](https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html). This
|
||||
document is supposed to provide examples to use the concepts for the specific
|
||||
purpose of managing VPN DNS configuration.
|
||||
|
||||
@ -184,14 +184,14 @@ the configuration to `systemd-resolved.service`? There are three relevant
|
||||
interfaces:
|
||||
|
||||
1. Ideally, you use D-Bus and talk to [`systemd-resolved.service`'s D-Bus
|
||||
API](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.resolve1.html)
|
||||
API](https://www.freedesktop.org/software/systemd/man/org.freedesktop.resolve1.html)
|
||||
directly. Use `SetLinkDomains()` to set the per-interface search and routing
|
||||
domains on the interfaces you manage, and `SetLinkDefaultRoute()` to manage
|
||||
the `default-route` boolean, all on the `org.freedesktop.resolve1.Manager`
|
||||
interface of the `/org/freedesktop/resolve1` object.
|
||||
|
||||
2. If that's not in the cards, you may shell out to
|
||||
[`resolvectl`](https://www.freedesktop.org/software/systemd/man/latest/resolvectl.html),
|
||||
[`resolvectl`](https://www.freedesktop.org/software/systemd/man/resolvectl.html),
|
||||
which is a thin wrapper around the D-Bus interface mentioned above. Use
|
||||
`resolvectl domain <iface> …` to set the search/routing domains and
|
||||
`resolvectl default-route <iface> …` to set the `default-route` boolean.
|
||||
|
||||
@ -101,7 +101,7 @@ auxiliary resources:
|
||||
> [!NOTE]
|
||||
> Depending on the execution environment the first component (the boot loader)
|
||||
> might be dispensable. Specifically, on disk images intended solely for use in
|
||||
> VMs, it might make sense to tell the firmware to directly boot a UKI,
|
||||
> VMs, it might be make sense to tell the firmware to directly boot a UKI,
|
||||
> letting the VMM's image selection functionality play the role of the boot loader.
|
||||
|
||||
> [!NOTE]
|
||||
|
||||
@ -21,7 +21,7 @@ On a systemd system it is no longer OK to listen on /dev/log directly, and your
|
||||
If you do that then you will lose logging from STDOUT/STDERR of services (as well as other stuff).
|
||||
|
||||
Your BSD compatible logging service should alias `syslog.service` to itself (i.e. symlink) when it is _enabled_.
|
||||
That way [syslog.socket](https://github.com/systemd/systemd/blob/main/units/syslog.socket) will activate your service when things are logged.
|
||||
That way [syslog.socket](http://cgit.freedesktop.org/systemd/systemd/plain/units/syslog.socket) will activate your service when things are logged.
|
||||
Of course, only one implementation of BSD syslog can own that symlink, and hence only one implementation can be enabled at a time, but that's intended as there can only be one process listening on that socket.
|
||||
(see below for details how to manage this symlink.)
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ If the `$TMPDIR` environment variable is set, use that path, and neither use
|
||||
`/tmp/` nor `/var/tmp/` directly.
|
||||
|
||||
See
|
||||
[file-hierarchy(7)](https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html)
|
||||
[file-hierarchy(7)](https://www.freedesktop.org/software/systemd/man/file-hierarchy.html)
|
||||
for details about these two (and most other) directories of a Linux system.
|
||||
|
||||
## Common Namespace
|
||||
|
||||
@ -41,9 +41,9 @@ A unified filesystem layout (as it results from the /usr merge) is more compatib
|
||||
|
||||
- /usr/bin/foo may be called by other tools either via /usr/bin/foo or /bin/foo, both paths become fully equivalent through the /usr merge. The operating system ends up executing exactly the same file, simply because the symlink /bin just redirects the invocation to /usr/bin.
|
||||
|
||||
The historical justification for a /bin, /sbin and /lib separate from /usr no longer applies today. ([More on the historical justification for the split](https://lists.busybox.net/pipermail/busybox/2010-December/074114.html), by Rob Landley) They were split off to have selected tools on a faster hard disk (which was small, because it was more expensive) and to contain all the tools necessary to mount the slower /usr partition. Today, a separate /usr partition already must be mounted by the initramfs during early boot, thus making the justification for a split-off moot. In addition a lot of tools in /bin and /sbin in the status quo already lost the ability to run without a pre-mounted /usr. There is no valid reason anymore to have the operating system spread over multiple hierarchies, it lost its purpose.
|
||||
The historical justification for a /bin, /sbin and /lib separate from /usr no longer applies today. ([More on the historical justification for the split](http://lists.busybox.net/pipermail/busybox/2010-December/074114.html), by Rob Landley) They were split off to have selected tools on a faster hard disk (which was small, because it was more expensive) and to contain all the tools necessary to mount the slower /usr partition. Today, a separate /usr partition already must be mounted by the initramfs during early boot, thus making the justification for a split-off moot. In addition a lot of tools in /bin and /sbin in the status quo already lost the ability to run without a pre-mounted /usr. There is no valid reason anymore to have the operating system spread over multiple hierarchies, it lost its purpose.
|
||||
|
||||
Solaris implemented the core part of the /usr merge 15 years ago already, and completed it with the introduction of Solaris 11. Solaris has /bin and /sbin only as symlinks in the root file system, the same way as you will have after the /usr merge: [Transitioning From Oracle Solaris 10 to Oracle Solaris 11 - User Environment Feature Changes](https://docs.oracle.com/cd/E23824_01/html/E24456/userenv-1.html).
|
||||
Solaris implemented the core part of the /usr merge 15 years ago already, and completed it with the introduction of Solaris 11. Solaris has /bin and /sbin only as symlinks in the root file system, the same way as you will have after the /usr merge: [Transitioning From Oracle Solaris 10 to Oracle Solaris 11 - User Environment Feature Changes](http://docs.oracle.com/cd/E23824_01/html/E24456/userenv-1.html).
|
||||
|
||||
Not implementing the /usr merge in your distribution will isolate it from upstream development. It will make porting of packages needlessly difficult, because packagers need to split up installed files into multiple directories and hard code different locations for tools; both will cause unnecessary incompatibilities. Several Linux distributions are agreeing with the benefits of the /usr merge and are already in the process to implement the /usr merge. This means that upstream projects will adapt quickly to the change, those making portability to your distribution harder.
|
||||
|
||||
@ -112,4 +112,4 @@ _With all vendor-supplied OS resources in a single directory /usr they may be sh
|
||||
|
||||
---
|
||||
|
||||
If this page didn't answer your questions you may continue reading [on the Fedora feature page](https://fedoraproject.org/wiki/Features/UsrMove).
|
||||
If this page didn't answer your questions you may continue reading [on the Fedora feature page](https://fedoraproject.org/wiki/Features/UsrMove) and this [mail from Lennart](http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus=155792).
|
||||
|
||||
@ -25,10 +25,10 @@ systemd will measure to PCRs 5 (`boot-loader-config`), 11 (`kernel-boot`),
|
||||
|
||||
Currently, four components will issue TPM2 PCR measurements:
|
||||
|
||||
* The [`systemd-boot`](https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html) boot menu (UEFI)
|
||||
* The [`systemd-stub`](https://www.freedesktop.org/software/systemd/man/latest/systemd-stub.html) boot stub (UEFI)
|
||||
* The [`systemd-pcrextend`](https://www.freedesktop.org/software/systemd/man/latest/systemd-pcrphase.service.html) measurement tool (userspace)
|
||||
* The [`systemd-cryptsetup`](https://www.freedesktop.org/software/systemd/man/latest/systemd-cryptsetup@.service.html) disk encryption tool (userspace)
|
||||
* The [`systemd-boot`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html) boot menu (UEFI)
|
||||
* The [`systemd-stub`](https://www.freedesktop.org/software/systemd/man/systemd-stub.html) boot stub (UEFI)
|
||||
* The [`systemd-pcrextend`](https://www.freedesktop.org/software/systemd/man/systemd-pcrphase.service.html) measurement tool (userspace)
|
||||
* The [`systemd-cryptsetup`](https://www.freedesktop.org/software/systemd/man/systemd-cryptsetup@.service.html) disk encryption tool (userspace)
|
||||
|
||||
A userspace measurement event log in a format close to TCG CEL-JSON is
|
||||
maintained in `/run/log/systemd/tpm2-measure.log`.
|
||||
|
||||
@ -93,7 +93,7 @@ possible.
|
||||
`systemd` defines a number of special UID ranges:
|
||||
|
||||
1. 60001…60513 → UIDs for home directories managed by
|
||||
[`systemd-homed.service(8)`](https://www.freedesktop.org/software/systemd/man/latest/systemd-homed.service.html).
|
||||
[`systemd-homed.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html).
|
||||
UIDs from this range are automatically assigned to any home directory discovered,
|
||||
and persisted locally on first login.
|
||||
On different systems the same user might get different UIDs assigned in case of conflict, though it is
|
||||
@ -113,7 +113,7 @@ possible.
|
||||
|
||||
3. 61184…65519 → UIDs for dynamic users are allocated from this range (see the
|
||||
`DynamicUser=` documentation in
|
||||
[`systemd.exec(5)`](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html)).
|
||||
[`systemd.exec(5)`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html)).
|
||||
This range has been chosen so that it is below the 16-bit boundary
|
||||
(i.e. below 65535), in order to provide compatibility with container environments that
|
||||
assign a 64K range of UIDs to containers using user namespacing.
|
||||
|
||||
@ -8,7 +8,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
# `systemd-homed` and JSON User/Group Record Support in Desktop Environments
|
||||
|
||||
Starting with version 245, systemd supports a new subsystem
|
||||
[`systemd-homed.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-homed.service.html)
|
||||
[`systemd-homed.service`](https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html)
|
||||
for managing regular ("human") users and their home directories.
|
||||
Along with it a new concept `userdb` got merged that brings rich, extensible JSON user/group
|
||||
records, extending the classic UNIX/glibc NSS `struct passwd`/`struct group` structures.
|
||||
@ -60,7 +60,7 @@ A display manager which supports this kind of out-of-context screen lock
|
||||
operation needs to inform systemd-homed about this so that systemd-homed knows
|
||||
that it is safe to suspend the user's home directory on suspend.
|
||||
This is done via the `suspend=` argument to the
|
||||
[`pam_systemd_home`](https://www.freedesktop.org/software/systemd/man/latest/pam_systemd_home.html)
|
||||
[`pam_systemd_home`](https://www.freedesktop.org/software/systemd/man/pam_systemd_home.html)
|
||||
PAM module.
|
||||
A display manager should hence change its PAM stack configurationto set this parameter to on.
|
||||
`systemd-homed` will not suspend home directories if there's at least one active session of the user that does not support
|
||||
|
||||
@ -23,7 +23,7 @@ The concepts described here define an IPC interface.
|
||||
Alternatively, user/group records may be dropped in number of drop-in directories as files where they are
|
||||
picked up in addition to the users/groups defined by this IPC logic.
|
||||
See
|
||||
[`nss-systemd(8)`](https://www.freedesktop.org/software/systemd/man/latest/nss-systemd.html)
|
||||
[`nss-systemd(8)`](https://www.freedesktop.org/software/systemd/man/nss-systemd.html)
|
||||
for details.
|
||||
|
||||
This simple API only exposes only three method calls, and requires only a small
|
||||
@ -150,7 +150,7 @@ synthesize NSS records for users/groups natively defined via a Varlink API.
|
||||
Special care is taken to avoid recursion between these two compatibility mechanisms.
|
||||
|
||||
Subsystems that shall provide user/group records to the system may choose
|
||||
between offering them via an NSS module or via this Varlink API, either way
|
||||
between offering them via an NSS module or via a this Varlink API, either way
|
||||
all records are accessible via both APIs, due to the bidirectional forwarding.
|
||||
It is also possible to provide the same records via both APIs
|
||||
directly, but in that case the compatibility logic must be turned off.
|
||||
|
||||
@ -73,9 +73,9 @@ below implements a deny list of what's not allowed and permits everything else.
|
||||
Strict user/group name syntax is enforced whenever a systemd component is used
|
||||
to register a user or group in the system, for example a system user/group
|
||||
using
|
||||
[`systemd-sysusers.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-sysusers.html)
|
||||
[`systemd-sysusers.service`](https://www.freedesktop.org/software/systemd/man/systemd-sysusers.html)
|
||||
or a regular user with
|
||||
[`systemd-homed.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-homed.html).
|
||||
[`systemd-homed.service`](https://www.freedesktop.org/software/systemd/man/systemd-homed.html).
|
||||
|
||||
In strict mode, only uppercase and lowercase characters are allowed, as well as
|
||||
digits, underscores and hyphens.
|
||||
@ -98,7 +98,7 @@ Written as regular expression the above is: `^[a-zA-Z_][a-zA-Z0-9_-]{0,30}$`
|
||||
Relaxed user/group name syntax is enforced whenever a systemd component accepts
|
||||
and makes use of user/group names registered by other (non-systemd)
|
||||
components of the system, for example in
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-logind.service.html).
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/systemd-logind.html).
|
||||
|
||||
Relaxed syntax is also enforced by the `User=` setting in service unit files,
|
||||
i.e. for system services used for running services.
|
||||
|
||||
@ -13,22 +13,22 @@ pairs, encoded as JSON.
|
||||
|
||||
Specifically:
|
||||
|
||||
1. [`systemd-homed.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-homed.service.html)
|
||||
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) for details).
|
||||
|
||||
2. [`pam_systemd`](https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html)
|
||||
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
|
||||
settings to the activated session, including environment variables, nice
|
||||
levels and more.
|
||||
|
||||
3. [`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-logind.service.html)
|
||||
3. [`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html)
|
||||
processes these JSON records of users that log in, and applies various
|
||||
resource management settings to the per-user slice units it manages.
|
||||
This allows setting global limits on resource consumption by a specific user.
|
||||
|
||||
4. [`nss-systemd`](https://www.freedesktop.org/software/systemd/man/latest/nss-systemd.html)
|
||||
4. [`nss-systemd`](https://www.freedesktop.org/software/systemd/man/nss-systemd.html)
|
||||
is a glibc NSS module that synthesizes classic NSS records from these JSON
|
||||
records, providing full backwards compatibility with the classic UNIX APIs
|
||||
both for look-up and enumeration.
|
||||
@ -37,7 +37,7 @@ Specifically:
|
||||
effect of `DynamicUser=` in service unit files) as these advanced JSON
|
||||
records, making them discoverable to the rest of the system.
|
||||
|
||||
6. [`systemd-userdbd.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-userdbd.service.html)
|
||||
6. [`systemd-userdbd.service`](https://www.freedesktop.org/software/systemd/man/systemd-userdbd.service.html)
|
||||
is a small service that can translate UNIX/glibc NSS records to these JSON user records.
|
||||
It also provides a unified [Varlink](https://varlink.org/) API for querying and enumerating records of this type,
|
||||
optionally acquiring them from various other services.
|
||||
@ -82,7 +82,7 @@ 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). 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/latest/nss-systemd.html)
|
||||
[`nss-systemd(8)`](https://www.freedesktop.org/software/systemd/man/nss-systemd.html)
|
||||
for details.
|
||||
|
||||
## Why JSON?
|
||||
@ -260,7 +260,7 @@ This field must not contain control characters (such as `\n`) or colons (`:`), s
|
||||
as record separators in classic `/etc/passwd` files and similar formats.
|
||||
|
||||
`emailAddress` → The email address of the user, formatted as string.
|
||||
[`pam_systemd`](https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html)
|
||||
[`pam_systemd`](https://www.freedesktop.org/software/systemd/man/pam_systemd.html)
|
||||
initializes the `$EMAIL` environment variable from this value for all login
|
||||
sessions.
|
||||
|
||||
@ -310,19 +310,19 @@ Takes an integer. Note that usually on UNIX the umask is noted in octal, but JSO
|
||||
integers are generally written in decimal, hence in this context we denote it umask in decimal too.
|
||||
The specified value should be in the valid range for umasks, i.e. 0000…0777 (in octal as typical in UNIX), or 0…511 (in decimal, how
|
||||
it actually appears in the JSON record).
|
||||
This `umask` is automatically set by [`pam_systemd`](https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html)
|
||||
This `umask` is automatically set by [`pam_systemd`](https://www.freedesktop.org/software/systemd/man/pam_systemd.html)
|
||||
for all login sessions of the user.
|
||||
|
||||
`environment` → An array of strings, each containing an environment variable
|
||||
and its value to set for the user's login session, in a format compatible with
|
||||
[`putenv()`](https://man7.org/linux/man-pages/man3/putenv.3.html). Any
|
||||
environment variable listed here is automatically set by
|
||||
[`pam_systemd`](https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html)
|
||||
[`pam_systemd`](https://www.freedesktop.org/software/systemd/man/pam_systemd.html)
|
||||
for all login sessions of the user.
|
||||
|
||||
`timeZone` → A string indicating a preferred timezone to use for the user. When
|
||||
logging in
|
||||
[`pam_systemd`](https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html)
|
||||
[`pam_systemd`](https://www.freedesktop.org/software/systemd/man/pam_systemd.html)
|
||||
will automatically initialize the `$TZ` environment variable from this
|
||||
string.
|
||||
The string should be a `tzdata` compatible location string, for example: `Europe/Berlin`.
|
||||
@ -340,13 +340,13 @@ specify all the languages that they know, so software lacking translations in th
|
||||
primary language can try another language that the user knows rather than falling back to
|
||||
the default English. All entries in this field must be valid locale names, compatible with
|
||||
the `$LANG` variable, for example: `de_DE.UTF-8`. When logging in
|
||||
[`pam_systemd`](https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html)
|
||||
[`pam_systemd`](https://www.freedesktop.org/software/systemd/man/pam_systemd.html)
|
||||
will prepend `preferredLanguage` (if set) to this list (if set), remove duplicates,
|
||||
and then automatically initialize the `$LANGUAGE` variable with the resulting list.
|
||||
It will also initialize `$LANG` variable with the first entry in the resulting list.
|
||||
|
||||
`niceLevel` → An integer value in the range -20…19. When logging in
|
||||
[`pam_systemd`](https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html)
|
||||
[`pam_systemd`](https://www.freedesktop.org/software/systemd/man/pam_systemd.html)
|
||||
will automatically initialize the login process' nice level to this value with,
|
||||
which is then inherited by all the user's processes, see
|
||||
[`setpriority()`](https://man7.org/linux/man-pages/man2/setpriority.2.html) for
|
||||
@ -356,7 +356,7 @@ more information.
|
||||
(such as `RLIMIT_NOFILE` and similar).
|
||||
Their values should be an object with two keys `cur` and `max` for the soft and hard resource limit.
|
||||
When logging in
|
||||
[`pam_systemd`](https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html)
|
||||
[`pam_systemd`](https://www.freedesktop.org/software/systemd/man/pam_systemd.html)
|
||||
will automatically initialize the login process' resource limits to these
|
||||
values, which is then inherited by all the user's processes, see
|
||||
[`setrlimit()`](https://man7.org/linux/man-pages/man2/setrlimit.2.html) for more
|
||||
@ -408,7 +408,7 @@ access mask for the home directory when it is first created.
|
||||
tasks the user may start in parallel during system runtime.
|
||||
This counts all tasks (i.e. threads, where each process is at least one thread) the user starts or that are
|
||||
forked from these processes even if the user identity is changed (for example by setuid binaries/`su`/`sudo` and similar).
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-logind.service.html)
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html)
|
||||
enforces this by setting the `TasksMax` slice property for the user's slice
|
||||
`user-$UID.slice`.
|
||||
|
||||
@ -416,14 +416,14 @@ enforces this by setting the `TasksMax` slice property for the user's slice
|
||||
memory limits for all processes of the user (plus all processes forked off them
|
||||
that might have changed user identity),
|
||||
in bytes. Enforced by
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-logind.service.html),
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html),
|
||||
similar to `tasksMax`.
|
||||
|
||||
`cpuWeight`/`ioWeight` → These take unsigned integers in the range 1…10000
|
||||
(defaults to 100) and configure the CPU and IO scheduling weights for the
|
||||
user's processes as a whole.
|
||||
Also enforced by
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-logind.service.html),
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html),
|
||||
similar to `tasksMax`, `memoryHigh` and `memoryMax`.
|
||||
|
||||
`mountNoDevices`/`mountNoSuid`/`mountNoExecute` → Three booleans that control
|
||||
@ -574,7 +574,7 @@ display manager to pre-select the correct environment to launch when the user lo
|
||||
`stopDelayUSec` → An unsigned 64-bit integer, indicating the time in µs the
|
||||
per-user service manager is kept around after the user fully logged out. This
|
||||
value is honored by
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-logind.service.html). If
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html). If
|
||||
set to zero the per-user service manager is immediately terminated when the
|
||||
user logs out, and longer values optimize high-frequency log-ins as the
|
||||
necessary work to set up and tear down a log-in is reduced if the service manager stays running.
|
||||
@ -582,7 +582,7 @@ necessary work to set up and tear down a log-in is reduced if the service manage
|
||||
`killProcesses` → A boolean.
|
||||
If true all processes of the user are automatically killed when the user logs out.
|
||||
This is enforced by
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/latest/systemd-logind.service.html).
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html).
|
||||
If false any processes left around when the user logs out are left running.
|
||||
|
||||
`passwordChangeMinUSec`/`passwordChangeMaxUSec` → An unsigned 64-bit integer,
|
||||
|
||||
@ -15,11 +15,11 @@ This provides a number of new features, but also requires updating of the Deskto
|
||||
This document should be read together with [Writing Display Managers](/WRITING_DISPLAY_MANAGERS) which focuses on the porting work necessary for display managers.
|
||||
|
||||
If required it is possible to implement ConsoleKit and systemd-logind support in the same desktop environment code, detecting at runtime which interface is needed.
|
||||
The [sd_booted()](https://www.freedesktop.org/software/systemd/man/latest/sd_booted.html) call may be used to determine at runtime whether systemd is used.
|
||||
The [sd_booted()](http://www.freedesktop.org/software/systemd/man/sd_booted.html) call may be used to determine at runtime whether systemd is used.
|
||||
|
||||
To a certain level ConsoleKit and systemd-logind may be used side-by-side, but a number of features are not available if ConsoleKit is used.
|
||||
|
||||
Please have a look at the [Bus API of logind](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.login1.html) and the C API as documented in [sd-login(7)](https://www.freedesktop.org/software/systemd/man/latest/sd-login.html). (Also see below)
|
||||
Please have a look at the [Bus API of logind](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.login1.html) and the C API as documented in [sd-login(7)](http://www.freedesktop.org/software/systemd/man/sd-login.html). (Also see below)
|
||||
|
||||
Here are the suggested changes:
|
||||
|
||||
@ -44,6 +44,6 @@ Here are the suggested changes:
|
||||
Use logind's ListInhibitors() call to get a list of these inhibitors. See [Inhibitor Locks](/INHIBITOR_LOCKS) for further details on this.
|
||||
- If your DE contains a process viewer of some kind ("system monitor") it's a good idea to show session, service and seat information for each process.
|
||||
Use sd_pid_get_session(), sd_pid_get_unit(), sd_session_get_seat() to determine these.
|
||||
For details see [sd-login(7)](https://www.freedesktop.org/software/systemd/man/latest/sd-login.html).
|
||||
For details see [sd-login(7)](http://www.freedesktop.org/software/systemd/man/sd-login.html).
|
||||
|
||||
And that's all! Thank you!
|
||||
|
||||
@ -16,11 +16,11 @@ true automatic multi-seat support, proper tracking of session processes, (option
|
||||
This document should be read together with [Writing Desktop Environments](/WRITING_DESKTOP_ENVIRONMENTS) which focuses on the porting work necessary for desktop environments.
|
||||
|
||||
If required it is possible to implement ConsoleKit and systemd-logind support in the same display manager, detecting at runtime which interface is needed.
|
||||
The [sd_booted()](https://www.freedesktop.org/software/systemd/man/latest/sd_booted.html) call may be used to determine at runtime whether systemd is used.
|
||||
The [sd_booted()](http://www.freedesktop.org/software/systemd/man/sd_booted.html) call may be used to determine at runtime whether systemd is used.
|
||||
|
||||
To a certain level ConsoleKit and systemd-logind may be used side-by-side, but a number of features are not available if ConsoleKit is used, for example automatic multi-seat support.
|
||||
|
||||
Please have a look at the [Bus API of logind](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.login1.html) and the C API as documented in [sd-login(7)](https://www.freedesktop.org/software/systemd/man/latest/sd-login.html).
|
||||
Please have a look at the [Bus API of logind](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.login1.html) and the C API as documented in [sd-login(7)](http://www.freedesktop.org/software/systemd/man/sd-login.html).
|
||||
(Also see below)
|
||||
|
||||
Minimal porting (without multi-seat) requires the following:
|
||||
@ -51,7 +51,7 @@ In summary: porting a display manager from ConsoleKit to systemd primarily means
|
||||
And that's already it.
|
||||
|
||||
While most information about seats, sessions and users is available on systemd-logind's D-Bus interface, this is not the only API.
|
||||
The synchronous [sd-login(7)](https://www.freedesktop.org/software/systemd/man/latest/sd-login.html) C interface is often easier to use and much faster too.
|
||||
The synchronous [sd-login(7)](http://www.freedesktop.org/software/systemd/man/sd-login.html) C interface is often easier to use and much faster too.
|
||||
In fact it is possible to implement the scheme above entirely without D-Bus relying only on this API.
|
||||
Note however, that this C API is purely passive, and if you want to execute an actually state changing operation you need to use the bus interface (for example, to switch sessions, or to kill sessions and suchlike).
|
||||
Also have a look at the [logind Bus API](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.login1.html).
|
||||
|
||||
@ -42,22 +42,22 @@
|
||||
{
|
||||
"category": "Manual Pages",
|
||||
"title": "Index",
|
||||
"url": "https://www.freedesktop.org/software/systemd/man/latest/"
|
||||
"url": "https://www.freedesktop.org/software/systemd/man/"
|
||||
},
|
||||
{
|
||||
"category": "Manual Pages",
|
||||
"title": "Directives",
|
||||
"url": "https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html"
|
||||
"url": "https://www.freedesktop.org/software/systemd/man/systemd.directives.html"
|
||||
},
|
||||
{
|
||||
"category": "Publications",
|
||||
"title": "Article in The H",
|
||||
"url": "https://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html"
|
||||
"url": "http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html"
|
||||
},
|
||||
{
|
||||
"category": "Publications",
|
||||
"title": "Article in The H, Part 2",
|
||||
"url": "https://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html"
|
||||
"url": "http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html"
|
||||
},
|
||||
{
|
||||
"category": "Publications",
|
||||
@ -157,7 +157,7 @@
|
||||
{
|
||||
"category": "Videos for Users and Administrators",
|
||||
"title": "Presentation about systemd at linux.conf.au 2011",
|
||||
"url": "https://www.youtube.com/watch?v=9XRj8ii91D0"
|
||||
"url": "http://linuxconfau.blip.tv/file/4696791/"
|
||||
},
|
||||
{
|
||||
"category": "Videos for Users and Administrators",
|
||||
@ -289,6 +289,11 @@
|
||||
"title": "A more complete Russian translation (PDF)",
|
||||
"url": "http://www2.kangran.su/~nnz/pub/s4a/s4a_latest.pdf"
|
||||
},
|
||||
{
|
||||
"category": "The systemd for Administrators Blog Series",
|
||||
"title": "A Vietnamese translation",
|
||||
"url": "https://archlinuxvn.org/doc/systemd/#lp"
|
||||
},
|
||||
{
|
||||
"category": "The systemd for Developers Series",
|
||||
"title": "#1: Socket Activation",
|
||||
@ -402,12 +407,12 @@
|
||||
{
|
||||
"category": "Documentation for Developers - external links",
|
||||
"title": "The 30 Biggest Myths about systemd",
|
||||
"url": "https://0pointer.de/blog/projects/the-biggest-myths.html"
|
||||
"url": "http://0pointer.de/blog/projects/the-biggest-myths.html"
|
||||
},
|
||||
{
|
||||
"category": "Documentation for Developers - external links",
|
||||
"title": "Introduction to systemd in French",
|
||||
"url": "https://lea-linux.org/documentations/Systemd"
|
||||
"url": "http://lea-linux.org/documentations/Systemd"
|
||||
},
|
||||
{
|
||||
"category": "The various distributions",
|
||||
@ -432,12 +437,12 @@
|
||||
{
|
||||
"category": "The various distributions",
|
||||
"title": "openSUSE instructions",
|
||||
"url": "https://en.opensuse.org/SDB:Systemd"
|
||||
"url": "http://en.opensuse.org/SDB:Systemd"
|
||||
},
|
||||
{
|
||||
"category": "The various distributions",
|
||||
"title": "openSUSE bugtracker",
|
||||
"url": "https://bugzilla.opensuse.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=REOPENED&classification=openSUSE&field0-0-0=product&field0-0-1=component&field0-0-2=short_desc&field0-0-3=status_whiteboard&known_name=systemd&query_based_on=systemd&query_format=advanced&short_desc=systemd&short_desc_type=allwordssubstr&type0-0-0=substring&type0-0-1=substring&type0-0-2=substring&type0-0-3=substring&value0-0-0=systemd&value0-0-1=systemd&value0-0-2=systemd&value0-0-3=systemd"
|
||||
"url": "https://bugzilla.novell.com/buglist.cgi?short_desc=systemd&field0-0-0=product&type0-0-1=substring&field0-0-1=component&classification=openSUSE&value0-0-2=systemd&query_based_on=systemd&query_format=advanced&type0-0-3=substring&field0-0-3=status_whiteboard&value0-0-3=systemd&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=REOPENED&short_desc_type=allwordssubstr&field0-0-2=short_desc&value0-0-1=systemd&type0-0-0=substring&value0-0-0=systemd&type0-0-2=substring&known_name=systemd"
|
||||
},
|
||||
{
|
||||
"category": "The various distributions",
|
||||
@ -457,17 +462,17 @@
|
||||
{
|
||||
"category": "The various distributions",
|
||||
"title": "Debian packages",
|
||||
"url": "https://packages.debian.org/systemd"
|
||||
"url": "http://packages.debian.org/systemd"
|
||||
},
|
||||
{
|
||||
"category": "The various distributions",
|
||||
"title": "Debian wiki",
|
||||
"url": "https://wiki.debian.org/systemd"
|
||||
"url": "http://wiki.debian.org/systemd"
|
||||
},
|
||||
{
|
||||
"category": "The various distributions",
|
||||
"title": "Debian bugtracker",
|
||||
"url": "https://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;src=systemd"
|
||||
"url": "http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;src=systemd"
|
||||
},
|
||||
{
|
||||
"category": "The various distributions",
|
||||
@ -481,8 +486,8 @@
|
||||
},
|
||||
{
|
||||
"category": "The various distributions",
|
||||
"title": "Mageia wiki",
|
||||
"url": "https://wiki.mageia.org/en/Features/Systemd"
|
||||
"title": "Mageia packages",
|
||||
"url": "http://svnweb.mageia.org/packages/cauldron/systemd/current/"
|
||||
},
|
||||
{
|
||||
"category": "The various distributions",
|
||||
@ -492,12 +497,12 @@
|
||||
{
|
||||
"category": "The various distributions",
|
||||
"title": "Gentoo packages",
|
||||
"url": "https://packages.gentoo.org/package/sys-apps/systemd"
|
||||
"url": "http://packages.gentoo.org/package/sys-apps/systemd"
|
||||
},
|
||||
{
|
||||
"category": "The various distributions",
|
||||
"title": "Gentoo wiki",
|
||||
"url": "https://wiki.gentoo.org/wiki/Systemd"
|
||||
"url": "http://wiki.gentoo.org/wiki/Systemd"
|
||||
},
|
||||
{
|
||||
"category": "The various distributions",
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<svg xmlns="https://www.w3.org/2000/svg" width="202" height="26" viewBox="0 0 202 26" id="systemd-logo">
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="202" height="26" viewBox="0 0 202 26" id="systemd-logo">
|
||||
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
||||
<path d="M0 0v26h10v-4H4V4h6V0zm76 0v4h6v18h-6v4h10V0z" fill="currentColor"/>
|
||||
<path d="M113.498 14.926q-4.5-.96-4.5-3.878 0-1.079.609-1.981.621-.902 1.781-1.441 1.16-.54 2.707-.54 1.63 0 2.848.528 1.219.516 1.875 1.453.656.926.656 2.121h-3.539q0-.762-.457-1.183-.457-.434-1.394-.434-.774 0-1.243.363-.457.364-.457.938 0 .55.516.89.527.34 1.781.575 1.5.28 2.543.738 1.043.445 1.653 1.242.62.797.62 2.027 0 1.114-.667 2.004-.657.88-1.887 1.383-1.219.504-2.836.504-1.711 0-2.965-.621-1.242-.633-1.898-1.617-.645-.985-.645-2.051h3.34q.036.914.656 1.36.621.433 1.594.433.902 0 1.383-.34.492-.351.492-.937 0-.364-.223-.61-.21-.258-.773-.48-.55-.223-1.57-.446zm19.384-7.606l-5.086 14.58q-.293.831-.726 1.523-.434.703-1.266 1.195-.832.504-2.098.504-.457 0-.75-.048-.281-.046-.785-.176v-2.672q.176.02.527.02.95 0 1.418-.293.47-.293.715-.961l.352-.926-4.43-12.738h3.797l2.262 7.687 2.285-7.687zm5.884 7.606q-4.5-.96-4.5-3.878 0-1.079.61-1.981.62-.902 1.781-1.441 1.16-.54 2.707-.54 1.629 0 2.848.528 1.218.516 1.875 1.453.656.926.656 2.121h-3.539q0-.762-.457-1.183-.457-.434-1.395-.434-.773 0-1.242.363-.457.364-.457.938 0 .55.516.89.527.34 1.781.575 1.5.28 2.543.738 1.043.445 1.652 1.242.621.797.621 2.027 0 1.114-.668 2.004-.656.88-1.886 1.383-1.219.504-2.836.504-1.711 0-2.965-.621-1.242-.633-1.899-1.617-.644-.985-.644-2.051h3.34q.036.914.656 1.36.621.433 1.594.433.902 0 1.383-.34.492-.351.492-.937 0-.364-.223-.61-.21-.258-.773-.48-.551-.223-1.57-.446zm13.983 2.403q.574 0 .984-.082v2.66q-.914.328-2.086.328-3.727 0-3.727-3.797V9.899h-1.793V7.321h1.793v-3.14h3.54v3.14h2.132v2.578h-2.133v6.129q0 .75.293 1.031.293.27.997.27zm14.228-2.519h-8.016q.2 1.183.985 1.886.785.691 2.015.691.914 0 1.688-.34.785-.351 1.336-1.042l1.699 1.957q-.668.96-1.957 1.617-1.278.656-3 .656-1.946 0-3.387-.82-1.43-.82-2.203-2.227-.762-1.406-.762-3.105v-.446q0-1.898.715-3.386.715-1.489 2.063-2.32 1.347-.844 3.187-.844 1.793 0 3.059.761 1.265.762 1.922 2.168.656 1.395.656 3.293zm-3.469-2.65q-.024-1.03-.574-1.628-.54-.598-1.617-.598-1.008 0-1.582.668-.563.668-.739 1.84h4.512zm19.923-5.073q1.934 0 2.989 1.148 1.054 1.148 1.054 3.727v8.039h-3.539V11.95q0-.797-.21-1.23-.212-.446-.61-.61-.387-.164-.984-.164-.715 0-1.219.352-.504.34-.797.972.02.082.02.27V20h-3.54v-8.015q0-.797-.21-1.242-.211-.445-.61-.621-.386-.176-.996-.176-.68 0-1.183.304-.492.293-.797.844V20h-3.539V7.32h3.316l.118 1.419q.633-.797 1.547-1.22.926-.433 2.086-.433 1.172 0 2.016.48.855.47 1.312 1.442.633-.926 1.582-1.418.961-.504 2.203-.504zM201.398 2v18h-3.187l-.176-1.359q-1.243 1.594-3.212 1.594-1.535 0-2.66-.82-1.113-.832-1.699-2.285-.574-1.454-.574-3.317v-.246q0-1.934.574-3.398.586-1.465 1.7-2.274 1.124-.808 2.683-.808 1.805 0 3.012 1.37V2.001zm-5.672 15.376q1.488 0 2.133-1.266v-4.898q-.61-1.266-2.11-1.266-1.207 0-1.77.984-.55.985-.55 2.637v.246q0 1.629.54 2.602.55.96 1.757.96z" fill="currentColor"/>
|
||||
|
||||
|
Before Width: | Height: | Size: 3.1 KiB After Width: | Height: | Size: 3.1 KiB |
@ -1,4 +1,4 @@
|
||||
<svg xmlns="https://www.w3.org/2000/svg" width="16" height="16">
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
|
||||
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
||||
<g transform="translate(380 -506.52)">
|
||||
<rect ry="16.875" rx="16.875" y="2409.281" x="4128.568" height="90" width="90" fill="#201a26" transform="matrix(.17778 0 0 .17778 -1113.968 78.203)" stroke-width="5.625"/>
|
||||
|
||||
|
Before Width: | Height: | Size: 653 B After Width: | Height: | Size: 652 B |
|
Before Width: | Height: | Size: 61 KiB After Width: | Height: | Size: 61 KiB |
@ -1,851 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
width="316.28293mm"
|
||||
height="306.23108mm"
|
||||
viewBox="0 0 316.28293 306.23108"
|
||||
version="1.1"
|
||||
id="svg1"
|
||||
inkscape:version="1.4.2 (ebf0e940d0, 2025-05-08)"
|
||||
sodipodi:docname="drawing.svg"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<sodipodi:namedview
|
||||
id="namedview1"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:showpageshadow="2"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pagecheckerboard="0"
|
||||
inkscape:deskcolor="#d1d1d1"
|
||||
inkscape:document-units="mm"
|
||||
inkscape:zoom="0.74118967"
|
||||
inkscape:cx="540.34752"
|
||||
inkscape:cy="712.36826"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1043"
|
||||
inkscape:window-x="0"
|
||||
inkscape:window-y="0"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="layer1" />
|
||||
<defs
|
||||
id="defs1">
|
||||
<marker
|
||||
style="overflow:visible"
|
||||
id="marker10"
|
||||
refX="0"
|
||||
refY="0"
|
||||
orient="auto-start-reverse"
|
||||
inkscape:stockid="Triangle arrow"
|
||||
markerWidth="3"
|
||||
markerHeight="3"
|
||||
viewBox="0 0 1 1"
|
||||
inkscape:isstock="true"
|
||||
inkscape:collect="always"
|
||||
preserveAspectRatio="xMidYMid">
|
||||
<path
|
||||
transform="scale(0.5)"
|
||||
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
|
||||
d="M 5.77,0 -2.88,5 V -5 Z"
|
||||
id="path10" />
|
||||
</marker>
|
||||
<marker
|
||||
style="overflow:visible"
|
||||
id="Triangle"
|
||||
refX="0"
|
||||
refY="0"
|
||||
orient="auto-start-reverse"
|
||||
inkscape:stockid="Triangle arrow"
|
||||
markerWidth="3"
|
||||
markerHeight="3"
|
||||
viewBox="0 0 1 1"
|
||||
inkscape:isstock="true"
|
||||
inkscape:collect="always"
|
||||
preserveAspectRatio="xMidYMid">
|
||||
<path
|
||||
transform="scale(0.5)"
|
||||
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
|
||||
d="M 5.77,0 -2.88,5 V -5 Z"
|
||||
id="path135" />
|
||||
</marker>
|
||||
<marker
|
||||
style="overflow:visible"
|
||||
id="Triangle-8"
|
||||
refX="0"
|
||||
refY="0"
|
||||
orient="auto-start-reverse"
|
||||
inkscape:stockid="Triangle arrow"
|
||||
markerWidth="3"
|
||||
markerHeight="3"
|
||||
viewBox="0 0 1 1"
|
||||
inkscape:isstock="true"
|
||||
inkscape:collect="always"
|
||||
preserveAspectRatio="xMidYMid">
|
||||
<path
|
||||
transform="scale(0.5)"
|
||||
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
|
||||
d="M 5.77,0 -2.88,5 V -5 Z"
|
||||
id="path135-9" />
|
||||
</marker>
|
||||
<marker
|
||||
style="overflow:visible"
|
||||
id="marker10-2"
|
||||
refX="0"
|
||||
refY="0"
|
||||
orient="auto-start-reverse"
|
||||
inkscape:stockid="Triangle arrow"
|
||||
markerWidth="3"
|
||||
markerHeight="3"
|
||||
viewBox="0 0 1 1"
|
||||
inkscape:isstock="true"
|
||||
inkscape:collect="always"
|
||||
preserveAspectRatio="xMidYMid">
|
||||
<path
|
||||
transform="scale(0.5)"
|
||||
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
|
||||
d="M 5.77,0 -2.88,5 V -5 Z"
|
||||
id="path10-6" />
|
||||
</marker>
|
||||
<marker
|
||||
style="overflow:visible"
|
||||
id="Triangle-8-6"
|
||||
refX="0"
|
||||
refY="0"
|
||||
orient="auto-start-reverse"
|
||||
inkscape:stockid="Triangle arrow"
|
||||
markerWidth="3"
|
||||
markerHeight="3"
|
||||
viewBox="0 0 1 1"
|
||||
inkscape:isstock="true"
|
||||
inkscape:collect="always"
|
||||
preserveAspectRatio="xMidYMid">
|
||||
<path
|
||||
transform="scale(0.5)"
|
||||
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
|
||||
d="M 5.77,0 -2.88,5 V -5 Z"
|
||||
id="path135-9-3" />
|
||||
</marker>
|
||||
<marker
|
||||
style="overflow:visible"
|
||||
id="marker10-2-1"
|
||||
refX="0"
|
||||
refY="0"
|
||||
orient="auto-start-reverse"
|
||||
inkscape:stockid="Triangle arrow"
|
||||
markerWidth="3"
|
||||
markerHeight="3"
|
||||
viewBox="0 0 1 1"
|
||||
inkscape:isstock="true"
|
||||
inkscape:collect="always"
|
||||
preserveAspectRatio="xMidYMid">
|
||||
<path
|
||||
transform="scale(0.5)"
|
||||
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
|
||||
d="M 5.77,0 -2.88,5 V -5 Z"
|
||||
id="path10-6-7" />
|
||||
</marker>
|
||||
</defs>
|
||||
<g
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(-6.3824526,-3.5266833)">
|
||||
<rect
|
||||
style="fill:#008075;fill-opacity:1;stroke:#0d64b5;stroke-width:0.799999;stroke-opacity:1"
|
||||
id="rect3"
|
||||
width="131.36539"
|
||||
height="128.86658"
|
||||
x="6.7824521"
|
||||
y="61.045975"
|
||||
rx="5.0009999"
|
||||
ry="5" />
|
||||
<g
|
||||
id="g2">
|
||||
<g
|
||||
id="g1">
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="15.773956"
|
||||
y="100.73308"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="64.392487"
|
||||
y="110.51707"
|
||||
id="text1"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan1"
|
||||
style="stroke-width:0.264583"
|
||||
x="64.392487"
|
||||
y="110.51707">Instance</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="113.87379"
|
||||
y="110.50744"
|
||||
id="text2"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan2"
|
||||
style="stroke-width:0.264583"
|
||||
x="113.87379"
|
||||
y="110.50744">pattern</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
id="g2-3"
|
||||
transform="translate(0,17.732698)">
|
||||
<g
|
||||
id="g1-5">
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-6"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="15.773956"
|
||||
y="100.73308"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="64.392487"
|
||||
y="110.51707"
|
||||
id="text1-2"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan1-9"
|
||||
style="stroke-width:0.264583"
|
||||
x="64.392487"
|
||||
y="110.51707">Instance</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="113.87379"
|
||||
y="110.50744"
|
||||
id="text2-1"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan2-2"
|
||||
style="stroke-width:0.264583"
|
||||
x="113.87379"
|
||||
y="110.50744">pattern</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
id="g3">
|
||||
<g
|
||||
id="g1-0"
|
||||
transform="translate(0,35.465397)">
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-62"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="15.773956"
|
||||
y="100.73308"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="64.392487"
|
||||
y="110.51707"
|
||||
id="text1-6"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan1-1"
|
||||
style="stroke-width:0.264583"
|
||||
x="64.392487"
|
||||
y="110.51707">Instance</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="113.87379"
|
||||
y="145.97284"
|
||||
id="text2-8"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan2-7"
|
||||
style="stroke-width:0.264583"
|
||||
x="113.87379"
|
||||
y="145.97284">pattern</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="47.416828"
|
||||
y="162.0649"
|
||||
id="text3"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3"
|
||||
style="stroke-width:0.264583"
|
||||
x="47.416828"
|
||||
y="162.0649">⋮</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="59.971153"
|
||||
y="74.610878"
|
||||
id="text4"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4"
|
||||
style="stroke-width:0.264583"
|
||||
x="59.971153"
|
||||
y="74.610878">Resource</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:6.35px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="118.45662"
|
||||
y="86.030052"
|
||||
id="text5"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan5"
|
||||
style="font-size:6.35px;stroke-width:0.264583"
|
||||
x="118.45662"
|
||||
y="86.030052">Partially loaded from .transfer file</tspan></text>
|
||||
<g
|
||||
id="g5"
|
||||
transform="translate(0,-16.876938)">
|
||||
<rect
|
||||
style="fill:#008075;fill-opacity:1;stroke:#0d64b5;stroke-width:0.799999;stroke-opacity:1"
|
||||
id="rect3-3"
|
||||
width="131.36539"
|
||||
height="128.86658"
|
||||
x="190.90001"
|
||||
y="77.922913"
|
||||
rx="5.0009999"
|
||||
ry="5" />
|
||||
<g
|
||||
id="g2-7"
|
||||
transform="translate(184.11755,16.87694)">
|
||||
<g
|
||||
id="g1-59">
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-2"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="15.773956"
|
||||
y="100.73308"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="64.392487"
|
||||
y="110.51707"
|
||||
id="text1-28"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan1-97"
|
||||
style="stroke-width:0.264583"
|
||||
x="64.392487"
|
||||
y="110.51707">Instance</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="113.87379"
|
||||
y="110.50744"
|
||||
id="text2-3"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan2-6"
|
||||
style="stroke-width:0.264583"
|
||||
x="113.87379"
|
||||
y="110.50744">pattern</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
id="g2-3-1"
|
||||
transform="translate(184.11755,34.609638)">
|
||||
<g
|
||||
id="g1-5-2">
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-6-9"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="15.773956"
|
||||
y="100.73308"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="64.392487"
|
||||
y="110.51707"
|
||||
id="text1-2-3"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan1-9-1"
|
||||
style="stroke-width:0.264583"
|
||||
x="64.392487"
|
||||
y="110.51707">Instance</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="113.87379"
|
||||
y="110.50744"
|
||||
id="text2-1-9"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan2-2-4"
|
||||
style="stroke-width:0.264583"
|
||||
x="113.87379"
|
||||
y="110.50744">pattern</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
id="g3-7"
|
||||
transform="translate(184.11755,16.87694)">
|
||||
<g
|
||||
id="g1-0-8"
|
||||
transform="translate(0,35.465397)">
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-62-4"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="15.773956"
|
||||
y="100.73308"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="64.392487"
|
||||
y="110.51707"
|
||||
id="text1-6-5"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan1-1-0"
|
||||
style="stroke-width:0.264583"
|
||||
x="64.392487"
|
||||
y="110.51707">Instance</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="113.87379"
|
||||
y="145.97284"
|
||||
id="text2-8-3"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan2-7-6"
|
||||
style="stroke-width:0.264583"
|
||||
x="113.87379"
|
||||
y="145.97284">pattern</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="231.53438"
|
||||
y="178.94183"
|
||||
id="text3-1"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3-0"
|
||||
style="stroke-width:0.264583"
|
||||
x="231.53438"
|
||||
y="178.94183">⋮</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="244.0887"
|
||||
y="91.487816"
|
||||
id="text4-6"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4-3"
|
||||
style="stroke-width:0.264583"
|
||||
x="244.0887"
|
||||
y="91.487816">Resource</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:6.35px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="302.57416"
|
||||
y="102.90699"
|
||||
id="text5-2"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan5-0"
|
||||
style="font-size:6.35px;stroke-width:0.264583"
|
||||
x="302.57416"
|
||||
y="102.90699">Partially loaded from .transfer file</tspan></text>
|
||||
</g>
|
||||
<rect
|
||||
style="fill:#ff7f2a;fill-opacity:1;stroke:#b56f0d;stroke-width:0.880404;stroke-opacity:1"
|
||||
id="rect6"
|
||||
width="111.65157"
|
||||
height="42.399162"
|
||||
x="6.8226547"
|
||||
y="3.9668853"
|
||||
rx="4.9974012"
|
||||
ry="6.0599365" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:6.35px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="92.622543"
|
||||
y="28.901594"
|
||||
id="text5-8"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan5-8"
|
||||
style="font-size:6.35px;stroke-width:0.264583"
|
||||
x="92.622543"
|
||||
y="28.901594">Loaded from .transfer file</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="55.061909"
|
||||
y="16.949841"
|
||||
id="text6"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan6"
|
||||
style="stroke-width:0.264583"
|
||||
x="55.061913"
|
||||
y="16.949841">Transfer</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7.76111px;line-height:1.25;font-family:monospace;-inkscape-font-specification:monospace;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="39.600597"
|
||||
y="41.837189"
|
||||
id="text7"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan7"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7.76111px;font-family:monospace;-inkscape-font-specification:monospace;stroke-width:0.264583"
|
||||
x="39.600597"
|
||||
y="41.837189">source</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7.76111px;line-height:1.25;font-family:monospace;-inkscape-font-specification:monospace;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="113.82346"
|
||||
y="41.837189"
|
||||
id="text8"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan8"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7.76111px;font-family:monospace;-inkscape-font-specification:monospace;stroke-width:0.264583"
|
||||
x="113.82346"
|
||||
y="41.837189">target</tspan></text>
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Triangle)"
|
||||
d="m 27.129808,44.621394 -0.356973,18.91947"
|
||||
id="path8"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker10)"
|
||||
d="m 116.01562,40.337739 75.67789,23.203125"
|
||||
id="path9"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<g
|
||||
id="g16"
|
||||
transform="translate(-194.19231,210.25601)">
|
||||
<rect
|
||||
style="fill:#55d400;fill-opacity:1;stroke:#58b50d;stroke-width:1.12104;stroke-opacity:1"
|
||||
id="rect10"
|
||||
width="121.40612"
|
||||
height="78.56958"
|
||||
x="217.91293"
|
||||
y="4.087204"
|
||||
rx="5.8448224"
|
||||
ry="8.4007883" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:6.35px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:start;letter-spacing:0px;word-spacing:0px;text-anchor:start;stroke-width:0.264583"
|
||||
x="222.03329"
|
||||
y="28.901594"
|
||||
id="text5-8-9"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan5-8-2"
|
||||
style="font-size:6.35px;text-align:start;text-anchor:start;stroke-width:0.264583"
|
||||
x="222.03329"
|
||||
y="28.901594">Set of Instances taken from across</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
style="font-size:6.35px;text-align:start;text-anchor:start;stroke-width:0.264583"
|
||||
x="222.03329"
|
||||
y="36.839092"
|
||||
id="tspan11">all Transfers, matching a certain</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
style="font-size:6.35px;text-align:start;text-anchor:start;stroke-width:0.264583"
|
||||
x="222.03329"
|
||||
y="44.776592"
|
||||
id="tspan12">version; either all source Instances</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
style="font-size:6.35px;text-align:start;text-anchor:start;stroke-width:0.264583"
|
||||
x="222.03329"
|
||||
y="52.714092"
|
||||
id="tspan13">or all target Instances.</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
style="font-size:6.35px;text-align:start;text-anchor:start;stroke-width:0.264583"
|
||||
x="222.03329"
|
||||
y="60.651592"
|
||||
id="tspan14" /><tspan
|
||||
sodipodi:role="line"
|
||||
style="font-size:6.35px;text-align:start;text-anchor:start;stroke-width:0.264583"
|
||||
x="222.03329"
|
||||
y="68.589096"
|
||||
id="tspan15">For example: verity, root FS,</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
style="font-size:6.35px;text-align:start;text-anchor:start;stroke-width:0.264583"
|
||||
x="222.03329"
|
||||
y="76.526596"
|
||||
id="tspan16">and kernel boot image</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="277.00961"
|
||||
y="16.949841"
|
||||
id="text10"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan10"
|
||||
style="stroke-width:0.264583"
|
||||
x="277.00961"
|
||||
y="16.949841">UpdateSet</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
id="g19"
|
||||
transform="matrix(0.26299485,0,0,0.26299485,127.72763,135.80969)">
|
||||
<rect
|
||||
style="fill:#008075;fill-opacity:1;stroke:#0d64b5;stroke-width:0.799999;stroke-opacity:1"
|
||||
id="rect3-9"
|
||||
width="131.36539"
|
||||
height="128.86658"
|
||||
x="202.28317"
|
||||
y="291.19574"
|
||||
rx="5.0009999"
|
||||
ry="5" />
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-8"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="211.27467"
|
||||
y="330.88284"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-6-1"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="211.27467"
|
||||
y="348.61554"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-62-9"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="211.27467"
|
||||
y="366.34824"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="242.91754"
|
||||
y="392.21466"
|
||||
id="text3-7"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3-1"
|
||||
style="stroke-width:0.264583"
|
||||
x="242.91754"
|
||||
y="392.21466">⋮</tspan></text>
|
||||
<rect
|
||||
style="fill:#008075;fill-opacity:1;stroke:#0d64b5;stroke-width:0.799999;stroke-opacity:1"
|
||||
id="rect3-3-6"
|
||||
width="131.36539"
|
||||
height="128.86658"
|
||||
x="386.40073"
|
||||
y="291.19574"
|
||||
rx="5.0009999"
|
||||
ry="5" />
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-2-6"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="395.39221"
|
||||
y="330.88284"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-6-9-1"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="395.39221"
|
||||
y="348.61554"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-62-4-8"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="395.39221"
|
||||
y="366.34824"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="427.0351"
|
||||
y="392.21466"
|
||||
id="text3-1-3"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3-0-8"
|
||||
style="stroke-width:0.264583"
|
||||
x="427.0351"
|
||||
y="392.21466">⋮</tspan></text>
|
||||
<rect
|
||||
style="fill:#ff7f2a;fill-opacity:1;stroke:#b56f0d;stroke-width:0.880404;stroke-opacity:1"
|
||||
id="rect6-5"
|
||||
width="111.65157"
|
||||
height="42.399162"
|
||||
x="202.32336"
|
||||
y="234.11665"
|
||||
rx="4.9974012"
|
||||
ry="6.0599365" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Triangle-8)"
|
||||
d="m 222.63053,274.77115 -0.35698,18.91947"
|
||||
id="path8-4"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker10-2)"
|
||||
d="m 311.51634,270.4875 75.67789,23.20312"
|
||||
id="path9-4"
|
||||
sodipodi:nodetypes="cc" />
|
||||
</g>
|
||||
<g
|
||||
id="g19-6"
|
||||
transform="matrix(0.26299485,0,0,0.26299485,127.72763,199.17835)">
|
||||
<rect
|
||||
style="fill:#008075;fill-opacity:1;stroke:#0d64b5;stroke-width:0.799999;stroke-opacity:1"
|
||||
id="rect3-9-2"
|
||||
width="131.36539"
|
||||
height="128.86658"
|
||||
x="202.28317"
|
||||
y="291.19574"
|
||||
rx="5.0009999"
|
||||
ry="5" />
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-8-1"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="211.27467"
|
||||
y="330.88284"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-6-1-7"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="211.27467"
|
||||
y="348.61554"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-62-9-8"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="211.27467"
|
||||
y="366.34824"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="242.91754"
|
||||
y="392.21466"
|
||||
id="text3-7-5"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3-1-7"
|
||||
style="stroke-width:0.264583"
|
||||
x="242.91754"
|
||||
y="392.21466">⋮</tspan></text>
|
||||
<rect
|
||||
style="fill:#008075;fill-opacity:1;stroke:#0d64b5;stroke-width:0.799999;stroke-opacity:1"
|
||||
id="rect3-3-6-4"
|
||||
width="131.36539"
|
||||
height="128.86658"
|
||||
x="386.40073"
|
||||
y="291.19574"
|
||||
rx="5.0009999"
|
||||
ry="5" />
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-2-6-1"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="395.39221"
|
||||
y="330.88284"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-6-9-1-8"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="395.39221"
|
||||
y="348.61554"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<rect
|
||||
style="fill:#f13900;stroke:#a93019;stroke-width:0.93445"
|
||||
id="rect1-62-4-8-5"
|
||||
width="52.697277"
|
||||
height="12.002567"
|
||||
x="395.39221"
|
||||
y="366.34824"
|
||||
rx="6.8996673"
|
||||
ry="4.9446111" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:10.5833px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:sans-serif;text-align:end;letter-spacing:0px;word-spacing:0px;text-anchor:end;stroke-width:0.264583"
|
||||
x="427.0351"
|
||||
y="392.21466"
|
||||
id="text3-1-3-9"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3-0-8-7"
|
||||
style="stroke-width:0.264583"
|
||||
x="427.0351"
|
||||
y="392.21466">⋮</tspan></text>
|
||||
<rect
|
||||
style="fill:#ff7f2a;fill-opacity:1;stroke:#b56f0d;stroke-width:0.880404;stroke-opacity:1"
|
||||
id="rect6-5-5"
|
||||
width="111.65157"
|
||||
height="42.399162"
|
||||
x="202.32336"
|
||||
y="234.11665"
|
||||
rx="4.9974012"
|
||||
ry="6.0599365" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Triangle-8-6)"
|
||||
d="m 222.63053,274.77115 -0.35698,18.91947"
|
||||
id="path8-4-3"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker10-2-1)"
|
||||
d="m 311.51634,270.4875 75.67789,23.20312"
|
||||
id="path9-4-8"
|
||||
sodipodi:nodetypes="cc" />
|
||||
</g>
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker10)"
|
||||
d="m 142.02963,226.88607 c 29.98558,-7.85336 26.92872,-47.36399 27.13167,-52.37021 2.14182,-52.83172 30.34254,-50.6899 30.34254,-50.6899"
|
||||
id="path19"
|
||||
sodipodi:nodetypes="csc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker10)"
|
||||
d="m 142.03149,232.34519 c 29.27163,16.0637 88.04009,-2.54025 88.04009,-2.54025"
|
||||
id="path20"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker10)"
|
||||
d="m 142.07294,241.56334 c 55.80936,38.16624 88.27271,50.05886 88.27271,50.05886"
|
||||
id="path21"
|
||||
sodipodi:nodetypes="cc" />
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 31 KiB |
@ -9,7 +9,7 @@ dmi:*:svnSystemmanufacturer:*
|
||||
dmi:*:svnSystemManufacturer:*
|
||||
dmi:*:svnTobefilledbyO.E.M.:*
|
||||
dmi:*:svnToBeFilledByO.E.M.:*
|
||||
ID_SYS_VENDOR_IS_RUBBISH=1
|
||||
ID_SYS_VENDOR_IS_RUBBISH=1
|
||||
|
||||
dmi:*:pnDefaultstring:*
|
||||
dmi:*:pnN/A:*
|
||||
@ -21,7 +21,7 @@ dmi:*:pnSystemname:*
|
||||
dmi:*:pnSystemName:*
|
||||
dmi:*:pnTobefilledbyO.E.M.:*
|
||||
dmi:*:pnToBeFilledByO.E.M.:*
|
||||
ID_PRODUCT_NAME_IS_RUBBISH=1
|
||||
ID_PRODUCT_NAME_IS_RUBBISH=1
|
||||
|
||||
dmi:*:pvrDefaultstring:*
|
||||
dmi:*:pvrDefault string:*
|
||||
@ -31,7 +31,7 @@ dmi:*:pvrOEM:*
|
||||
dmi:*:pvrTobefilledbyO.E.M.:*
|
||||
dmi:*:pvrToBeFilledByO.E.M.:*
|
||||
dmi:*:pvrTo Be Filled By O.E.M.:*
|
||||
ID_PRODUCT_VERSION_IS_RUBBISH=1
|
||||
ID_PRODUCT_VERSION_IS_RUBBISH=1
|
||||
|
||||
dmi:*:rvrDefaultstring:*
|
||||
dmi:*:rvrDefault string:*
|
||||
@ -41,7 +41,7 @@ dmi:*:rvrOEM:*
|
||||
dmi:*:rvrTobefilledbyO.E.M.:*
|
||||
dmi:*:rvrToBeFilledByO.E.M.:*
|
||||
dmi:*:rvrTo Be Filled By O.E.M.:*
|
||||
ID_BOARD_VERSION_IS_RUBBISH=1
|
||||
ID_BOARD_VERSION_IS_RUBBISH=1
|
||||
|
||||
dmi:*:skuDefaultstring:*
|
||||
dmi:*:skuDefault string:*
|
||||
@ -51,7 +51,7 @@ dmi:*:skuOEM:*
|
||||
dmi:*:skuTobefilledbyO.E.M.:*
|
||||
dmi:*:skuToBeFilledByO.E.M.:*
|
||||
dmi:*:skuTo Be Filled By O.E.M.:*
|
||||
ID_PRODUCT_SKU_IS_RUBBISH=1
|
||||
ID_PRODUCT_SKU_IS_RUBBISH=1
|
||||
|
||||
dmi:*:catDefaultstring:*
|
||||
dmi:*:catDefault string:*
|
||||
@ -61,17 +61,13 @@ dmi:*:catOEM:*
|
||||
dmi:*:catTobefilledbyO.E.M.:*
|
||||
dmi:*:catToBeFilledByO.E.M.:*
|
||||
dmi:*:catTo Be Filled By O.E.M.:*
|
||||
ID_CHASSIS_ASSET_TAG_IS_RUBBISH=1
|
||||
ID_CHASSIS_ASSET_TAG_IS_RUBBISH=1
|
||||
|
||||
# Fix "Lenovo" capitalization in /sys/class/dmi/id/sys_vendor
|
||||
dmi:bvnLENOVO*
|
||||
ID_SYSFS_ATTRIBUTE_MODEL=product_version
|
||||
ID_VENDOR_FROM_DATABASE=Lenovo
|
||||
ID_SYSFS_ATTRIBUTE_MODEL=product_version
|
||||
ID_VENDOR_FROM_DATABASE=Lenovo
|
||||
|
||||
# Microsoft Surface 1's chassis type
|
||||
dmi:bvnMicrosoft Corporation*:pvrSurface with Windows 8 Pro*
|
||||
ID_CHASSIS=tablet
|
||||
|
||||
# GPD Pocket 4 chassis type
|
||||
dmi:bvnAmericanMegatrendsInternational*:rvnGPD:rnG1628-04*
|
||||
ID_CHASSIS=convertible
|
||||
ID_CHASSIS=tablet
|
||||
|
||||
@ -132,13 +132,6 @@ evdev:input:b0003v05ACp025B*
|
||||
EVDEV_ABS_35=::94
|
||||
EVDEV_ABS_36=::92
|
||||
|
||||
# MacbookPro12,1 (unibody, Early 2015)
|
||||
evdev:input:b0003v05ACp0273*
|
||||
EVDEV_ABS_00=::97
|
||||
EVDEV_ABS_01=::92
|
||||
EVDEV_ABS_35=::97
|
||||
EVDEV_ABS_36=::92
|
||||
|
||||
# MacBook8,1 (2015), MacBook9,1 (2016), MacBook10,1 (2017)
|
||||
evdev:name:Apple SPI Touchpad:dmi:*:svnAppleInc.:pnMacBook8,1:*
|
||||
evdev:name:Apple SPI Touchpad:dmi:*:svnAppleInc.:pnMacBook9,1:*
|
||||
@ -704,13 +697,6 @@ evdev:name:AlpsPS/2 ALPS GlidePoint:dmi:*svnLENOVO:*pvrLenovoideapadY700-14ISK:*
|
||||
EVDEV_ABS_35=::27
|
||||
EVDEV_ABS_36=::29
|
||||
|
||||
#Lenovo Y50-70
|
||||
evdev:name:AlpsPS/2 ALPS GlidePoint:dmi:*svnLENOVO:*pvrLenovoY50-70**
|
||||
EVDEV_ABS_00=164:3918:37
|
||||
EVDEV_ABS_01=120:1935:26
|
||||
EVDEV_ABS_35=164:3918:37
|
||||
EVDEV_ABS_36=120:1935:26
|
||||
|
||||
# Lenovo Ideapad 310S-14ISK
|
||||
evdev:name:AlpsPS/2 ALPS GlidePoint:dmi:*svnLENOVO:*pvrLenovoideapad310S-14ISK:*
|
||||
EVDEV_ABS_00=113:3960:37
|
||||
@ -760,15 +746,12 @@ evdev:name:AlpsPS/2 ALPS GlidePoint:dmi:*svnLENOVO:*pvrLenovoU41-70:*
|
||||
EVDEV_ABS_35=117:3958:36
|
||||
EVDEV_ABS_36=104:1960:26
|
||||
|
||||
# Lenovo Thinkpad T490/T495 and T14/P14s Gen1/2 (identical chassis)
|
||||
# Lenovo Thinkpad T490 and T14/P14s Gen1/2
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*:svnLENOVO:*pvrThinkPadT490:*
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*:svnLENOVO:*pvrThinkPadT495:*
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*:svnLENOVO:*pvrThinkPadT14Gen1:*
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*:svnLENOVO:*pvrThinkPadT14Gen2a:*
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*:svnLENOVO:*pvrThinkPadT14Gen2i:*
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*:svnLENOVO:*pvrThinkPadP14sGen1:*
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*:svnLENOVO:*pvrThinkPadP14sGen2a:*
|
||||
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*:svnLENOVO:*pvrThinkPadP14sGen2i:*
|
||||
EVDEV_ABS_00=::44
|
||||
EVDEV_ABS_01=::52
|
||||
EVDEV_ABS_35=::44
|
||||
|
||||
@ -320,8 +320,6 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAYANEO:pnKUN:pvr*
|
||||
# multi-scancode sequence. The specific preceding codes
|
||||
# depend on the model, but the final scancode is always the
|
||||
# same.
|
||||
evdev:name:AT Translated Set 2 keyboard:dmi:*:svnAYA NEO:*
|
||||
evdev:name:AT Translated Set 2 keyboard:dmi:*:svnAYADEVICE:*
|
||||
evdev:name:AT Translated Set 2 keyboard:dmi:*:svnAYANEO:*
|
||||
KEYBOARD_KEY_66=f15 # LC (All models)
|
||||
KEYBOARD_KEY_67=f16 # RC (All models)
|
||||
@ -667,11 +665,6 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pn*[tT][aA][bB][lL][eE][tT]*:*
|
||||
KEYBOARD_KEY_86=pageup
|
||||
KEYBOARD_KEY_87=pagedown
|
||||
|
||||
# OmniBook Ultra Flip Laptop 14-fh0xxx
|
||||
evdev:atkbd:dmi:*:svnHP:pnHPOmniBookUltraFlipLaptop14-fh0xxx:*
|
||||
KEYBOARD_KEY_82=unknown # Mic mute, handled by hp-wmi
|
||||
KEYBOARD_KEY_ab=!unknown # Brightness Down and Up keys, handled by acpi-video
|
||||
|
||||
# Pavilion
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pn*[pP][aA][vV][iI][lL][iI][oO][nN]*:*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pn*[pP][aA][vV][iI][lL][iI][oO][nN]*:*
|
||||
@ -818,8 +811,6 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pnHPEliteBook*:*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pnHPElite*x360*:*
|
||||
# HP Elite Dragonfly
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pnHPEliteDragonfly*:*
|
||||
# HP EliteBoard
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pnHPEliteBoard*:*
|
||||
# HP ProBook 440 G2
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHP440G2:*
|
||||
# HP ProBook
|
||||
@ -1172,48 +1163,18 @@ evdev:input:b0003v04B3p301B*
|
||||
KEYBOARD_KEY_90007=mail
|
||||
KEYBOARD_KEY_90008=www
|
||||
|
||||
# Lenovo Ideapad D330-10IGM and D330-10IGL
|
||||
# (Tablet buttons)
|
||||
evdev:atkbd:dmi:*:svnLENOVO:*:pvrLenovoideapadD330-10IG[ML]:*
|
||||
KEYBOARD_LED_NUMLOCK=0 # Lacks Num-Lock LED
|
||||
KEYBOARD_LED_CAPSLOCK=0 # Lacks Caps-Lock LED
|
||||
# Lenovo Ideapad D330-10IGM
|
||||
evdev:name:SIPODEV Lenovo HID Device:dmi:*:svnLENOVO:*:pvrLenovoideapadD330-10IGM:*
|
||||
KEYBOARD_KEY_70073=touchpad_toggle # Fn+Supr (Touchpad toggle)
|
||||
|
||||
# Lenovo Ideapad D330-10IGM and D330-10IGL
|
||||
# (Dock keyboard) "* Lenovo HID Device"
|
||||
evdev:input:b0003v17EFp60C[368]*-e0,1,4,11,14,k*,C2,*ram4,l0,1,2,sfw
|
||||
# Touchpad key acts as LEFTCTRL+LEFTMETA+F24 (C2) Windows shortcut for touchpad toggle,
|
||||
# with this as LEFTCTRL+LEFTMETA+TOUCHPAD_TOGGLE but just works.
|
||||
KEYBOARD_KEY_70073=touchpad_toggle # Fn+Supr (Touchpad toggle).
|
||||
KEYBOARD_LED_NUMLOCK=0 # Lacks Num-Lock LED
|
||||
KEYBOARD_LED_CAPSLOCK=0 # Lacks Caps-Lock LED
|
||||
|
||||
# Lenovo Ideapad D330-10IGM and D330-10IGL
|
||||
# (Dock keyboard: volume, brightness and FnLk keys) "* Lenovo HID Device Consumer Control"
|
||||
evdev:input:b0003v17EFp60C[368]*-e0,1,4,k*,F0,*ram4,lsfw
|
||||
KEYBOARD_KEY_c00ff=fn_esc # Fn+Tab (FnLk toggle). Default is UNKNOWN (F0).
|
||||
evdev:name:SIPODEV Lenovo HID Device Consumer Control:dmi:*:svnLENOVO:*:pvrLenovoideapadD330-10IGM:*
|
||||
KEYBOARD_KEY_c00ff=fn_esc # Fn+Tab (FnLk toggle)
|
||||
|
||||
# Lenovo Thinkbook 16 G6+ 2024
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnLENOVO:pn21LG:pvr*
|
||||
KEYBOARD_KEY_0a=!9
|
||||
KEYBOARD_KEY_0b=!0
|
||||
|
||||
# Lenovo Legion Go Translated
|
||||
evdev:name:AT Translated Set 2 keyboard:dmi:*:svnLENOVO:pn83E1:*
|
||||
# Lenovo Legion Go S Translated
|
||||
evdev:name:AT Translated Set 2 keyboard:dmi:*:svnLENOVO:pn83L3:*
|
||||
evdev:name:AT Translated Set 2 keyboard:dmi:*:svnLENOVO:pn83N6:*
|
||||
evdev:name:AT Translated Set 2 keyboard:dmi:*:svnLENOVO:pn83Q2:*
|
||||
evdev:name:AT Translated Set 2 keyboard:dmi:*:svnLENOVO:pn83Q3:*
|
||||
# Lenovo Legion Go 2 Translated
|
||||
evdev:name:AT Translated Set 2 keyboard:dmi:*:svnLENOVO:pn83N0:*
|
||||
evdev:name:AT Translated Set 2 keyboard:dmi:*:svnLENOVO:pn83N1:*
|
||||
KEYBOARD_KEY_67=f16 # Power button long press
|
||||
|
||||
# Lenovo Legion Go 2 Raw
|
||||
evdev:name:AT Raw Set 2 keyboard:dmi:*:svnLENOVO:pn83N0:*
|
||||
evdev:name:AT Raw Set 2 keyboard:dmi:*:svnLENOVO:pn83N1:*
|
||||
KEYBOARD_KEY_20=f16 # Power button long press
|
||||
|
||||
###########################################################
|
||||
# LG
|
||||
###########################################################
|
||||
@ -2399,21 +2360,21 @@ evdev:input:b0003v05FEp1010*
|
||||
######################### LACK OF MODIFIER LEDS ############################
|
||||
# This section lists keyboard which do not have their own LEDs for some
|
||||
# modifiers. Only Caps-Lock (KEYBOARD_LED_CAPSLOCK) and Num-Lock
|
||||
# (KEYBOARD_LED_NUMLOCK) are currently handled and need their values set
|
||||
# (KEYBOARD_LED_CAPSLOCK) are currently handled and need their values set
|
||||
# to "0" to indicate the absence of LED.
|
||||
#
|
||||
# Presence of a LED is implicit when the property is absent.
|
||||
|
||||
# Apple Wireless keyboards
|
||||
evdev:input:b0005v05ACp022C*
|
||||
evdev:input:b0005v05ACp022D*
|
||||
evdev:input:b0005v05ACp022E*
|
||||
evdev:input:b0005v05ACp0239*
|
||||
evdev:input:b0005v05ACp023A*
|
||||
evdev:input:b0005v05ACp023B*
|
||||
evdev:input:b0005v05ACp0255*
|
||||
evdev:input:b0005v05ACp0256*
|
||||
evdev:input:b0005v05ACp0257*
|
||||
evdev:input:b0005v05aCp022C*
|
||||
evdev:input:b0005v05aCp022D*
|
||||
evdev:input:b0005v05aCp022E*
|
||||
evdev:input:b0005v05aCp0239*
|
||||
evdev:input:b0005v05aCp023A*
|
||||
evdev:input:b0005v05aCp023B*
|
||||
evdev:input:b0005v05aCp0255*
|
||||
evdev:input:b0005v05aCp0256*
|
||||
evdev:input:b0005v05aCp0257*
|
||||
KEYBOARD_LED_NUMLOCK=0
|
||||
|
||||
# Logitech K750
|
||||
|
||||
@ -41,9 +41,7 @@
|
||||
# PROXIMITY_NEAR_LEVEL=<value>
|
||||
#
|
||||
# where <matrix> is a mount-matrix in the format specified in the IIO
|
||||
# subsystem[1]. The default, when unset, is the one defined by the ACPI
|
||||
# found in /sys/bus/iio/devices/iio\:deviceXXX/in_mount_matrix or, in
|
||||
# absence of it, is equivalent to:
|
||||
# subsystem[1]. The default, when unset, is equivalent to:
|
||||
# ACCEL_MOUNT_MATRIX=1, 0, 0; 0, 1, 0; 0, 0, 1
|
||||
# eg. the identity matrix,
|
||||
# and <value> is an integer value above or equal to which an object is
|
||||
@ -160,6 +158,10 @@ sensor:modalias:acpi:INVN6500*:dmi:*svnASUSTeK*:*pnT100TAS:*
|
||||
sensor:modalias:acpi:INVN6500*:dmi:*svnASUSTeK*:pnT200TA:*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
# Asus Transformer Mini T103HAF
|
||||
sensor:modalias:platform:HID-SENSOR-200073*:dmi:*svn*ASUSTeK*:pnT103HAF:*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; 1, 0, 0; 0, 0, -1
|
||||
|
||||
sensor:modalias:acpi:INVN6500*:dmi:*svnASUSTeK*:*pnTP201SA:*
|
||||
sensor:modalias:acpi:INVN6500*:dmi:*svnASUSTeK*:pn*E205SA:*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
@ -758,14 +760,6 @@ sensor:modalias:acpi:BMA250E*:dmi:bvnLENOVO:*:pvrLenovoMIIX3-1030:*
|
||||
sensor:modalias:acpi:SMO8500*:dmi:bvnLENOVO:*:pvrLenovoMIIX3-830:*
|
||||
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1
|
||||
|
||||
# IdeaPad D330-10IGM (81H3) and (81MD) product names
|
||||
# Panel mounted at -90º. ACPI in_mount_matrix 0, -1, 0; 1, 0, 0; 0, 0, 1
|
||||
# IdeaPad Duet 3 10IGL5 (82AT) and 10IGL5-LTE (82HK)
|
||||
# Panel mounted at -90º. ACPI in_mount_matrix unknown, if someone knows please report it
|
||||
sensor:modalias:acpi:BOSC0200*:dmi:*:svnLENOVO:*:pvrLenovoideapadD330-10IGM:*
|
||||
sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO:*:pvrIdeaPadDuet310IGL5*:*
|
||||
ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
# IdeaPad Miix 300
|
||||
sensor:modalias:acpi:SMO8500*:dmi:bvnLENOVO:*:pvrMIIX300-*:*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
||||
@ -20,65 +20,6 @@
|
||||
# Allowed properties are:
|
||||
# ID_HARDWARE_WALLET=0|1
|
||||
|
||||
################
|
||||
# Blockstream Jade Hardware Wallets
|
||||
################
|
||||
|
||||
# Jade UART (Silicon Labs)
|
||||
usb:v10C4pEA60*
|
||||
ID_HARDWARE_WALLET=1
|
||||
|
||||
# Jade UART (WCH)
|
||||
usb:v1A86p55D4*
|
||||
ID_HARDWARE_WALLET=1
|
||||
|
||||
################
|
||||
# Coinkite Hardware Wallets
|
||||
################
|
||||
|
||||
# Coldcard
|
||||
usb:vD13EpCC10*
|
||||
ID_HARDWARE_WALLET=1
|
||||
|
||||
################
|
||||
# Digital Bitbox Hardware Wallets
|
||||
################
|
||||
|
||||
# Digital Bitbox (dbb)
|
||||
usb:v03EBp2402*
|
||||
ID_HARDWARE_WALLET=1
|
||||
|
||||
# BitBox02
|
||||
usb:v03EBp2403*
|
||||
ID_HARDWARE_WALLET=1
|
||||
|
||||
################
|
||||
# KeepKey Hardware Wallets
|
||||
################
|
||||
|
||||
# KeepKey HID Firmware/Bootloader
|
||||
usb:v2B24p0001*
|
||||
ID_HARDWARE_WALLET=1
|
||||
|
||||
# KeepKey WebUSB Firmware/Bootloader
|
||||
usb:v2B24p0002*
|
||||
ID_HARDWARE_WALLET=1
|
||||
|
||||
################
|
||||
# Ledger Hardware Wallets
|
||||
################
|
||||
|
||||
# Ledger HW.1 / Nano series
|
||||
usb:v2581p1B7C*
|
||||
usb:v2581p2B7C*
|
||||
usb:v2581p3B7C*
|
||||
usb:v2581p4B7C*
|
||||
ID_HARDWARE_WALLET=1
|
||||
|
||||
# Ledger Nano S/X/Blue/Stax and related devices
|
||||
usb:v2C97*
|
||||
ID_HARDWARE_WALLET=1
|
||||
|
||||
################
|
||||
# Trezor Hardware Wallets
|
||||
################
|
||||
@ -89,5 +30,7 @@ usb:v534Cp0001*
|
||||
|
||||
# Trezor v2
|
||||
usb:v1209p53C0*
|
||||
ID_HARDWARE_WALLET=1
|
||||
|
||||
usb:v1209p53C1*
|
||||
ID_HARDWARE_WALLET=1
|
||||
|
||||
@ -26,11 +26,11 @@
|
||||
# Logitech
|
||||
################
|
||||
# Litra Beam
|
||||
bluetooth:v046DpC901*
|
||||
usb:v046DpC901*
|
||||
bluetooth:v046dpc901*
|
||||
usb:v046dpc901*
|
||||
ID_AV_LIGHTS=1
|
||||
|
||||
# Litra Glow
|
||||
bluetooth:v046DpC900*
|
||||
usb:v046DpC900*
|
||||
bluetooth:v046dpc900*
|
||||
usb:v046dpc900*
|
||||
ID_AV_LIGHTS=1
|
||||
|
||||
@ -43,32 +43,18 @@ usb:v045Ep091E*
|
||||
# Arctis Headsets
|
||||
usb:v1038p12B3*
|
||||
usb:v1038p12B6*
|
||||
usb:v1038p12D7*
|
||||
usb:v1038p1260*
|
||||
usb:v1038p12AD*
|
||||
usb:v1038p1252*
|
||||
usb:v1038p1280*
|
||||
usb:v1038p12D5*
|
||||
usb:v1038p12D7*
|
||||
usb:v1038p12AD*
|
||||
usb:v1038p220E*
|
||||
usb:v1038p2212*
|
||||
usb:v1038p2216*
|
||||
usb:v1038p2236*
|
||||
usb:v1038p12C2*
|
||||
usb:v1038p1290*
|
||||
usb:v1038p12EC*
|
||||
usb:v1038p2269*
|
||||
usb:v1038p226D*
|
||||
usb:v1038p2232*
|
||||
usb:v1038p2253*
|
||||
usb:v1038p2202*
|
||||
usb:v1038p2206*
|
||||
usb:v1038p220A*
|
||||
usb:v1038p2258*
|
||||
usb:v1038p223A*
|
||||
usb:v1038p227A*
|
||||
usb:v1038p22A1*
|
||||
usb:v1038p227E*
|
||||
usb:v1038p229E*
|
||||
usb:v1038p12E0*
|
||||
usb:v1038p12E5*
|
||||
usb:v1038p1290*
|
||||
SOUND_FORM_FACTOR=headset
|
||||
|
||||
@ -52,12 +52,6 @@ touchpad:usb:v05acp0324:*
|
||||
touchpad:usb:v044ep1221:*
|
||||
ID_INPUT_TOUCHPAD_INTEGRATION=external
|
||||
|
||||
###########################################################
|
||||
# Lenovo IdeaPad Duet3 10IGL5 (82AT)
|
||||
###########################################################
|
||||
touchpad:bluetooth:v17efp60fa:*
|
||||
ID_INPUT_TOUCHPAD_INTEGRATION=internal
|
||||
|
||||
###########################################################
|
||||
# Logitech
|
||||
###########################################################
|
||||
|
||||
@ -268,10 +268,6 @@
|
||||
<!-- add Index link at top of page -->
|
||||
<xsl:template name="user.header.content">
|
||||
<style>
|
||||
:root {
|
||||
color-scheme: light dark;
|
||||
}
|
||||
|
||||
a.headerlink {
|
||||
color: #c60f0f;
|
||||
font-size: 0.8em;
|
||||
@ -316,13 +312,6 @@
|
||||
<xsl:text>"</xsl:text>
|
||||
</xsl:template>
|
||||
|
||||
<!-- copied from docbook to remove the static color declarations -->
|
||||
<xsl:template name="body.attributes">
|
||||
<xsl:if test="starts-with($writing.mode, 'rl')">
|
||||
<xsl:attribute name="dir">rtl</xsl:attribute>
|
||||
</xsl:if>
|
||||
</xsl:template>
|
||||
|
||||
<!-- Switch things to UTF-8, ISO-8859-1 is soo yesteryear -->
|
||||
<xsl:output method="html" encoding="UTF-8" indent="no"/>
|
||||
|
||||
|
||||
@ -616,7 +616,6 @@
|
||||
<term><filename>/proc/cmdline</filename></term>
|
||||
<listitem>
|
||||
<para>Specifies the kernel command line to use. The first of the files that is found will be used.
|
||||
When running in a container, <filename>/proc/cmdline</filename> is ignored.
|
||||
<varname>$KERNEL_INSTALL_CONF_ROOT</varname> may be used to override the search path; see below for
|
||||
details.</para>
|
||||
|
||||
|
||||
@ -4901,7 +4901,7 @@ node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice {
|
||||
has no main PID. The control PID is the PID of the current start/stop/reload process running and is 0
|
||||
if no such process is currently running. That means that <varname>ExecMainPID</varname> and
|
||||
<varname>MainPID</varname> differ in the way that the latter immediately reflects whether a main
|
||||
process is currently running while the former possibly contains information collected from the last run
|
||||
process is currently running while the latter possible contains information collected from the last run
|
||||
even if the process is no longer around.</para>
|
||||
|
||||
<para><varname>StatusText</varname>, <varname>StatusErrno</varname>, <varname>StatusBusError</varname>,
|
||||
@ -12627,8 +12627,8 @@ $ gdbus introspect --system --dest org.freedesktop.systemd1 \
|
||||
<varname>LogsDirectoryQuotaUsage</varname>,
|
||||
<varname>LogsDirectoryAccounting</varname>, and
|
||||
<function>KillSubgroup()</function> were added in version 258.</para>
|
||||
<para><varname>UserNamespacePath</varname>,
|
||||
<varname>OOMKills</varname>, and
|
||||
<para><varname>OOMKills</varname>, and
|
||||
<varname>UserNamespacePath</varname>, and
|
||||
<varname>ManagedOOMKills</varname> were added in 259.</para>
|
||||
</refsect2>
|
||||
<refsect2>
|
||||
|
||||
@ -1206,7 +1206,7 @@ manpages = [
|
||||
'systemd-tmpfiles-setup.service'],
|
||||
''],
|
||||
['systemd-tpm2-clear.service', '8', [], 'ENABLE_BOOTLOADER'],
|
||||
['systemd-tpm2-generator', '8', [], 'ENABLE_BOOTLOADER'],
|
||||
['systemd-tpm2-generator', '8', [], ''],
|
||||
['systemd-tpm2-setup.service',
|
||||
'8',
|
||||
['systemd-tpm2-setup', 'systemd-tpm2-setup-early.service'],
|
||||
|
||||
@ -295,7 +295,7 @@
|
||||
|
||||
<listitem><para>If specified, run0 will elevate the privileges of the selected user (using
|
||||
<option>--user=</option>) or the current user if no user is explicitly selected. Currently this means
|
||||
we give the invoked process all available capabilities and add the <literal>empower</literal>
|
||||
we give the invoked process all available capabilities and add the the <literal>empower</literal>
|
||||
group as a supplemental group (for which all polkit actions are allowed by default), but other
|
||||
privileges may be granted in the future as well when using this option.</para>
|
||||
|
||||
|
||||
@ -1715,7 +1715,7 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
|
||||
<listitem>
|
||||
<para>Shut down and reboot the system.</para>
|
||||
|
||||
<para>This command is mostly equivalent to <command>systemctl start reboot.target
|
||||
<para>This command mostly equivalent to <command>systemctl start reboot.target
|
||||
--job-mode=replace-irreversibly --no-block</command>, but also prints a wall message to all
|
||||
users. This command is asynchronous; it will return after the reboot operation is enqueued,
|
||||
without waiting for it to complete.</para>
|
||||
|
||||
@ -722,7 +722,7 @@
|
||||
<listitem><para>Show a list of candidate block devices this command may operate on. Specifically,
|
||||
this enumerates block devices currently present that contain a LUKS superblock, and shows their
|
||||
device node paths along with any of their symlinks. The devices must implement the
|
||||
<option>hmac-secret</option> extension to be usable.</para>
|
||||
<option>hmac-secret</option> extension to be useable.</para>
|
||||
|
||||
<xi:include href="version-info.xml" xpointer="v257"/></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -85,8 +85,8 @@
|
||||
initrd. This accepts a device node path (usually <filename>/dev/disk/by-uuid/…</filename> or
|
||||
<filename>/dev/disk/by-label/…</filename> or similar), or the special values
|
||||
<literal>gpt-auto</literal>, <literal>gpt-auto-force</literal>, <literal>dissect</literal>,
|
||||
<literal>dissect-force</literal>, <literal>fstab</literal>, <literal>tmpfs</literal>,
|
||||
<literal>bind:…</literal>, and <literal>off</literal>.</para>
|
||||
<literal>dissect-force</literal>, <literal>fstab</literal>, <literal>fstab</literal>, and
|
||||
<literal>off</literal>.</para>
|
||||
|
||||
<para>Set to <literal>gpt-auto</literal>, <literal>gpt-auto-force</literal>,
|
||||
<literal>dissect</literal>, <literal>dissect-force</literal> to explicitly request automatic root
|
||||
|
||||
@ -504,10 +504,10 @@
|
||||
<term><option>--defer-partitions-empty=yes</option></term>
|
||||
|
||||
<listitem><para>This is very similar to <option>--defer-partitions=</option> but automatically
|
||||
selects all partitions for deferral that have <option>Format=empty</option> set and do not configure
|
||||
a custom label, or which set <option>Label=_empty</option>. It may be used in conjunction with
|
||||
<option>--defer-partitions=</option> or <option>--defer-partitions-factory-reset=yes</option>, in
|
||||
which case all matching partitions are deferred.</para>
|
||||
selects all partitions for deferral that have <option>Format=empty</option> set. It may be used in
|
||||
conjunction with <option>--defer-partitions=</option> or
|
||||
<option>--defer-partitions-factory-reset=yes</option>, in which case all matching partitions are
|
||||
deferred.</para>
|
||||
|
||||
<xi:include href="version-info.xml" xpointer="v259"/></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -317,7 +317,7 @@
|
||||
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
|
||||
|
||||
<para>Defaults to true. (Note that this is unlike the option of the same name to
|
||||
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
<citerefentry><refentrytitle>systemd-vmspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
that defaults to false.)</para>
|
||||
|
||||
<xi:include href="version-info.xml" xpointer="v258"/></listitem>
|
||||
|
||||
@ -943,8 +943,8 @@
|
||||
<xi:include href="version-info.xml" xpointer="v232"/>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><varname>TCP6SegmentationOffload=</varname></term>
|
||||
<varlistentry>
|
||||
<term><varname>TCP6SegmentationOffload=</varname></term>
|
||||
<listitem>
|
||||
<para>Takes a boolean. If set to true, TCP6 Segmentation Offload (tx-tcp6-segmentation) is enabled.
|
||||
When unset, the kernel's default will be used.</para>
|
||||
|
||||
@ -594,12 +594,11 @@
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>RestartSteps=</varname></term>
|
||||
<listitem><para>Configures the number of exponential steps to take to increase the interval
|
||||
<listitem><para>Configures the number of steps to take to increase the interval
|
||||
of auto-restarts from <varname>RestartSec=</varname> to <varname>RestartMaxDelaySec=</varname>.
|
||||
Takes a positive integer or 0 to disable it. Defaults to 0.</para>
|
||||
|
||||
<para>This setting is effective only if <varname>RestartMaxDelaySec=</varname> is also set and
|
||||
<varname>RestartSec=</varname> is not zero.</para>
|
||||
<para>This setting is effective only if <varname>RestartMaxDelaySec=</varname> is also set.</para>
|
||||
|
||||
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
|
||||
</varlistentry>
|
||||
@ -611,8 +610,7 @@
|
||||
in the same format as <varname>RestartSec=</varname>, or <literal>infinity</literal>
|
||||
to disable the setting. Defaults to <literal>infinity</literal>.</para>
|
||||
|
||||
<para>This setting is effective only if <varname>RestartSteps=</varname> is also set and
|
||||
<varname>RestartSec=</varname> is not zero.</para>
|
||||
<para>This setting is effective only if <varname>RestartSteps=</varname> is also set.</para>
|
||||
|
||||
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -119,15 +119,13 @@ r - 500-900
|
||||
bearing the same name unless the ID field specifies it. The account will be
|
||||
created disabled, so that logins are not allowed.</para>
|
||||
|
||||
<xi:include href="version-info.xml" xpointer="v215"/>
|
||||
|
||||
<para>Type <varname>u</varname> may be suffixed with an exclamation mark (<literal>u!</literal>) to
|
||||
create a fully locked account. This is recommended, since logins should typically not be allowed
|
||||
for system users. With or without the exclamation mark an invalid password is set. For
|
||||
<literal>u!</literal>, the account is also locked, which makes a difference for non-password forms
|
||||
of authentication, such as SSH or similar.</para>
|
||||
|
||||
<xi:include href="version-info.xml" xpointer="v257"/></listitem>
|
||||
<xi:include href="version-info.xml" xpointer="v215"/></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||