http://systemd.cn/Recent content in 首页 on systemd中文文档Hugozh[© CC BY 4.0](https://creativecommons.org/licenses/by/4.0/legalcode)http://systemd.cn/docs/Booting/AUTOMATIC_BOOT_ASSESSMENT/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/Booting/AUTOMATIC_BOOT_ASSESSMENT/<h1 id="自动启动评估">自动启动评估<a class="anchor" href="#%e8%87%aa%e5%8a%a8%e5%90%af%e5%8a%a8%e8%af%84%e4%bc%b0">#</a></h1> <p>systemd provides support for automatically reverting back to the previous version of the OS or kernel in case the system consistently fails to boot. The <a href="https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting">UAPI.1 Boot Loader Specification</a> describes how to annotate boot loader entries with a counter that specifies how many attempts should be made to boot it. This document describes how systemd implements this scheme.</p> <p>The many different components involved in the implementation may be used independently and in combination with other software to, for example, support other boot loaders or take actions outside of the boot loader.</p>http://systemd.cn/docs/Booting/ROOTFS_DISCOVERY/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/Booting/ROOTFS_DISCOVERY/<h1 id="启动组件和根文件系统探测">启动组件和根文件系统探测<a class="anchor" href="#%e5%90%af%e5%8a%a8%e7%bb%84%e4%bb%b6%e5%92%8c%e6%a0%b9%e6%96%87%e4%bb%b6%e7%b3%bb%e7%bb%9f%e6%8e%a2%e6%b5%8b">#</a></h1> <p>The recommended way to boot a <a href="https://systemd.io/"><code>systemd</code></a> based <a href="https://en.wikipedia.org/wiki/UEFI">UEFI</a> system consists primarily of three components:</p> <ol> <li> <p>A boot loader, i.e. <a href="https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html"><code>systemd-boot</code></a> that provides interactive and programmatic control of what precisely to boot. It takes care of enumerating all possible boot targets (implementing the <a href="https://uapi-group.org/specifications/specs/boot_loader_specification/">UAPI.1 Boot Loader Specification</a>), potentially presenting it to the user in a menu, but otherwise picking an item automatically, implementing boot counting and automatic rollback if desired.</p> </li> <li> <p>A <a href="https://uapi-group.org/specifications/specs/unified_kernel_image/">UAPI.5 Unified Kernel Image (&ldquo;UKI&rdquo;)</a>, i.e. an UEFI PE executable that combines <a href="https://www.freedesktop.org/software/systemd/man/latest/systemd-stub.html"><code>systemd-stub</code></a>, a Linux kernel, and an initial RAM disk (&quot;<code>initrd</code>&quot;) into one. UKIs are self-descriptive: the aforementioned boot loader enumerates these UKIs and automatically extracts all information necessary to determine which menu entries to generate for them. Within the UKI runtime (very early during kernel initialization) the transition from the UEFI firmware code to the Linux code takes place, i.e. it executes the fundamental <code>ExitBootServices()</code> UEFI call that ends PC firmware control, and lets the Linux kernel take over.</p>http://systemd.cn/docs/Booting/BOOT_LOADER_INTERFACE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/Booting/BOOT_LOADER_INTERFACE/<h1 id="引导加载程序接口">引导加载程序接口<a class="anchor" href="#%e5%bc%95%e5%af%bc%e5%8a%a0%e8%bd%bd%e7%a8%8b%e5%ba%8f%e6%8e%a5%e5%8f%a3">#</a></h1> <p>systemd can interface with the boot loader to receive performance data and other information, and pass control information. This is only supported on EFI systems. Data is transferred between the boot loader and systemd in EFI variables. All EFI variables use the vendor UUID <code>4a67b082-0a4c-41cf-b6c7-440b29bb8c4f</code>. Variables will be listed below using the Linux efivarfs naming, <code>&lt;name&gt;-&lt;vendoruuid&gt;</code>.</p> <ul> <li> <p>The EFI Variable <code>LoaderTimeInitUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f</code> contains the timestamp in microseconds when the loader was initialized. This value is the time spent in the firmware for initialization. It is formatted as numeric, NUL-terminated, decimal string, in UTF-16.</p>http://systemd.cn/docs/Booting/FACTORY_RESET/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/Booting/FACTORY_RESET/<h1 id="恢复出厂设置">恢复出厂设置<a class="anchor" href="#%e6%81%a2%e5%a4%8d%e5%87%ba%e5%8e%82%e8%ae%be%e7%bd%ae">#</a></h1> <p>In various scenarios it is important to be able to reset operating systems back into a &ldquo;factory state&rdquo;, i.e. where all state, user data and configuration is reset so that it resembles the system state when it was originally shipped.</p> <p>systemd natively supports a concept of factory reset, that can both act as a specific implementation for UEFI based systems, as well as a series of hook points and a template for implementations on other systems.</p>http://systemd.cn/docs/Booting/MOUNT_REQUIREMENTS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/Booting/MOUNT_REQUIREMENTS/<h1 id="挂载点可用性要求">挂载点可用性要求<a class="anchor" href="#%e6%8c%82%e8%bd%bd%e7%82%b9%e5%8f%af%e7%94%a8%e6%80%a7%e8%a6%81%e6%b1%82">#</a></h1> <p>This document describes the requirements placed by systemd on the time when various parts of the file system hierarchy must be available and mounted during boot. This document should be read in conjunction with <a href="https://uapi-group.org/specifications/specs/linux_file_system_hierarchy/">UAPI.9 Linux File System Hierarchy</a>, which describes the role of the mount points discussed here.</p> <p>If the file system backing a mount point is located on external or remote media that require special drivers, infrastructure or networking to be set up, then this implies that this functionality must be started and running at the point in the boot sequence when that mount point is required.</p>http://systemd.cn/docs/Booting/TPM2_PCR_MEASUREMENTS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/Booting/TPM2_PCR_MEASUREMENTS/<h1 id="tpm2-pcr测量">TPM2 PCR测量<a class="anchor" href="#tpm2-pcr%e6%b5%8b%e9%87%8f">#</a></h1> <p>Various systemd components issue TPM2 PCR measurements during the boot process, both in UEFI mode and from userspace. The following lists all measurements done, and describes (in case done before <code>ExitBootServices()</code>) how they appear in the TPM2 Event Log, maintained by the PC firmware. Note that the userspace measurements listed below are (by default) only done if a system is booted with <code>systemd-stub</code> — or in other words: systemd&rsquo;s userspace measurements are linked to systemd&rsquo;s UEFI-mode measurements, and if the latter are not done the former aren&rsquo;t made either.</p>http://systemd.cn/posts/example-post/Wed, 15 Jan 2025 00:00:00 +0000http://systemd.cn/posts/example-post/<p>This is an example blog post demonstrating the Hugo Book blog layout.</p> <h2 id="what-this-demonstrates">What This Demonstrates<a class="anchor" href="#what-this-demonstrates">#</a></h2> <p>Blog posts in Hugo Book support standard Hugo content features:</p> <ul> <li><strong>Date display</strong>: configured via <code>BookDateFormat</code></li> <li><strong>Tags and categories</strong>: displayed as metadata</li> <li><strong>Pagination</strong>: automatic when multiple posts exist</li> <li><strong>Prev/next navigation</strong>: links between posts in the section</li> </ul> <h2 id="adding-your-own-posts">Adding Your Own Posts<a class="anchor" href="#adding-your-own-posts">#</a></h2> <p>Create markdown files under <code>content/posts/</code>:</p> <pre tabindex="0"><code>content/ └── posts/ ├── _index.md ├── first-post.md └── second-post.md</code></pre><p>Each post needs at minimum a <code>title</code> and <code>date</code> in frontmatter. See <a href="http://systemd.cn/docs/content/blog/">Blog</a> for full documentation.</p>http://systemd.cn/docs/API_FILE_SYSTEMS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/API_FILE_SYSTEMS/<h1 id="api-file-systems">API File Systems<a class="anchor" href="#api-file-systems">#</a></h1> <p><em>So you are seeing all kinds of weird file systems in the output of mount(8) that are not listed in <code>/etc/fstab</code>, and you wonder what those are, how you can get rid of them, or at least change their mount options.</em></p> <p>The Linux kernel provides a number of different ways for userspace to communicate with it. For many facilities there are system calls, others are hidden behind Netlink interfaces, and even others are exposed via virtual file systems such as <code>/proc</code> or <code>/sys</code>. These file systems are programming interfaces, they are not actually backed by real, persistent storage. They simply use the file system interface of the kernel as interface to various unrelated mechanisms. Similarly, there are file systems that userspace uses for its own API purposes, to store shared memory segments, shared temporary files or sockets. In this article we want to discuss all these kind of <em>API file systems</em>. More specifically, here&rsquo;s a list of these file systems typical Linux systems currently have:</p>http://systemd.cn/docs/APPSTREAM_BUNDLE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/APPSTREAM_BUNDLE/<h1 id="appstream-bundle">Appstream Bundle<a class="anchor" href="#appstream-bundle">#</a></h1> <p>NOTE: This document is a work-in-progress.</p> <p>NOTE: This isn&rsquo;t yet implemented in libappstream and the software centers.</p> <p><a href="https://www.freedesktop.org/software/appstream/docs/chap-CatalogData.html">Appstream catalogs</a> are a standardized way to expose metadata about system components, apps, and updates to software centers (i.e. GNOME Software and KDE Discover). The <code>&lt;bundle/&gt;</code> tag links an appstream component to a packaging format. This is used by the software centers to decide which code path (or plugin) should handle the component. For instance: components with a <code>&lt;bundle type=&quot;package&quot;&gt;...&lt;/bundle&gt;</code> will be handled by <a href="https://www.freedesktop.org/software/PackageKit/">PackageKit</a>, and components with a <code>&lt;bundle type=&quot;flatpak&quot;&gt;...&lt;/bundle&gt;</code> will be handled by <a href="https://docs.flatpak.org/">libflatpak</a>. This document will define how to format an appstream component&rsquo;s <code>&lt;bundle&gt;</code> tag such that software centers will know to manage it using systemd. The following syntax will be supported:</p>http://systemd.cn/docs/BACKPORTS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/BACKPORTS/<h1 id="backports">Backports<a class="anchor" href="#backports">#</a></h1> <p>The upstream systemd git repo at <a href="https://github.com/systemd/systemd">https://github.com/systemd/systemd</a> contains the <code>main</code> branch that progresses at a quick pace, continuously bringing both bugfixes and new features. New releases are tagged as <code>vNNN</code> on this branch.</p> <p>In addition to the <code>main</code> branch, the repo contains a number of branches for stable point updates for a given release, called <code>vNNN-stable</code>. Stable releases are tagged as <code>vNNN.X</code> on those branches. See <a href="https://github.com/systemd/systemd/branches/all?query=-stable">list of branches</a> and <a href="https://github.com/systemd/systemd/pulls?q=is%3Apr&#43;is%3Aopen&#43;label%3Astable-branch">pull requests for stable branches</a>.</p>http://systemd.cn/docs/SEPARATE_USR_IS_BROKEN/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/SEPARATE_USR_IS_BROKEN/<h1 id="booting-without-usr-is-broken">Booting Without /usr is Broken<a class="anchor" href="#booting-without-usr-is-broken">#</a></h1> <p>You probably discovered this page because your shiny new systemd system referred you here during boot time, when it warned you that booting without <code>/usr</code> pre-mounted wasn&rsquo;t supported anymore. And now you wonder what this all is about. Here&rsquo;s an attempt of an explanation:</p> <p>One thing in advance: systemd itself is actually mostly fine with <code>/usr</code> on a separate file system that is not pre-mounted at boot time. However, the common basic set of OS components of modern Linux machines is not, and has not been in quite some time. And it is unlikely that this is going to be fixed any time soon, or even ever.</p>http://systemd.cn/docs/CODE_QUALITY/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/CODE_QUALITY/<h1 id="code-quality-tools">Code Quality Tools<a class="anchor" href="#code-quality-tools">#</a></h1> <p>The systemd project has a number of code quality tools set up in the source tree and on the github infrastructure. Here&rsquo;s an incomprehensive list of the available functionality:</p> <ol> <li> <p>Use <code>meson test -C build</code> to run the unit tests. Some tests are skipped if no privileges are available, hence consider also running them with <code>sudo meson test -C build</code>. A couple of unit tests are considered &ldquo;unsafe&rdquo; (as they change system state); to run those too, build with <code>meson setup -Dtests=unsafe</code>. Finally, some unit tests are considered to be very slow, build them too with <code>meson setup -Dslow-tests=true</code>. (Note that there are a couple of manual tests in addition to these unit tests.) (Also note: you can change these flags for an already set up build tree, too, with &ldquo;meson configure -C build -D…&rdquo;.)</p>http://systemd.cn/docs/CODING_STYLE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/CODING_STYLE/<h1 id="coding-style">Coding Style<a class="anchor" href="#coding-style">#</a></h1> <h2 id="formatting">Formatting<a class="anchor" href="#formatting">#</a></h2> <ul> <li> <p>8ch indent, no tabs, except for files in <code>man/</code> which are 2ch indent, and still no tabs, and shell scripts, which are 4ch indent, and no tabs either.</p> </li> <li> <p>We prefer <code>/* comments */</code> over <code>// comments</code> in code you commit, please. This way <code>// comments</code> are left for developers to use for local, temporary commenting of code for debug purposes (i.e. uncommittable stuff), making such comments easily discernible from explanatory, documenting code comments (i.e. committable stuff).</p>http://systemd.cn/docs/INCOMPATIBILITIES/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/INCOMPATIBILITIES/<h1 id="compatibility-with-sysv">Compatibility with SysV<a class="anchor" href="#compatibility-with-sysv">#</a></h1> <p>Since systemd v260, support for SysV functionality has been removed. The documentation below is preserved for historical reference only.</p> <p>A few interfaces are optionally kept for backward compatibility. When systemd is compiled with the <code>-Dcompat-sysv-interfaces=true</code> setting, legacy interfaces are provided, e.g. the <code>runlevelX.target</code> aliases, and lock directories under <code>/var</code> and <code>/run</code>. This option may be extended to cover other deprecated interfaces in the future.</p> <h2 id="pre-v260-state">Pre v260 state<a class="anchor" href="#pre-v260-state">#</a></h2> <p>systemd provides a fair degree of compatibility with the behavior exposed by the SysV init system as implemented by many distributions. Compatibility is provided both for the user experience and the SysV scripting APIs. However, there are some areas where compatibility is limited due to technical reasons or design decisions of systemd and the distributions. All of the following applies to SysV init scripts handled by systemd, however a number of them matter only on specific distributions. Many of the incompatibilities are specific to distribution-specific extensions of LSB/SysV init.</p>http://systemd.cn/docs/CONTAINER_INTERFACE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/CONTAINER_INTERFACE/<h1 id="the-container-interface">The Container Interface<a class="anchor" href="#the-container-interface">#</a></h1> <p>Also consult <a href="http://systemd.cn/WRITING_VM_AND_CONTAINER_MANAGERS">Writing Virtual Machine or Container Managers</a>.</p> <p>systemd has a number of interfaces for interacting with container managers, when systemd is used inside of an OS container. If you work on a container manager, please consider supporting the following interfaces.</p> <h2 id="execution-environment">Execution Environment<a class="anchor" href="#execution-environment">#</a></h2> <ol> <li> <p>If the container manager wants to control the hostname for a container running systemd it may just set it before invoking systemd, and systemd will leave it unmodified when there is no hostname configured in <code>/etc/hostname</code> (that file overrides whatever is pre-initialized by the container manager).</p>http://systemd.cn/docs/CONTRIBUTING/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/CONTRIBUTING/<h1 id="contributing">Contributing<a class="anchor" href="#contributing">#</a></h1> <p>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:</p> <h2 id="filing-issues">Filing Issues<a class="anchor" href="#filing-issues">#</a></h2> <ul> <li>We use <a href="https://github.com/systemd/systemd/issues">GitHub Issues</a> <strong>exclusively</strong> for tracking <strong>bugs</strong> and <strong>feature</strong> <strong>requests</strong> (RFEs) of systemd. If you are looking for help, please try the forums of your distribution first, or <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel">systemd-devel mailing list</a> for general questions about systemd.</li> <li>We only track bugs in the <strong>two</strong> <strong>most</strong> <strong>recently</strong> <strong>released</strong> (non-rc) <strong>versions</strong> of systemd in the GitHub Issue tracker. If you are using an older version of systemd, please contact your distribution&rsquo;s bug tracker instead (see below). See <a href="https://github.com/systemd/systemd/releases">GitHub Release Page</a> for the list of most recent releases.</li> <li>When filing a feature request issue (RFE), please always check first if the newest upstream version of systemd already implements the feature, and whether there&rsquo;s already an issue filed for your feature by someone else.</li> <li>When filing an issue, specify the <strong>systemd</strong> <strong>version</strong> you are experiencing the issue with. Also, indicate which <strong>distribution</strong> you are using.</li> <li>Please include an explanation how to reproduce the issue you are pointing out.</li> </ul> <p>Following these guidelines makes it easier for us to process your issue, and ensures we won&rsquo;t close your issue right-away for being misfiled.</p>http://systemd.cn/docs/CGROUP_DELEGATION/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/CGROUP_DELEGATION/<h1 id="control-group-apis-and-delegation">Control Group APIs and Delegation<a class="anchor" href="#control-group-apis-and-delegation">#</a></h1> <p><em>Intended audience: hackers working on userspace subsystems that require direct cgroup access, such as container managers and similar.</em></p> <p>So you are wondering about resource management with systemd, you know Linux control groups (cgroups) a bit and are trying to integrate your software with what systemd has to offer there. Here&rsquo;s a bit of documentation about the concepts and interfaces involved with this.</p> <p>What&rsquo;s described here has been part of systemd and documented since v205 times. However, it has been updated and improved substantially, even though the concepts stayed mostly the same. This is an attempt to provide more comprehensive up-to-date information about all this, particular in light of the poor implementations of the components interfacing with systemd of current container managers.</p>http://systemd.cn/docs/CONVERTING_TO_HOMED/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/CONVERTING_TO_HOMED/<h1 id="converting-existing-users-to-systemd-homed-managed-users">Converting Existing Users to systemd-homed managed Users<a class="anchor" href="#converting-existing-users-to-systemd-homed-managed-users">#</a></h1> <p>Traditionally on most Linux distributions, regular (human) users are managed via entries in <code>/etc/passwd</code>, <code>/etc/shadow</code>, <code>/etc/group</code> and <code>/etc/gshadow</code>. With the advent of <a href="https://www.freedesktop.org/software/systemd/man/latest/systemd-homed.service.html"><code>systemd-homed</code></a> it might be desirable to convert an existing, traditional user account to a <code>systemd-homed</code> managed one. Below is a brief guide how to do that.</p> <p>Before continuing, please read up on these basic concepts:</p> <ul> <li><a href="http://systemd.cn/HOME_DIRECTORY">Home Directories</a></li> <li><a href="http://systemd.cn/USER_RECORD">JSON User Records</a></li> <li><a href="http://systemd.cn/GROUP_RECORD">JSON Group Records</a></li> <li><a href="http://systemd.cn/USER_GROUP_API">User/Group Record Lookup API via Varlink</a></li> </ul> <h2 id="caveat">Caveat<a class="anchor" href="#caveat">#</a></h2> <p>This is a manual process, and possibly a bit fragile. Hence, do this at your own risk, read up beforehand, and make a backup first. You know what&rsquo;s at stake: your own home directory, i.e. all your personal data.</p>http://systemd.cn/docs/CREDENTIALS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/CREDENTIALS/<h1 id="system-and-service-credentials">System and Service Credentials<a class="anchor" href="#system-and-service-credentials">#</a></h1> <p>The <code>systemd</code> service manager supports a &ldquo;credential&rdquo; concept for securely acquiring and passing credential data to systems and services. The precise nature of the credential data is up to applications, but the concept is intended to provide systems and services with potentially security sensitive cryptographic keys, certificates, passwords, identity information and similar types of information. It may also be used as generic infrastructure for parameterizing systems and services.</p>http://systemd.cn/docs/DESKTOP_ENVIRONMENTS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/DESKTOP_ENVIRONMENTS/<h1 id="desktop-environments">Desktop Environments<a class="anchor" href="#desktop-environments">#</a></h1> <p>NOTE: This document is a work-in-progress.</p> <h2 id="single-graphical-session">Single Graphical Session<a class="anchor" href="#single-graphical-session">#</a></h2> <p>systemd only supports running one graphical session per user at a time. While this might not have always been the case historically, having multiple sessions for one user running at the same time is problematic. The DBus session bus is shared between all the logins, and services that are started must be implicitly assigned to the user&rsquo;s current graphical session.</p>http://systemd.cn/docs/DEBUGGING/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/DEBUGGING/<h1 id="diagnosing-boot-problems">Diagnosing Boot Problems<a class="anchor" href="#diagnosing-boot-problems">#</a></h1> <p>If your machine gets stuck during boot, first check if the hang happens before or after control passes to systemd.</p> <p>Try to boot without <code>rhgb</code> and <code>quiet</code> on the kernel command line. If you see some messages like these:</p> <ul> <li>Welcome to Fedora <em>VERSION</em> (<em>codename</em>)!&quot;</li> <li>Starting <em>name</em>&hellip;</li> <li>[ OK ] Started <em>name</em>.</li> </ul> <p>then systemd is running. (See an actual <a href="../assets/f17boot.png">screenshot</a>.)</p> <p>Debugging always gets easier if you can get a shell. If you do not get a login prompt, try switching to a different virtual terminal using CTRL+ALT+F__. Problems with a display server startup may manifest themselves as a missing login on tty1, but other VTs working.</p>http://systemd.cn/docs/FILE_DESCRIPTOR_STORE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/FILE_DESCRIPTOR_STORE/<h1 id="the-file-descriptor-store">The File Descriptor Store<a class="anchor" href="#the-file-descriptor-store">#</a></h1> <p><em>TL;DR: The systemd service manager may optionally maintain a set of file descriptors for each service. Those file descriptors are under control of the service. Storing file descriptors in the manager makes is easier to restart services without dropping connections or losing state.</em></p> <p>Since its inception <code>systemd</code> has supported the <em>socket</em> <em>activation</em> 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: <em>fd</em>) passing over <code>execve()</code>. This is primarily exposed in the <a href="https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html">.socket</a> unit type.</p>http://systemd.cn/docs/FAQ/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/FAQ/<h1 id="frequently-asked-questions">Frequently Asked Questions<a class="anchor" href="#frequently-asked-questions">#</a></h1> <p>Also check out the <a href="http://systemd.cn/TIPS_AND_TRICKS">Tips &amp; Tricks</a>!</p> <p><strong>Q: How do I change the current runlevel?</strong></p> <p>A: The concept of runlevels is obsolete. A set of target units are exposed that carry similar semantics, e.g. runlevel 5 -&gt; <code>graphical.target</code>:</p> <div class="highlight"><pre tabindex="0" style="color:#e2e4e5;background-color:#282a36;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-sh" data-lang="sh"><span style="display:flex;"><span><span style="color:#78787e"># systemctl isolate graphical.target</span></span></span></code></pre></div><p>This will only change the current runlevel, and has no effect on the next boot.</p> <p><strong>Q: How do I change the default runlevel to boot into?</strong></p> <p>A: The symlink /etc/systemd/system/default.target controls where we boot into by default. Link it to the target unit of your choice. For example, like this:</p>http://systemd.cn/docs/GOVERNANCE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/GOVERNANCE/<p>The systemd project is governed as a Free Software project, with the following rules:</p> <ol> <li> <p>Anyone is welcome to submit comments and reviews.</p> </li> <li> <p>Every project maintainer has the right to merge changes, if they feel that they hold the expertise in the specific area.</p> </li> <li> <p>Except for trivial changes, an approval from at least one project maintainer who is not the author is required before merging.</p> </li> <li> <p>Regular contributors may be invited to join the project maintainers team.</p>http://systemd.cn/docs/HACKING/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/HACKING/<h1 id="hacking-on-systemd">Hacking on systemd<a class="anchor" href="#hacking-on-systemd">#</a></h1> <p>We welcome all contributions to systemd. If you notice a bug or a missing feature, please feel invited to fix it, and submit your work as a <a href="https://github.com/systemd/systemd/pull/new">GitHub Pull Request (PR)</a>.</p> <p>Please make sure to follow our <a href="http://systemd.cn/CODING_STYLE">Coding Style</a> when submitting patches. Also have a look at our <a href="http://systemd.cn/CONTRIBUTING">Contribution Guidelines</a>.</p> <p>When adding new functionality, tests should be added. For shared functionality (in <code>src/basic/</code> and <code>src/shared/</code>) unit tests should be sufficient. The general policy is to keep tests in matching files underneath <code>src/test/</code>, e.g. <code>src/test/test-path-util.c</code> contains tests for any functions in <code>src/basic/path-util.c</code>. If adding a new source file, consider adding a matching test executable. For features at a higher level, tests in <code>src/test/</code> are very strongly recommended. If that is not possible, integration tests in <code>test/</code> are encouraged. Please always test your work before submitting a PR.</p>http://systemd.cn/docs/HOME_DIRECTORY/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/HOME_DIRECTORY/<h1 id="home-directories">Home Directories<a class="anchor" href="#home-directories">#</a></h1> <p><a href="https://www.freedesktop.org/software/systemd/man/latest/systemd-homed.service.html"><code>systemd-homed.service(8)</code></a> manages home directories of regular (&ldquo;human&rdquo;) 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 between systems without any further, external metadata. This document describes the format used by these home directories, in the context of the storage mechanism used.</p> <h2 id="general-structure">General Structure<a class="anchor" href="#general-structure">#</a></h2> <p>Inside of the home directory a file <code>~/.identity</code> contains the JSON formatted user record of the user. It follows the format defined in <a href="http://systemd.cn/USER_RECORD"><code>JSON User Records</code></a>. It is recommended to bring the record into &rsquo;normalized&rsquo; form(i.e. all objects should contain their fields sorted alphabetically by their key) before storing it there, though this is not required nor enforced. Since the user record is cryptographically signed, the user cannot make modifications to the file on their own (at least not without corrupting it, or knowing the private key used for signing the record). Note that user records are stored here without their <code>binding</code>, <code>status</code> and <code>secret</code> sections, i.e. only with the sections included in the signature plus the signature section itself.</p>http://systemd.cn/docs/INHIBITOR_LOCKS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/INHIBITOR_LOCKS/<h1 id="inhibitor-locks">Inhibitor Locks<a class="anchor" href="#inhibitor-locks">#</a></h1> <p>systemd 183 and newer include a logic to inhibit system shutdowns and sleep states. This is implemented as part of <a href="https://www.freedesktop.org/software/systemd/man/latest/systemd-logind.service.html">systemd-logind.daemon(8)</a> There are a couple of different use cases for this:</p> <ul> <li> <p>A CD burning application wants to ensure that the system is not turned off or suspended while the burn process is in progress.</p> </li> <li> <p>A package manager wants to ensure that the system is not turned off while a package upgrade is in progress.</p>http://systemd.cn/docs/INITRD_INTERFACE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/INITRD_INTERFACE/<h1 id="the-initrd-interface-of-systemd">The initrd Interface of systemd<a class="anchor" href="#the-initrd-interface-of-systemd">#</a></h1> <p>The Linux initrd mechanism (short for &ldquo;initial RAM disk&rdquo;, also known as &ldquo;initramfs&rdquo;) refers to a small file system archive that is unpacked by the kernel and contains the first userspace code that runs. It typically finds and transitions into the actual root file system to use. systemd supports both initrd and initrd-less boots. If an initrd is used, it is a good idea to pass a few bits of runtime information from the initrd to systemd in order to avoid duplicate work and to provide performance data to the administrator. In this page we attempt to roughly describe the interfaces that exist between the initrd and systemd. These interfaces are currently used by <a href="https://github.com/systemd/mkosi">mkosi</a>-generated initrds, dracut and the Arch Linux initrds.</p>http://systemd.cn/docs/JOURNAL_EXPORT_FORMATS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/JOURNAL_EXPORT_FORMATS/<h1 id="journal-export-formats">Journal Export Formats<a class="anchor" href="#journal-export-formats">#</a></h1> <h2 id="journal-export-format">Journal Export Format<a class="anchor" href="#journal-export-format">#</a></h2> <p><em>Note that this document describes the binary serialization format of journals only, as used for transfer across the network. For interfacing with web technologies there&rsquo;s the Journal JSON Format, described below. The binary format on disk is documented as the <a href="http://systemd.cn/JOURNAL_FILE_FORMAT">Journal File Format</a>.</em></p> <p><em>Before reading on, please make sure you are aware of the <a href="https://www.freedesktop.org/software/systemd/man/latest/systemd.journal-fields.html">basic properties of journal entries</a>, in particular realize that they may include binary non-text data (though usually don&rsquo;t), and the same field might have multiple values assigned within the same entry (though usually hasn&rsquo;t).</em></p>http://systemd.cn/docs/JOURNAL_FILE_FORMAT/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/JOURNAL_FILE_FORMAT/<h1 id="journal-file-format">Journal File Format<a class="anchor" href="#journal-file-format">#</a></h1> <p><em>Note that this document describes the binary on-disk format of journals only. For interfacing with web technologies there&rsquo;s the <a href="http://systemd.cn/docs/JOURNAL_EXPORT_FORMATS/#journal-json-format">Journal JSON Format</a>. For transfer of journal data across the network there&rsquo;s the <a href="http://systemd.cn/docs/JOURNAL_EXPORT_FORMATS/#journal-export-format">Journal Export Format</a>.</em></p> <p>The systemd journal stores log data in a binary format with several features:</p> <ul> <li>Fully indexed by all fields</li> <li>Can store binary data, up to 2^64-1 in size</li> <li>Seekable</li> <li>Primarily append-based, hence robust to corruption</li> <li>Support for in-line compression</li> <li>Support for in-line Forward Secure Sealing</li> </ul> <p>This document explains the basic structure of the file format on disk. We are making this available primarily to allow review and provide documentation. Note that the actual implementation in the <a href="https://github.com/systemd/systemd/blob/main/src/libsystemd/sd-journal/">systemd codebase</a> is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right. That said we&rsquo;ll of course try hard to keep this document up-to-date and accurate.</p>http://systemd.cn/docs/CATALOG/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/CATALOG/<h1 id="journal-message-catalogs">Journal Message Catalogs<a class="anchor" href="#journal-message-catalogs">#</a></h1> <p>Starting with 196 systemd includes a message catalog system which allows augmentation on display of journal log messages with short explanation texts, keyed off the MESSAGE_ID= field of the entry. Many important log messages generated by systemd itself have message catalog entries. External packages can easily provide catalog data for their own messages.</p> <p>The message catalog has a number of purposes:</p> <ul> <li>Provide the administrator, user or developer with further information about the issue at hand, beyond the actual message text</li> <li>Provide links to further documentation on the topic of the specific message</li> <li>Provide native language explanations for English language system messages</li> <li>Provide links for support forums, hotlines or other contacts</li> </ul> <h2 id="format">Format<a class="anchor" href="#format">#</a></h2> <p>Message catalog source files are simple text files that follow an RFC822 inspired format. To get an understanding of the format <a href="https://github.com/systemd/systemd/blob/main/catalog/systemd.catalog.in">here&rsquo;s an example file</a>, 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.</p>http://systemd.cn/docs/GROUP_RECORD/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/GROUP_RECORD/<h1 id="json-group-records">JSON Group Records<a class="anchor" href="#json-group-records">#</a></h1> <p>Long story short: JSON Group Records are to <code>struct group</code> what <a href="http://systemd.cn/USER_RECORD">JSON User Records</a> are to <code>struct passwd</code>.</p> <p>Conceptually, much of what applies to JSON user records also applies to JSON group records. They also consist of seven sections, with similar properties and they carry some identical (or at least very similar) fields.</p> <h2 id="fields-in-the-regular-section">Fields in the <code>regular</code> section<a class="anchor" href="#fields-in-the-regular-section">#</a></h2> <p><code>groupName</code> → A string with the UNIX group name. Matches the <code>gr_name</code> field of UNIX/glibc NSS <code>struct group</code>, or the shadow structure <code>struct sgrp</code>&rsquo;s <code>sg_namp</code> field.</p>http://systemd.cn/docs/USER_RECORD/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/USER_RECORD/<h1 id="json-user-records">JSON User Records<a class="anchor" href="#json-user-records">#</a></h1> <p>systemd optionally processes user records that go beyond the classic UNIX (or glibc NSS) <code>struct passwd</code>. Various components of systemd are able to provide and consume records in a more extensible format of a dictionary of key/value pairs, encoded as JSON.</p> <p>Specifically:</p> <ol> <li> <p><a href="https://www.freedesktop.org/software/systemd/man/latest/systemd-homed.service.html"><code>systemd-homed.service</code></a> manages <code>human</code> user home directories and embeds these JSON records directly in the home directory images (see <a href="http://systemd.cn/HOME_DIRECTORY">Home Directories</a> for details).</p> </li> <li> <p><a href="https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html"><code>pam_systemd</code></a> processes these JSON records for users that log in, and applies various settings to the activated session, including environment variables, nice levels and more.</p>http://systemd.cn/docs/ENVIRONMENT/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/ENVIRONMENT/<h1 id="known-environment-variables">Known Environment Variables<a class="anchor" href="#known-environment-variables">#</a></h1> <p>A number of systemd components take additional runtime parameters via environment variables. Many of these environment variables are not supported at the same level as command line switches and other interfaces are: we don&rsquo;t document them in the man pages and we make no stability guarantees for them. While they generally are unlikely to be dropped any time soon again, we do not want to guarantee that they stay around for good either.</p>http://systemd.cn/docs/BLOCK_DEVICE_LOCKING/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/BLOCK_DEVICE_LOCKING/<h1 id="locking-block-device-access">Locking Block Device Access<a class="anchor" href="#locking-block-device-access">#</a></h1> <p><em>TL;DR: Use BSD file locks <a href="https://man7.org/linux/man-pages/man2/flock.2.html">(<code>flock(2)</code>)</a> on block device nodes to synchronize access for partitioning and file system formatting tools.</em></p> <p><code>systemd-udevd</code> probes all block devices showing up for file system superblock and partition table information (utilizing <code>libblkid</code>). If another program concurrently modifies a superblock or partition table this probing might be affected, which is bad in itself, but also might in turn result in undesired effects in programs subscribing to <code>udev</code> events.</p>http://systemd.cn/docs/MINIMAL_BUILDS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/MINIMAL_BUILDS/<h1 id="minimal-builds">Minimal Builds<a class="anchor" href="#minimal-builds">#</a></h1> <p>systemd includes a variety of components. The core components are always built (which includes systemd itself, as well as udevd and journald). Many of the other components can be disabled at compile time with configure switches.</p> <p>For some uses the configure switches do not provide sufficient modularity. For example, they cannot be used to build only the man pages, or to build only the tmpfiles tool, only detect-virt or only udevd.</p>http://systemd.cn/docs/MY_SERVICE_CANT_GET_REALTIME/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/MY_SERVICE_CANT_GET_REALTIME/<h1 id="my-service-cant-get-realtime">My Service Can&rsquo;t Get Realtime!<a class="anchor" href="#my-service-cant-get-realtime">#</a></h1> <p><em>So, you have a service that requires real-time scheduling. When you run this service on your systemd system it is unable to acquire real-time scheduling, even though it is full root and has all possible privileges. And now you are wondering what is going on and what you can do about it?</em></p> <h2 id="what-is-going-on">What is Going on?<a class="anchor" href="#what-is-going-on">#</a></h2> <p>By default systemd places all system services into their own control groups in the &ldquo;cpu&rdquo; hierarchy. This has the benefit that the CPU usage of services with many worker threads or processes (think: Apache with all its gazillion CGIs and stuff) gets roughly the same amount of CPU as a service with very few worker threads (think: MySQL). Instead of evening out CPU <em>per process</em> this will cause CPU to be evened out <em>per service</em>.</p>http://systemd.cn/docs/JOURNAL_NATIVE_PROTOCOL/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/JOURNAL_NATIVE_PROTOCOL/<h1 id="native-journal-protocol">Native Journal Protocol<a class="anchor" href="#native-journal-protocol">#</a></h1> <p><code>systemd-journald.service</code> accepts log data via various protocols:</p> <ul> <li>Classic RFC3164 BSD syslog via the <code>/dev/log</code> socket</li> <li>STDOUT/STDERR of programs via <code>StandardOutput=journal</code> + <code>StandardError=journal</code> in service files (both of which are default settings)</li> <li>Kernel log messages via the <code>/dev/kmsg</code> device node</li> <li>Audit records via the kernel&rsquo;s audit subsystem</li> <li>Structured log messages via <code>journald</code>&rsquo;s native protocol</li> </ul> <p>The latter is what this document is about: if you are developing a program and want to pass structured log data to <code>journald</code>, it&rsquo;s the Journal&rsquo;s native protocol that you want to use. The systemd project provides the <a href="https://www.freedesktop.org/software/systemd/man/latest/sd_journal_print.html"><code>sd_journal_print(3)</code></a> API that implements the client side of this protocol. This document explains what this interface does behind the scenes, in case you&rsquo;d like to implement a client for it yourself, without linking to <code>libsystemd</code> — for example because you work in a programming language other than C or otherwise want to avoid the dependency.</p>http://systemd.cn/docs/CONTROL_GROUP_INTERFACE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/CONTROL_GROUP_INTERFACE/<h1 id="the-new-control-group-interfaces">The New Control Group Interfaces<a class="anchor" href="#the-new-control-group-interfaces">#</a></h1> <blockquote class='book-hint '> <p><em>aka &ldquo;I want to make use of kernel cgroups, how do I do this in the new world order?&rdquo;</em></p> </blockquote><p>Starting with version 205 systemd provides a number of interfaces that may be used to create and manage labelled groups of processes for the purpose of monitoring and controlling them and their resource usage. This is built on top of the Linux kernel Control Groups (&ldquo;cgroups&rdquo;) facility.</p>http://systemd.cn/docs/TRANSLATORS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/TRANSLATORS/<h1 id="notes-for-translators">Notes for Translators<a class="anchor" href="#notes-for-translators">#</a></h1> <p>systemd depends on the <code>gettext</code> package for multilingual support.</p> <p>You&rsquo;ll find the i18n files in the <code>po/</code> directory.</p> <p>The build system (meson/ninja) can be used to generate a template (<code>*.pot</code>), which can be used to create new translations.</p> <p>It can also merge the template into the existing translations (<code>*.po</code>), to pick up new strings in need of translation.</p> <p>Finally, it is able to compile the translations (to <code>*.gmo</code> files), so that they can be used by systemd software. (This step is also useful to confirm the syntax of the <code>*.po</code> files is correct.)</p>http://systemd.cn/docs/PASSWORD_AGENTS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/PASSWORD_AGENTS/<h1 id="password-agents">Password Agents<a class="anchor" href="#password-agents">#</a></h1> <p>systemd 12 and newer support lightweight password agents which can be used to query the user for system-level passwords or passphrases. These are passphrases that are not related to a specific user, but to some kind of hardware or service. This is used for encrypted hard-disk passphrases or to query passphrases of SSL certificates at web server start-up time. The basic idea is that a system component requesting a password entry can simply drop a simple .ini-style file into <code>/run/systemd/ask-password/</code> which multiple different agents may watch via <code>inotify()</code>, and query the user as necessary. The answer is then sent back to the querier via an <code>AF_UNIX</code>/<code>SOCK_DGRAM</code> socket. Multiple agents might be running at the same time in which case they all should query the user and the agent which answers first wins. Right now systemd ships with the following passphrase agents:</p>http://systemd.cn/docs/PAX_CONTROL_GROUPS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/PAX_CONTROL_GROUPS/<h1 id="pax-controla-groupiana">Pax Controla Groupiana<a class="anchor" href="#pax-controla-groupiana">#</a></h1> <p><em>aka &ldquo;How to behave nicely in the cgroupfs trees&rdquo;</em></p> <p><strong>Important Update: Please consult this document only as a historical reference. It was written under the assumption that the cgroups tree was a shared resource. However, after much discussion this concept has been deemed outdated. The cgroups tree can no longer be considered a shared resource. Instead, a management daemon of some kind needs to arbitrate access to it, and it needs to actively propagate changes between the entities it manages. More specifically, on systemd systems this management daemon is systemd itself, accessible via a number of bus APIs. This means instead of dealing directly with the low-level interfaces of the cgroup file system, please use systemd&rsquo;s high-level APIs as a replacement, see the <a href="http://systemd.cn/CONTROL_GROUP_INTERFACE">New Control Group Interfaces</a> for details. They offer similar functionality.</strong></p>http://systemd.cn/docs/PORTABILITY_AND_STABILITY/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/PORTABILITY_AND_STABILITY/<h1 id="portability-and-stability-promise">Portability and Stability Promise<a class="anchor" href="#portability-and-stability-promise">#</a></h1> <p>We try to keep backward compatibility for public interfaces, and we try to avoid breaking them whenever possible, as described below. We&rsquo;ll try to fix any reported regressions.</p> <p>Occasionally we need to remove some interface or raise the minimum required version of a dependency. In those cases, we&rsquo;ll announce the deprecation and removal plan in NEWS for a future release. The feedback from users and distributions will be taken into account.</p>http://systemd.cn/docs/PORTABLE_SERVICES/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/PORTABLE_SERVICES/<h1 id="portable-services">Portable Services<a class="anchor" href="#portable-services">#</a></h1> <p>systemd (since version 239) supports a concept of &ldquo;Portable Services&rdquo;. &ldquo;Portable Services&rdquo; are a delivery method for services that uses two specific features of container management:</p> <ol> <li> <p>Applications are bundled. I.e. multiple services, their binaries and all their dependencies are packaged in an image, and are run directly from it.</p> </li> <li> <p>Stricter default security policies, i.e. sand-boxing of applications.</p> </li> </ol> <p>The primary tool for interacting with Portable Services is <code>portablectl</code>, and they are managed by the <code>systemd-portabled</code> service. <code>systemd-portabled</code> can run as a system or a user service.</p>http://systemd.cn/docs/DISTRO_PORTING/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/DISTRO_PORTING/<h1 id="porting-systemd-to-new-distributions">Porting systemd To New Distributions<a class="anchor" href="#porting-systemd-to-new-distributions">#</a></h1> <h2 id="howto">HOWTO<a class="anchor" href="#howto">#</a></h2> <p>You need to make the follow changes to adapt systemd to your distribution:</p> <ol> <li> <p>Find the right configure parameters for:</p> <ul> <li><code>-Dloadkeys-path=</code></li> <li><code>-Dsetfont-path=</code></li> <li><code>-Dtty-gid=</code></li> <li><code>-Dntp-servers=</code></li> <li><code>-Ddns-servers=</code></li> <li><code>-Dsupport-url=</code></li> </ul> </li> <li> <p>Try it out.</p> <p>Play around (as an ordinary user) with <code>/usr/lib/systemd/systemd --test --system</code> for a test run of systemd without booting. This will read the unit files and print the initial transaction it would execute during boot-up. This will also inform you about ordering loops and suchlike.</p>http://systemd.cn/docs/PORTING_TO_NEW_ARCHITECTURES/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/PORTING_TO_NEW_ARCHITECTURES/<h1 id="porting-systemd-to-new-architectures">Porting systemd to New Architectures<a class="anchor" href="#porting-systemd-to-new-architectures">#</a></h1> <p>Here&rsquo;s a brief checklist of things to implement when porting systemd to a new architecture.</p> <ol> <li> <p>Patch <a href="https://github.com/systemd/systemd/blob/main/src/basic/architecture.h">src/basic/architecture.h</a> and <a href="https://github.com/systemd/systemd/blob/main/src/basic/architecture.c">src/basic/architecture.c</a> to make your architecture known to systemd. Besides an <code>ARCHITECTURE_XYZ</code> enumeration entry you need to provide an implementation of <code>native_architecture()</code> and <code>uname_architecture()</code>.</p> </li> <li> <p>Patch <a href="https://github.com/systemd/systemd/blob/main/src/shared/gpt.h">src/shared/gpt.h</a> and <a href="https://github.com/systemd/systemd/blob/main/src/shared/gpt.c">src/shared/gpt.c</a> and define a new set of GPT partition type UUIDs for the root file system, <code>/usr/</code> file system, and the matching Verity and Verity signature partitions. Use <code>systemd-id128 new -p</code> to generate new suitable UUIDs you can use for this. Make sure to register your new types in the various functions in <code>gpt.c</code>. Also make sure to update the tables in <a href="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">UAPI.2 Discoverable Partitions Specification</a> and <code>man/systemd-gpt-auto-generator.xml</code> accordingly.</p>http://systemd.cn/docs/PREDICTABLE_INTERFACE_NAMES/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/PREDICTABLE_INTERFACE_NAMES/<h1 id="predictable-network-interface-names">Predictable Network Interface Names<a class="anchor" href="#predictable-network-interface-names">#</a></h1> <p>Starting with v197 systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme (<code>eth0</code>, <code>eth1</code>, <code>wlan0</code>, &hellip;), but should fix real problems.</p> <h2 id="why">Why?<a class="anchor" href="#why">#</a></h2> <p>The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with <code>eth0</code>, <code>eth1</code>, &hellip; to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names <code>eth0</code>, <code>eth1</code> and so on is generally not fixed anymore and it might very well happen that <code>eth0</code> on one boot ends up being <code>eth1</code> on the next. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names.</p>http://systemd.cn/docs/PRESET/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/PRESET/<h1 id="presets">Presets<a class="anchor" href="#presets">#</a></h1> <h2 id="why">Why?<a class="anchor" href="#why">#</a></h2> <p>Different <strong>distributions</strong> have different policies on which services shall be enabled by default when the package they are shipped in is installed. On Fedora all services stay off by default, so that installing a package will not cause a service to be enabled (with some exceptions). On Debian all services are immediately enabled by default, so that installing a package will cause its service(s) to be enabled right-away.</p>http://systemd.cn/docs/DISK-QUOTAS-PROJECTIDS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/DISK-QUOTAS-PROJECTIDS/<h1 id="project-ids-on-systemd-systems">Project IDs on systemd Systems<a class="anchor" href="#project-ids-on-systemd-systems">#</a></h1> <p>Project IDs are needed to enforce disk quotas for Exec Directories. Project IDs are unsigned, 32-bit integers. For disk quota enforcement, the range used is 2147483648 - 4294967294, which is the highest range inspired from <code>UIDS-GUID.md</code>. The range is defined through <code>PROJ_ID_MIN</code> and <code>PROJ_ID_MAX</code> in <code>exec-invoke.c</code>.</p>http://systemd.cn/docs/RANDOM_SEEDS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/RANDOM_SEEDS/<h1 id="random-seeds">Random Seeds<a class="anchor" href="#random-seeds">#</a></h1> <p>systemd can help in a number of ways with providing reliable, high quality random numbers from early boot on.</p> <h2 id="linux-kernel-entropy-pool">Linux Kernel Entropy Pool<a class="anchor" href="#linux-kernel-entropy-pool">#</a></h2> <p>Today&rsquo;s computer systems require random number generators for numerous cryptographic and other purposes. On Linux systems, the kernel&rsquo;s entropy pool is typically used as high-quality source of random numbers. The kernel&rsquo;s entropy pool combines various entropy inputs together, mixes them and provides an API to userspace as well as to internal kernel subsystems to retrieve it.</p>http://systemd.cn/docs/SECURITY/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/SECURITY/<h1 id="reporting-of-security-vulnerabilities">Reporting of Security Vulnerabilities<a class="anchor" href="#reporting-of-security-vulnerabilities">#</a></h1> <p>If you discover a security vulnerability, we&rsquo;d appreciate a non-public disclosure. systemd developers can be contacted privately by creating a new <strong><a href="https://github.com/systemd/systemd/security/advisories/new">Security Advisory on GitHub</a></strong> (preferred) or via the <a href="mailto:systemd-security@redhat.com">systemd-security@redhat.com</a> mailing list. The disclosure will be coordinated with distributions.</p> <p>(The <a href="https://github.com/systemd/systemd/issues">issue tracker</a> and <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel">systemd-devel mailing list</a> are fully public.)</p> <p>Subscription to the Security Advisories and/or systemd-security mailing list is open to <strong>regular systemd contributors and people working in the security teams of various distributions</strong>. Those conditions should be backed by publicly accessible information (ideally, a track of posts and commits from the mail address in question). If you fall into one of those categories and wish to be subscribed, contact the maintainers or submit a <strong><a href="https://www.redhat.com/mailman/listinfo/systemd-security">subscription request</a></strong>.</p>http://systemd.cn/docs/PRESSURE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/PRESSURE/<h1 id="resource-pressure-handling-in-systemd">Resource Pressure Handling in systemd<a class="anchor" href="#resource-pressure-handling-in-systemd">#</a></h1> <p>On Linux the <a href="https://docs.kernel.org/accounting/psi.html">Pressure Stall Information (PSI)</a> Linux kernel interface provides a way to monitor resource pressure — situations where tasks are stalled waiting for a resource to become available. PSI covers three types of resources:</p> <ul> <li> <p><strong>Memory pressure</strong>: tasks are stalled because the system is low on memory and the kernel is busy reclaiming it (e.g. writing out pages to swap or flushing file-backed pages).</p> </li> <li> <p><strong>CPU pressure</strong>: tasks are stalled waiting for CPU time because the CPU is oversubscribed.</p>http://systemd.cn/docs/NETWORK_ONLINE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/NETWORK_ONLINE/<h1 id="network-configuration-synchronization-points">Network Configuration Synchronization Points<a class="anchor" href="#network-configuration-synchronization-points">#</a></h1> <p>systemd provides three target units related to network configuration:</p> <h2 id="network-pre-configuration-network-pretarget">Network pre-configuration: <code>network-pre.target</code><a class="anchor" href="#network-pre-configuration-network-pretarget">#</a></h2> <p><code>network-pre.target</code> is used to order services before any network interfaces start to be configured. Its primary purpose is for usage with firewall services that want to establish a firewall <em>before</em> any network interface is up.</p> <p><code>network-pre.target</code> is a passive unit: it cannot be started directly and it is not pulled in by the network management service, but instead a service that wants to run before it must pull it in. Network management services hence should set <code>After=network-pre.target</code>, but not <code>Wants=network-pre.target</code> or <code>Requires=network-pre.target</code>. Services that want to be run before the network is configured should use <code>Before=network-pre.target</code> and <code>Wants=network-pre.target</code>. This way, unless there&rsquo;s actually a service that needs to be ordered before the network is up, this target is not pulled in, avoiding an unnecessary synchronization point.</p>http://systemd.cn/docs/BUILDING_IMAGES/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/BUILDING_IMAGES/<h1 id="building-images-safely">Building Images Safely<a class="anchor" href="#building-images-safely">#</a></h1> <p>In many scenarios OS installations are shipped as pre-built images, that require no further installation process beyond simple <code>dd</code>-ing the image to disk and booting it up. When building such &ldquo;golden&rdquo; OS images for <code>systemd</code>-based OSes a few points should be taken into account.</p> <p>Most of the points described here are implemented by the <a href="https://github.com/systemd/mkosi"><code>mkosi</code></a> OS image builder developed and maintained by the systemd project. If you are using or working on another image builder it&rsquo;s recommended to keep the following concepts and recommendations in mind.</p>http://systemd.cn/showcases/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/showcases/<div class="book-hero text-center"> <h1 id="at-the-moment-this-page-is-empty">At the moment this page is empty<a class="anchor" href="#at-the-moment-this-page-is-empty">#</a></h1> <div>http://systemd.cn/docs/DAEMON_SOCKET_ACTIVATION/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/DAEMON_SOCKET_ACTIVATION/<h2 id="nginx">nginx<a class="anchor" href="#nginx">#</a></h2> <p>nginx includes an undocumented, internal socket-passing mechanism based on the <code>NGINX</code> environmental variable. It uses this to perform reloads without having to close and reopen its sockets, but it&rsquo;s also useful for socket activation.</p> <p><strong>/etc/nginx/my-nginx.conf</strong></p> <pre tabindex="0"><code>http { server { listen [::]:80 ipv6only=on; listen 80; } }</code></pre><p><strong>/etc/systemd/system/my-nginx.service</strong></p> <pre tabindex="0"><code>[Service] User=nginx Group=nginx Environment=NGINX=3:4; ExecStart=/usr/sbin/nginx -c/etc/nginx/my-nginx.conf PrivateNetwork=true</code></pre><p><strong>/etc/systemd/system/my-nginx.socket</strong></p> <pre tabindex="0"><code>[Socket] ListenStream=80 ListenStream=0.0.0.0:80 BindIPv6Only=ipv6-only [Install] WantedBy=sockets.target</code></pre><h2 id="php-fpm">PHP-FPM<a class="anchor" href="#php-fpm">#</a></h2> <p>Like nginx, PHP-FPM includes a socket-passing mechanism an environmental variable. In PHP-FPM&rsquo;s case, it&rsquo;s <code>FPM_SOCKETS</code>.</p>http://systemd.cn/docs/RELEASE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/RELEASE/<h1 id="steps-to-a-successful-release">Steps to a Successful Release<a class="anchor" href="#steps-to-a-successful-release">#</a></h1> <ol> <li>Add all items to NEWS</li> <li>Update the contributors list in NEWS (<code>ninja -C build git-contrib</code>)</li> <li>Update the time and place in NEWS</li> <li>Update hwdb (<code>ninja -C build update-hwdb</code>, <code>ninja -C build update-hwdb-autosuspend</code>, commit separately).</li> <li>Update syscall numbers (<code>ninja -C build update-syscall-tables update-syscall-header</code>).</li> <li>[RC1] Update library numbers in <code>meson.build</code></li> <li>[RC1] Switch <code>versionrewrite-pattern</code> and <code>versionrewrite-replacement</code> to RC mode in <a href="https://build.opensuse.org/projects/system:systemd/packages/systemd/files/_service?expand=1">https://build.opensuse.org/projects/system:systemd/packages/systemd/files/_service?expand=1</a></li> <li>Update version number in <code>meson.version</code> (e.g. from <code>256~devel</code> to <code>256~rc1</code> or from <code>256~rc3</code> to <code>256</code>). Note that this uses a tilde (~) instead of a hyphen (-) because tildes sort lower in version comparisons according to the <a href="https://uapi-group.org/specifications/specs/version_format_specification/">UAPI.10 Version Format Specification</a>, and we want <code>255~rc1</code> to sort lower than <code>255</code>.</li> <li>Check dbus docs with <code>ninja -C build update-dbus-docs</code></li> <li>Check manpages list with <code>ninja -C build update-man-rules</code></li> <li>Update translation strings (<code>ninja -C build systemd-pot</code>, <code>ninja -C build systemd-update-po</code>) - drop the header comments from <code>systemd.pot</code> + re-add SPDX before committing. If the only change in a file is the &lsquo;POT-Creation-Date&rsquo; field, then ignore that file.</li> <li>Tag the release: <code>version=&quot;v$(sed 's/~/-/g' meson.version)&quot; &amp;&amp; git tag -s &quot;${version}&quot; -m &quot;systemd ${version}&quot;</code> (tildes are replaced with hyphens, because git doesn&rsquo;t accept the former).</li> <li>Do <code>ninja -C build</code></li> <li>Make sure that the version string and package string match: <code>build/systemctl --version</code></li> <li>[FINAL] Close the github milestone and open a new one (<a href="https://github.com/systemd/systemd/milestones">https://github.com/systemd/systemd/milestones</a>)</li> <li>&ldquo;Draft&rdquo; a new release on github (<a href="https://github.com/systemd/systemd/releases/new%29">https://github.com/systemd/systemd/releases/new)</a>, mark &ldquo;This is a pre-release&rdquo; if appropriate.</li> <li>Check that announcement to systemd-devel, with a copy&amp;paste from NEWS, was sent. This should happen automatically.</li> <li>Update IRC topic (<code>/msg chanserv TOPIC #systemd Version NNN released | Online resources https://systemd.io/</code>)</li> <li>[FINAL] Create an empty -stable branch: <code>git push systemd origin/main:refs/heads/v${version}-stable</code>.</li> <li>[FINAL] Edit in the new -stable branch <code>.obs/workflows.yml</code>, changing <code>project</code> from <code>system:systemd</code> to <code>system:systemd:stable</code> and the branch from <code>main</code> to <code>v${version}-stable</code>. This should be backported to older active stable branches too.</li> <li>[FINAL] Build and upload the documentation (on the -stable branch): <code>ninja -C build doc-sync</code></li> <li>[FINAL] Create a new <code>ci/v${version}-stable</code> branch for deb package builds on <a href="https://salsa.debian.org/systemd-team/systemd">https://salsa.debian.org/systemd-team/systemd</a></li> <li>[FINAL] Switch <code>.semaphore/semaphore-runner.sh</code> and <code>mkosi/mkosi.pkgenv/mkosi.conf.d/debian-ubuntu.conf</code> to the new <code>ci/v${version}-stable</code> branch on the -stable branch</li> <li>[FINAL] Switch <code>versionrewrite-pattern</code> and <code>versionrewrite-replacement</code> to release mode in <a href="https://build.opensuse.org/projects/system:systemd/packages/systemd/files/_service?expand=1">https://build.opensuse.org/projects/system:systemd/packages/systemd/files/_service?expand=1</a></li> <li>[FINAL] Change the Github Pages branch to the newly created branch (<a href="https://github.com/systemd/systemd/settings/pages">https://github.com/systemd/systemd/settings/pages</a>) and set the &lsquo;Custom domain&rsquo; to &lsquo;systemd.io&rsquo;</li> <li>[FINAL] Update version number in <code>meson.version</code> to the devel version of the next release (e.g. from <code>256</code> to <code>257~devel</code>)</li> <li>[FINAL] Build and upload the documentation (on the main branch): <code>ninja -C build doc-sync</code></li> </ol> <h1 id="steps-to-a-successful-stable-release">Steps to a Successful Stable Release<a class="anchor" href="#steps-to-a-successful-stable-release">#</a></h1> <ol> <li>Backport at least the commits from all PRs tagged with <code>needs-stable-backport</code> on Github with <code>git cherry-pick -x</code>. Any other commits that fix bugs, change documentation, tests, CI or mkosi can generally be backported as well. Since 256 the stable branches live <a href="https://github.com/systemd/systemd/">here</a>. Stable branches for older releases are available <a href="https://github.com/systemd/systemd-stable/">here</a>. Check each commit to see if it makes sense to backport and check the comments on the PR to see if the author indicated that only specific commits should be backported.</li> <li>Update the version number in <code>meson.version</code> (e.g. from <code>256.2</code> to <code>256.3</code>) (only for 256-stable or newer)</li> <li>Tag the release: <code>version=&quot;v$(cat meson.version)&quot; &amp;&amp; git tag -s &quot;${version}&quot; -m &quot;systemd-stable ${version}&quot;</code> (Fill in the version manually on releases older than 256)</li> </ol>http://systemd.cn/docs/ROOT_STORAGE_DAEMONS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/ROOT_STORAGE_DAEMONS/<h1 id="systemd-and-storage-daemons-for-the-root-file-system">systemd and Storage Daemons for the Root File System<a class="anchor" href="#systemd-and-storage-daemons-for-the-root-file-system">#</a></h1> <p>a.k.a. <em>Pax Cellae pro Radix Arbor</em></p> <p>(or something like that, my Latin is a bit rusty)</p> <p>A number of complex storage technologies on Linux (e.g. RAID, volume management, networked storage) require user space services to run while the storage is active and mountable. This requirement becomes tricky as soon as the root file system of the Linux operating system is stored on such storage technology. Previously no clear path to make this work was available. This text tries to clear up the resulting confusion, and what is now supported and what is not.</p>http://systemd.cn/docs/CODE_OF_CONDUCT/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/CODE_OF_CONDUCT/<h1 id="the-systemd-community-conduct-guidelines">The systemd Community Conduct Guidelines<a class="anchor" href="#the-systemd-community-conduct-guidelines">#</a></h1> <p>This document provides community guidelines for a safe, respectful, productive, and collaborative place for any person who is willing to contribute to systemd. It applies to all “collaborative spaces”, which is defined as community communications channels (such as mailing lists, submitted patches, commit comments, etc.).</p> <ul> <li>Participants will be tolerant of opposing views.</li> <li>Participants must ensure that their language and actions are free of personal attacks and disparaging personal remarks.</li> <li>When interpreting the words and actions of others, participants should always assume good intentions.</li> <li>Behaviour which can be reasonably considered harassment will not be tolerated.</li> </ul> <h2 id="enforcement">Enforcement<a class="anchor" href="#enforcement">#</a></h2> <p>Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at <a href="mailto:systemd-conduct@googlegroups.com">systemd-conduct@googlegroups.com</a>. This team currently consists of David Strauss &laquo;<a href="mailto:systemd-conduct@davidstrauss.net">systemd-conduct@davidstrauss.net</a>&raquo;, Ekaterina Gerasimova (Kat) &laquo;<a href="mailto:Kittykat3756@gmail.com">Kittykat3756@gmail.com</a>&raquo;, and Zbigniew Jędrzejewski-Szmek &laquo;<a href="mailto:zbyszek@in.waw.pl">zbyszek@in.waw.pl</a>&raquo;. In the unfortunate event that you wish to make a complaint against one of the members, you may instead contact any of the other members individually.</p>http://systemd.cn/docs/COREDUMP/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/COREDUMP/<h1 id="systemd-coredump-handling">systemd Coredump Handling<a class="anchor" href="#systemd-coredump-handling">#</a></h1> <h2 id="support-in-the-service-manager-pid-1">Support in the Service Manager (PID 1)<a class="anchor" href="#support-in-the-service-manager-pid-1">#</a></h2> <p>The systemd service manager natively provides coredump handling functionality, as implemented by the Linux kernel. Specifically, PID 1 provides the following functionality:</p> <ol> <li> <p>During very early boot it will raise the <a href="https://man7.org/linux/man-pages/man2/getrlimit.2.html"><code>LIMIT_CORE</code></a> resource limit for itself to infinity (and thus implicitly also all its children). This removes any limits on the size of generated coredumps, for all invoked processes, from earliest boot on. (The Linux kernel sets the limit to 0 by default.)</p>http://systemd.cn/docs/SYSTEMD_FILE_HIERARCHY_REQUIREMENTS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/SYSTEMD_FILE_HIERARCHY_REQUIREMENTS/<h1 id="systemd-file-hierarchy-requirements">systemd File Hierarchy Requirements<a class="anchor" href="#systemd-file-hierarchy-requirements">#</a></h1> <p>There are various attempts to standardize the file system hierarchy of Linux systems. In systemd we leave much of the file system layout open to the operating system, but here&rsquo;s what systemd strictly requires:</p> <ul> <li> <p><code>/</code>, <code>/usr</code>, <code>/etc</code> must be mounted when the host systemd is first invoked. This may be achieved either by using the kernel&rsquo;s built-in root disk mounting (in which case <code>/</code>, <code>/usr</code> and <code>/etc</code> need to be on the same file system), or via an initrd, which could mount the three directories from different sources.</p>http://systemd.cn/docs/OPTIMIZATIONS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/OPTIMIZATIONS/<h1 id="systemd-optimizations">systemd Optimizations<a class="anchor" href="#systemd-optimizations">#</a></h1> <p><em>So you are working on a Linux distribution or appliance and need very fast boot-ups?</em></p> <p>systemd can already offer boot times of &lt; 1s for the Core OS (userspace only, i.e. only the bits controlled by systemd) and &lt; 2s for a complete up-to-date desktop environments on simpler (but modern, i.e. SSDs) laptops if configured properly (examples: <a href="http://git.fenrus.org/tmp/bootchart-20120512-1036.svg">http://git.fenrus.org/tmp/bootchart-20120512-1036.svg</a>).</p> <p>In this page we want to suggest a couple of ideas how to achieve that, and if the resulting boot times do not suffice where we believe room for improvements are that we&rsquo;d like to see implemented sooner or later.</p>http://systemd.cn/docs/ARCHITECTURE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/ARCHITECTURE/<h1 id="the-systemd-repository-architecture">The systemd Repository Architecture<a class="anchor" href="#the-systemd-repository-architecture">#</a></h1> <h2 id="code-map">Code Map<a class="anchor" href="#code-map">#</a></h2> <p>This document provides a high-level overview of the various components of the systemd repository.</p> <h2 id="source-code">Source Code<a class="anchor" href="#source-code">#</a></h2> <p>Directories in <code>src/</code> provide the implementation of all daemons, libraries and command-line tools shipped by the project. There are many, and more are constantly added, so we will not enumerate them all here — the directory names are self-explanatory.</p> <h3 id="shared-code">Shared Code<a class="anchor" href="#shared-code">#</a></h3> <p>The code that is shared between components is split into a few directories, each with a different purpose:</p>http://systemd.cn/docs/BOOT/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/BOOT/<h1 id="systemd-boot-uefi-boot-manager">systemd-boot UEFI Boot Manager<a class="anchor" href="#systemd-boot-uefi-boot-manager">#</a></h1> <p>systemd-boot is a UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu.</p> <p>systemd-boot operates on the EFI System Partition (ESP) only. Configuration file fragments, kernels, initrds, other EFI images need to reside on the ESP.</p> <p>Linux kernels need to be built with CONFIG_EFI_STUB to be able to be directly executed as an EFI image.</p>http://systemd.cn/docs/USERDB_AND_DESKTOPS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/USERDB_AND_DESKTOPS/<h1 id="systemd-homed-and-json-usergroup-record-support-in-desktop-environments"><code>systemd-homed</code> and JSON User/Group Record Support in Desktop Environments<a class="anchor" href="#systemd-homed-and-json-usergroup-record-support-in-desktop-environments">#</a></h1> <p>Starting with version 245, systemd supports a new subsystem <a href="https://www.freedesktop.org/software/systemd/man/latest/systemd-homed.service.html"><code>systemd-homed.service</code></a> for managing regular (&ldquo;human&rdquo;) users and their home directories. Along with it a new concept <code>userdb</code> got merged that brings rich, extensible JSON user/group records, extending the classic UNIX/glibc NSS <code>struct passwd</code>/<code>struct group</code> structures. Both additions are added in a fully backwards compatible way, accessible through <code>getpwnam()</code>/<code>getgrnam()</code>/… (i.e. libc NSS) and PAM as usual, meaning that for basic support no changes in the upper layers of the stack (in particular desktop environments, such as GNOME or KDE) have to be made. However, for better support a number of changes to desktop environments are recommended. A few areas where that applies are discussed below.</p>http://systemd.cn/docs/RESOLVED-VPNS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/RESOLVED-VPNS/<h1 id="systemd-resolvedservice-and-vpns"><code>systemd-resolved.service</code> and VPNs<a class="anchor" href="#systemd-resolvedservice-and-vpns">#</a></h1> <p><code>systemd-resolved.service</code> supports routing lookups for specific domains to specific interfaces. This is useful for hooking up VPN software with systemd-resolved and making sure the exact right lookups end up on the VPN and on the other interfaces.</p> <p>For a verbose explanation of <code>systemd-resolved.service</code>&rsquo;s domain routing logic, see its <a href="https://www.freedesktop.org/software/systemd/man/latest/systemd-resolved.service.html">man page</a>. This document is supposed to provide examples to use the concepts for the specific purpose of managing VPN DNS configuration.</p>http://systemd.cn/docs/TESTING_WITH_SANITIZERS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/TESTING_WITH_SANITIZERS/<h1 id="testing-systemd-using-sanitizers">Testing systemd Using Sanitizers<a class="anchor" href="#testing-systemd-using-sanitizers">#</a></h1> <p>To catch the <em>nastier</em> kind of bugs, you can run your code with <a href="https://clang.llvm.org/docs/AddressSanitizer.html">Address Sanitizer</a> and <a href="https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html">Undefined Behavior Sanitizer</a>. This is mostly done automagically by various CI systems for each PR, but you may want to do it locally as well. The process slightly varies depending on the compiler you want to use and which part of the test suite you want to run.</p> <h2 id="mkosi">mkosi<a class="anchor" href="#mkosi">#</a></h2> <p>To build with sanitizers in mkosi, create a file <code>mkosi/mkosi.local.conf</code> and add the following contents:</p>http://systemd.cn/docs/THE_CASE_FOR_THE_USR_MERGE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/THE_CASE_FOR_THE_USR_MERGE/<h1 id="the-case-for-the-usr-merge">The Case for the /usr Merge<a class="anchor" href="#the-case-for-the-usr-merge">#</a></h1> <p><strong>Why the /usr Merge Makes Sense for Compatibility Reasons</strong></p> <p><em>This is based on the <a href="https://fedoraproject.org/wiki/Features/UsrMove">Fedora feature</a> for the same topic, put together by Harald Hoyer and Kay Sievers. This feature has been implemented successfully in Fedora 17.</em></p> <p>Note that this page discusses a topic that is actually independent of systemd. systemd supports both systems with split and with merged /usr, and the /usr merge also makes sense for systemd-less systems. That said we want to encourage distributions adopting systemd to also adopt the /usr merge.</p>http://systemd.cn/docs/TIPS_AND_TRICKS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/TIPS_AND_TRICKS/<h1 id="tips--tricks">Tips &amp; Tricks<a class="anchor" href="#tips--tricks">#</a></h1> <p>Also check out the <a href="http://systemd.cn/FAQ">Frequently Asked Questions</a>!</p> <h2 id="listing-running-services">Listing running services<a class="anchor" href="#listing-running-services">#</a></h2> <div class="highlight"><pre tabindex="0" style="color:#e2e4e5;background-color:#282a36;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-sh" data-lang="sh"><span style="display:flex;"><span>$ systemctl </span></span><span style="display:flex;"><span>UNIT LOAD ACTIVE SUB JOB DESCRIPTION </span></span><span style="display:flex;"><span>accounts-daemon.service loaded active running Accounts Service </span></span><span style="display:flex;"><span>atd.service loaded active running Job spooling tools </span></span><span style="display:flex;"><span>avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack </span></span><span style="display:flex;"><span>bluetooth.service loaded active running Bluetooth Manager </span></span><span style="display:flex;"><span>colord-sane.service loaded active running Daemon <span style="color:#ff6ac1">for</span> monitoring attached scanners and registering them with colord </span></span><span style="display:flex;"><span>colord.service loaded active running Manage, Install and Generate Color Profiles </span></span><span style="display:flex;"><span>crond.service loaded active running Command Scheduler </span></span><span style="display:flex;"><span>cups.service loaded active running CUPS Printing Service </span></span><span style="display:flex;"><span>dbus.service loaded active running D-Bus System Message Bus </span></span><span style="display:flex;"><span>...</span></span></code></pre></div><h2 id="showing-runtime-status">Showing runtime status<a class="anchor" href="#showing-runtime-status">#</a></h2> <div class="highlight"><pre tabindex="0" style="color:#e2e4e5;background-color:#282a36;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-sh" data-lang="sh"><span style="display:flex;"><span>$ systemctl status udisks2.service </span></span><span style="display:flex;"><span>udisks2.service - Storage Daemon </span></span><span style="display:flex;"><span> Loaded: loaded <span style="color:#ff6ac1">(</span>/usr/lib/systemd/system/udisks2.service; static<span style="color:#ff6ac1">)</span> </span></span><span style="display:flex;"><span> Active: active <span style="color:#ff6ac1">(</span>running<span style="color:#ff6ac1">)</span> since Wed, <span style="color:#ff9f43">27</span> Jun <span style="color:#ff9f43">2012</span> 20:49:25 +0200; <span style="color:#ff9f43">1</span> day and 1h ago </span></span><span style="display:flex;"><span> Main PID: <span style="color:#ff9f43">615</span> <span style="color:#ff6ac1">(</span>udisksd<span style="color:#ff6ac1">)</span> </span></span><span style="display:flex;"><span> CGroup: <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/system/udisks2.service </span></span><span style="display:flex;"><span> └ <span style="color:#ff9f43">615</span> /usr/lib/udisks2/udisksd --no-debug </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span>Jun <span style="color:#ff9f43">27</span> 20:49:25 epsilon udisksd<span style="color:#ff6ac1">[</span>615<span style="color:#ff6ac1">]</span>: udisks daemon version 1.94.0 starting </span></span><span style="display:flex;"><span>Jun <span style="color:#ff9f43">27</span> 20:49:25 epsilon udisksd<span style="color:#ff6ac1">[</span>615<span style="color:#ff6ac1">]</span>: Acquired the name org.freedesktop.UDisks2 on the system message bus</span></span></code></pre></div><h2 id="cgroup-tree">cgroup tree<a class="anchor" href="#cgroup-tree">#</a></h2> <div class="highlight"><pre tabindex="0" style="color:#e2e4e5;background-color:#282a36;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-sh" data-lang="sh"><span style="display:flex;"><span>$ systemd-cgls </span></span><span style="display:flex;"><span>└ system </span></span><span style="display:flex;"><span>├ <span style="color:#ff9f43">1</span> /usr/lib/systemd/systemd --system --deserialize <span style="color:#ff9f43">18</span> </span></span><span style="display:flex;"><span>├ ntpd.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">8471</span> /usr/sbin/ntpd -u ntp:ntp -g </span></span><span style="display:flex;"><span>├ upower.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">798</span> /usr/libexec/upowerd </span></span><span style="display:flex;"><span>├ wpa_supplicant.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">751</span> /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid </span></span><span style="display:flex;"><span>├ nfs-idmap.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">731</span> /usr/sbin/rpc.idmapd </span></span><span style="display:flex;"><span>├ nfs-rquotad.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">753</span> /usr/sbin/rpc.rquotad </span></span><span style="display:flex;"><span>├ nfs-mountd.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">732</span> /usr/sbin/rpc.mountd </span></span><span style="display:flex;"><span>├ nfs-lock.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">704</span> /sbin/rpc.statd </span></span><span style="display:flex;"><span>├ rpcbind.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">680</span> /sbin/rpcbind -w </span></span><span style="display:flex;"><span>├ postfix.service </span></span><span style="display:flex;"><span>│ ├ <span style="color:#ff9f43">859</span> /usr/libexec/postfix/master </span></span><span style="display:flex;"><span>│ ├ <span style="color:#ff9f43">877</span> qmgr -l -t fifo -u </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">32271</span> pickup -l -t fifo -u </span></span><span style="display:flex;"><span>├ colord-sane.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">647</span> /usr/libexec/colord-sane </span></span><span style="display:flex;"><span>├ udisks2.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">615</span> /usr/lib/udisks2/udisksd --no-debug </span></span><span style="display:flex;"><span>├ colord.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">607</span> /usr/libexec/colord </span></span><span style="display:flex;"><span>├ prefdm.service </span></span><span style="display:flex;"><span>│ ├ <span style="color:#ff9f43">567</span> /usr/sbin/gdm-binary -nodaemon </span></span><span style="display:flex;"><span>│ ├ <span style="color:#ff9f43">602</span> /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 </span></span><span style="display:flex;"><span>│ ├ <span style="color:#ff9f43">612</span> /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-O00GPA/database -seat seat0 -nolisten tcp </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">905</span> gdm-session-worker <span style="color:#ff6ac1">[</span>pam/gdm-password<span style="color:#ff6ac1">]</span> </span></span><span style="display:flex;"><span>├ systemd-ask-password-wall.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">645</span> /usr/bin/systemd-tty-ask-password-agent --wall </span></span><span style="display:flex;"><span>├ atd.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">544</span> /usr/sbin/atd -f </span></span><span style="display:flex;"><span>├ ksmtuned.service </span></span><span style="display:flex;"><span>│ ├ <span style="color:#ff9f43">548</span> /bin/bash /usr/sbin/ksmtuned </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">1092</span> sleep <span style="color:#ff9f43">60</span> </span></span><span style="display:flex;"><span>├ dbus.service </span></span><span style="display:flex;"><span>│ ├ <span style="color:#ff9f43">586</span> /bin/dbus-daemon --system --address<span style="color:#ff6ac1">=</span>systemd: --nofork --systemd-activation </span></span><span style="display:flex;"><span>│ ├ <span style="color:#ff9f43">601</span> /usr/libexec/polkit-1/polkitd --no-debug </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">657</span> /usr/sbin/modem-manager </span></span><span style="display:flex;"><span>├ cups.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">508</span> /usr/sbin/cupsd -f </span></span><span style="display:flex;"><span>├ avahi-daemon.service </span></span><span style="display:flex;"><span>│ ├ <span style="color:#ff9f43">506</span> avahi-daemon: running <span style="color:#ff6ac1">[</span>epsilon.local<span style="color:#ff6ac1">]</span> </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">516</span> avahi-daemon: chroot helper </span></span><span style="display:flex;"><span>├ system-setup-keyboard.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">504</span> /usr/bin/system-setup-keyboard </span></span><span style="display:flex;"><span>├ accounts-daemon.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">502</span> /usr/libexec/accounts-daemon </span></span><span style="display:flex;"><span>├ systemd-logind.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">498</span> /usr/lib/systemd/systemd-logind </span></span><span style="display:flex;"><span>├ crond.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">486</span> /usr/sbin/crond -n </span></span><span style="display:flex;"><span>├ NetworkManager.service </span></span><span style="display:flex;"><span>│ ├ <span style="color:#ff9f43">484</span> /usr/sbin/NetworkManager --no-daemon </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">8437</span> /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-wlan0.pid -lf /var/lib/dhclient/dhclient-903b6f6aa7a1-46c8-82a9-7f637dfbb3e4-wlan0.lease -cf /var/run/nm-d... </span></span><span style="display:flex;"><span>├ libvirtd.service </span></span><span style="display:flex;"><span>│ ├ <span style="color:#ff9f43">480</span> /usr/sbin/libvirtd </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">571</span> /sbin/dnsmasq --strict-order --bind-interfaces --pid-file<span style="color:#ff6ac1">=</span>/var/run/libvirt/network/default.pid --conf-file<span style="color:#ff6ac1">=</span> --except-interface lo --listenaddress 192.168.122.1 --dhcp-range 192.168.122.2,1... </span></span><span style="display:flex;"><span>├ bluetooth.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">479</span> /usr/sbin/bluetoothd -n </span></span><span style="display:flex;"><span>├ systemd-udev.service </span></span><span style="display:flex;"><span>│ └ <span style="color:#ff9f43">287</span> /usr/lib/systemd/systemd-udevd </span></span><span style="display:flex;"><span>└ systemd-journald.service </span></span><span style="display:flex;"><span>└ <span style="color:#ff9f43">280</span> /usr/lib/systemd/systemd-journald</span></span></code></pre></div><h3 id="ps-with-cgroups">ps with cgroups<a class="anchor" href="#ps-with-cgroups">#</a></h3> <div class="highlight"><pre tabindex="0" style="color:#e2e4e5;background-color:#282a36;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-sh" data-lang="sh"><span style="display:flex;"><span>$ <span style="color:#ff5c57">alias</span> <span style="color:#ff5c57">psc</span><span style="color:#ff6ac1">=</span><span style="color:#5af78e">&#39;ps xawf -eo pid,user,cgroup,args&#39;</span> </span></span><span style="display:flex;"><span>$ psc </span></span><span style="display:flex;"><span> PID USER CGROUP COMMAND </span></span><span style="display:flex;"><span>... </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">1</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1 /bin/systemd systemd.log_target<span style="color:#ff6ac1">=</span>kmsg systemd.log_level<span style="color:#ff6ac1">=</span>debug <span style="color:#ff5c57">selinux</span><span style="color:#ff6ac1">=</span><span style="color:#ff9f43">0</span> </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">415</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/sysinit.service /sbin/udevd -d </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">928</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/atd.service /usr/sbin/atd -f </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">930</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/ntpd.service /usr/sbin/ntpd -n </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">932</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/crond.service /usr/sbin/crond -n </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">935</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/auditd.service /sbin/auditd -n </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">943</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/auditd.service <span style="color:#5af78e">\_</span> /sbin/audispd </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">964</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/auditd.service <span style="color:#5af78e">\_</span> /usr/sbin/sedispatch </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">937</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/acpid.service /usr/sbin/acpid -f </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">941</span> rpc <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/rpcbind.service /sbin/rpcbind -f </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">944</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -n -c <span style="color:#ff9f43">4</span> </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">947</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/systemd-logger.service /lib/systemd/systemd-logger </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">950</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/cups.service /usr/sbin/cupsd -f </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">955</span> dbus <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/messagebus.service /bin/dbus-daemon --system --address<span style="color:#ff6ac1">=</span>systemd: --nofork --systemd-activation </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">969</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/getty@.service/tty6 /sbin/mingetty tty6 </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">970</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/getty@.service/tty5 /sbin/mingetty tty5 </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">971</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/getty@.service/tty1 /sbin/mingetty tty1 </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">973</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/getty@.service/tty4 /sbin/mingetty tty4 </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">974</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/user/lennart/2 login -- lennart </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">1824</span> lennart <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/user/lennart/2 <span style="color:#5af78e">\_</span> -bash </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">975</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/getty@.service/tty3 /sbin/mingetty tty3 </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">988</span> root <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/polkitd.service /usr/libexec/polkit-1/polkitd </span></span><span style="display:flex;"><span> <span style="color:#ff9f43">994</span> rtkit <span style="color:#ff5c57">name</span><span style="color:#ff6ac1">=</span>systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon </span></span><span style="display:flex;"><span>...</span></span></code></pre></div><h2 id="changing-the-default-boot-target">Changing the Default Boot Target<a class="anchor" href="#changing-the-default-boot-target">#</a></h2> <div class="highlight"><pre tabindex="0" style="color:#e2e4e5;background-color:#282a36;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-sh" data-lang="sh"><span style="display:flex;"><span>$ ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target</span></span></code></pre></div><p>This line makes the multi user target (i.e. full system, but no graphical UI) the default target to boot into. This is kinda equivalent to setting runlevel 3 as the default runlevel on Fedora/sysvinit systems.</p>http://systemd.cn/docs/USER_RECORD_BLOB_DIRS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/USER_RECORD_BLOB_DIRS/<h1 id="user-record-blob-directories">User Record Blob Directories<a class="anchor" href="#user-record-blob-directories">#</a></h1> <p>The blob directories are for storing binary or unstructured data that would otherwise be stored in <a href="http://systemd.cn/USER_RECORD">JSON User Records</a>. For instance, this includes image files such as the user&rsquo;s avatar picture. This data, like most of the user record, will be made publicly available to the system.</p> <p>The JSON User Record specifies the location of the blob directory via the <code>blobDirectory</code> field. If the field is unset, then there is no blob directory and thus no blob files to look for. Note that <code>blobDirectory</code> can exist in the <code>regular</code>, <code>perMachine</code>, and <code>status</code> sections. The blob directory is completely owned and managed by the service that owns the rest of the user record (as specified in the <code>service</code> field).</p>http://systemd.cn/docs/USER_NAMES/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/USER_NAMES/<h1 id="usergroup-name-syntax">User/Group Name Syntax<a class="anchor" href="#usergroup-name-syntax">#</a></h1> <p>The precise set of allowed user and group names on Linux systems is weakly defined. Depending on the distribution a different set of requirements and restrictions on the syntax of user/group names are enforced — on some distributions the accepted syntax is even configurable by the administrator. In the interest of interoperability systemd enforces different rules when processing users/group defined by other subsystems and when defining users/groups itself, following the principle of &ldquo;Be conservative in what you send, be liberal in what you accept&rdquo;. Also in the interest of interoperability systemd will enforce the same rules everywhere and not make them configurable or distribution dependent. The precise rules are described below.</p>http://systemd.cn/docs/USER_GROUP_API/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/USER_GROUP_API/<h1 id="usergroup-record-lookup-api-via-varlink">User/Group Record Lookup API via Varlink<a class="anchor" href="#usergroup-record-lookup-api-via-varlink">#</a></h1> <p>JSON User/Group Records (as described in the <a href="http://systemd.cn/USER_RECORD">JSON User Records</a> and <a href="http://systemd.cn/GROUP_RECORD">JSON Group Records</a> documents) that are defined on the local system may be queried with a <a href="https://varlink.org/">Varlink</a> API. This API takes both the role of what <a href="https://man7.org/linux/man-pages/man3/getpwnam.3.html"><code>getpwnam(3)</code></a> and related calls are for <code>struct passwd</code>, as well as the interfaces modules implementing the <a href="https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html">glibc Name Service Switch (NSS)</a> expose. Or in other words, it both allows applications to efficiently query user/group records from local services, and allows local subsystems to provide user/group records efficiently to local applications.</p>http://systemd.cn/docs/UIDS-GIDS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/UIDS-GIDS/<h1 id="users-groups-uids-and-gids-on-systemd-systems">Users, Groups, UIDs and GIDs on systemd Systems<a class="anchor" href="#users-groups-uids-and-gids-on-systemd-systems">#</a></h1> <p>Here&rsquo;s a summary of the requirements <code>systemd</code> (and Linux) make on UID/GID assignments and their ranges.</p> <p>Note that while in theory UIDs and GIDs are orthogonal concepts they really aren&rsquo;t IRL. With that in mind, when we discuss UIDs below it should be assumed that whatever we say about UIDs applies to GIDs in mostly the same way, and all the special assignments and ranges for UIDs always have mostly the same validity for GIDs too.</p>http://systemd.cn/docs/TEMPORARY_DIRECTORIES/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/TEMPORARY_DIRECTORIES/<h1 id="using-tmp-and-vartmp-safely">Using <code>/tmp/</code> and <code>/var/tmp/</code> Safely<a class="anchor" href="#using-tmp-and-vartmp-safely">#</a></h1> <p><code>/tmp/</code> and <code>/var/tmp/</code> are two world-writable directories Linux systems provide for temporary files. The former is typically on <code>tmpfs</code> and thus backed by RAM/swap, and flushed out on each reboot. The latter is typically a proper, persistent file system, and thus backed by physical storage. This means:</p> <ol> <li> <p><code>/tmp/</code> should be used for smaller, size-bounded files only; <code>/var/tmp/</code> should be used for everything else.</p> </li> <li> <p>Data that shall survive a boot cycle shouldn&rsquo;t be placed in <code>/tmp/</code>.</p>http://systemd.cn/docs/VARLINK/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/VARLINK/<h1 id="general-guideline">General guideline<a class="anchor" href="#general-guideline">#</a></h1> <ul> <li> <p>Varlink field names should use camelCase. This guideline does not apply to well-known and documented configuration options, such as those defined in <a href="https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html">systemd.unit</a>, where existing naming conventions should be preserved for compatibility and clarity.</p> </li> <li> <p>Every field and method should include meaningful documentation. It&rsquo;s acceptable to reference existing documentation where appropriate. Documentation may be omitted only when the meaning is self-evident, even to someone not already familiar with varlink interface/method.</p>http://systemd.cn/docs/VM_INTERFACE/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/VM_INTERFACE/<h1 id="the-vm-interface">The VM Interface<a class="anchor" href="#the-vm-interface">#</a></h1> <p>Also consult <a href="https://systemd.io/WRITING_VM_AND_CONTAINER_MANAGERS">Writing Virtual Machine or Container Managers</a>.</p> <p>systemd has a number of interfaces for interacting with virtual machine managers, when systemd is used inside of a VM. If you work on a VM manager, please consider supporting the following interfaces.</p> <ol> <li> <p>systemd supports passing immutable binary data blobs with limited size and restricted access to services via the <code>ImportCredential=</code>, <code>LoadCredential=</code> and <code>SetCredential=</code> settings. These credentials may be passed into a system via SMBIOS Type 11 vendor strings, see <a href="https://www.freedesktop.org/software/systemd/man/latest/systemd.html">systemd(1)</a> for details. This concept may be used to flexibly configure various facets ot the guest system. See <a href="https://www.freedesktop.org/software/systemd/man/latest/systemd.system-credentials.html">systemd.system-credentials(7)</a> for a list of system credentials implemented by various systemd components.</p>http://systemd.cn/docs/TRANSIENT-SETTINGS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/TRANSIENT-SETTINGS/<h1 id="what-settings-are-currently-available-for-transient-units">What Settings Are Currently Available For Transient Units?<a class="anchor" href="#what-settings-are-currently-available-for-transient-units">#</a></h1> <p>Our intention is to make all settings that are available as unit file settings also available for transient units, through the D-Bus API. At the moment, device, swap, and target units are not supported at all as transient units, but others are pretty well supported.</p> <p>The lists below contain all settings currently available in unit files. The ones currently available in transient units are prefixed with <code>✓</code>.</p>http://systemd.cn/docs/WRITING_DESKTOP_ENVIRONMENTS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/WRITING_DESKTOP_ENVIRONMENTS/<h1 id="writing-desktop-environments">Writing Desktop Environments<a class="anchor" href="#writing-desktop-environments">#</a></h1> <p><em>Or: how to hook up your favorite desktop environment with logind</em></p> <p>systemd&rsquo;s logind service obsoletes ConsoleKit which was previously widely used on Linux distributions. This provides a number of new features, but also requires updating of the Desktop Environment running on it, in a few ways.</p> <p>This document should be read together with <a href="http://systemd.cn/WRITING_DISPLAY_MANAGERS">Writing Display Managers</a> which focuses on the porting work necessary for display managers.</p> <p>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 <a href="https://www.freedesktop.org/software/systemd/man/latest/sd_booted.html">sd_booted()</a> call may be used to determine at runtime whether systemd is used.</p>http://systemd.cn/docs/WRITING_DISPLAY_MANAGERS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/WRITING_DISPLAY_MANAGERS/<h1 id="writing-display-managers">Writing Display Managers<a class="anchor" href="#writing-display-managers">#</a></h1> <p><em>Or: How to hook up your favorite X11 display manager with systemd</em></p> <p>systemd&rsquo;s logind service obsoletes ConsoleKit which was previously widely used on Linux distributions. For X11 display managers the switch to logind requires a minimal amount of porting, however brings a couple of new features: true automatic multi-seat support, proper tracking of session processes, (optional) automatic killing of user processes on logout, a synchronous low-level C API and much simplification.</p>http://systemd.cn/docs/WRITING_NETWORK_CONFIGURATION_MANAGERS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/WRITING_NETWORK_CONFIGURATION_MANAGERS/<h1 id="writing-network-configuration-managers">Writing Network Configuration Managers<a class="anchor" href="#writing-network-configuration-managers">#</a></h1> <p><em>Or: How to hook up your favourite network configuration manager&rsquo;s DNS logic with <code>systemd-resolved</code></em></p> <p><em>(This is a longer explanation how to use some parts of <code>systemd-resolved</code> bus API. If you are just looking for an API reference, consult the <a href="https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.resolve1.html">bus API documentation</a> instead.)</em></p> <p>Since systemd 229 <code>systemd-resolved</code> offers a powerful bus API that may be used by network configuration managers (e.g. NetworkManager, connman, …, but also lower level DHCP, VPN or PPP daemons managing specific interfaces) to pass DNS server and DNSSEC configuration directly to <code>systemd-resolved</code>. Note that <code>systemd-resolved</code> also reads the DNS configuration data in <code>/etc/resolv.conf</code>, for compatibility. However, by passing the DNS configuration directly to <code>systemd-resolved</code> via the bus a couple of benefits are available:</p>http://systemd.cn/docs/WRITING_RESOLVER_CLIENTS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/WRITING_RESOLVER_CLIENTS/<h1 id="writing-resolver-clients">Writing Resolver Clients<a class="anchor" href="#writing-resolver-clients">#</a></h1> <p><em>Or: How to look up hostnames and arbitrary DNS Resource Records via</em> <code>systemd-resolved</code> <em>&rsquo;s bus APIs</em></p> <p><em>(This is a longer explanation how to use some parts of</em> <code>systemd-resolved</code> <em>bus API. If you are just looking for an API reference, consult the <a href="https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.resolve1.html">bus API documentation</a> instead.)</em></p> <p><em><code>systemd-resolved</code></em> provides a set of APIs on the bus for resolving DNS resource records. These are:</p> <ol> <li><em>ResolveHostname()</em> for resolving hostnames to acquire their IP addresses</li> <li><em>ResolveAddress()</em> for the reverse operation: acquire the hostname for an IP address</li> <li><em>ResolveService()</em> for resolving a DNS-SD or SRV service</li> <li><em>ResolveRecord()</em> for resolving arbitrary resource records.</li> </ol> <p>Below you&rsquo;ll find examples for two of these calls, to show how to use them. Note that glibc offers similar (and more portable) calls in <em>getaddrinfo()</em>, <em>getnameinfo()</em> and <em>res_query()</em>. Of these <em>getaddrinfo()</em> and <em>getnameinfo()</em> are directed to the calls above via the <em>nss-resolve</em> NSS module, but <em>req_query()</em> is not. There are a number of reasons why it might be preferable to invoke <code>systemd-resolved</code>&rsquo;s bus calls rather than the glibc APIs:</p>http://systemd.cn/docs/SYSLOG/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/SYSLOG/<h1 id="writing-syslog-daemons-which-cooperate-nicely-with-systemd">Writing syslog Daemons Which Cooperate Nicely With systemd<a class="anchor" href="#writing-syslog-daemons-which-cooperate-nicely-with-systemd">#</a></h1> <p>Here are a few notes on things to keep in mind when you work on a classic BSD syslog daemon for Linux, to ensure that your syslog daemon works nicely together with systemd. If your syslog implementation does not follow these rules, then it will not be compatible with systemd v38 and newer.</p> <p>A few notes in advance: systemd centralizes all log streams in the Journal daemon. Messages coming in via /dev/log, via the native protocol, via STDOUT/STDERR of all services and via the kernel are received in the journal daemon.</p>http://systemd.cn/docs/WRITING_VM_AND_CONTAINER_MANAGERS/Mon, 01 Jan 0001 00:00:00 +0000http://systemd.cn/docs/WRITING_VM_AND_CONTAINER_MANAGERS/<h1 id="writing-vm-and-container-managers">Writing VM and Container Managers<a class="anchor" href="#writing-vm-and-container-managers">#</a></h1> <p><em>Or: How to hook up your favorite VM or container manager with systemd</em></p> <p>Nomenclature: a <em>Virtual Machine</em> shall refer to a system running on virtualized hardware consisting of a full OS with its own kernel. A <em>Container</em> shall refer to a system running on the same shared kernel of the host, but running a mostly complete OS with its own init system. Both kinds of virtualized systems shall collectively be called &ldquo;machines&rdquo;.</p>