source: chapter09/systemd-custom.xml

trunk
Last change on this file was ea93c11, checked in by Xi Ruoyao <xry111@…>, 3 months ago

treewide: Use <ulink> instead of <filename> for man pages

"gcc(1)" is really not a file name.

Use <ulink> and link to the online man page on
https://man.archlinux.org/ so the user can refer to the man pages more
easily.

The change is done via a sed command and long lines are wrapped
manually.

  • Property mode set to 100644
File size: 12.8 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
4 <!ENTITY % general-entities SYSTEM "../general.ent">
5 %general-entities;
6]>
7
8<sect1 id="ch-config-systemd-custom" revision="systemd">
9 <?dbhtml filename="systemd-custom.html"?>
10
11 <title>Systemd Usage and Configuration</title>
12
13 <indexterm zone="ch-config-systemd-custom">
14 <primary sortas="e-Systemd">Systemd Customization</primary>
15 </indexterm>
16
17 <sect2>
18 <title>Basic Configuration</title>
19
20 <para>The <filename>/etc/systemd/system.conf</filename> file contains a set
21 of options to control basic systemd operations. The default file has all
22 entries commented out with the default settings indicated. This file is
23 where the log level may be changed as well as some basic logging settings.
24 See the <ulink role='man'
25 url='&man;systemd-system.conf.5'>systemd-system.conf(5)</ulink> manual
26 page for details on each configuration option.</para>
27
28 </sect2>
29
30 <sect2>
31 <title>Disabling Screen Clearing at Boot Time</title>
32
33 <para>The normal behavior for systemd is to clear the screen at
34 the end of the boot sequence. If desired, this behavior may be
35 changed by running the following command:</para>
36
37<screen role="nodump"><userinput>mkdir -pv /etc/systemd/system/getty@tty1.service.d
38
39cat &gt; /etc/systemd/system/getty@tty1.service.d/noclear.conf &lt;&lt; EOF
40<literal>[Service]
41TTYVTDisallocate=no</literal>
42EOF</userinput></screen>
43
44 <para>The boot messages can always be reviewed by using the
45 <userinput>journalctl -b</userinput> command as the
46 <systemitem class="username">root</systemitem> user.</para>
47
48 </sect2>
49
50 <sect2 id='systemd-no-tmpfs'>
51 <title>Disabling tmpfs for /tmp</title>
52
53 <para>By default, <filename class="directory">/tmp</filename> is created as
54 a tmpfs. If this is not desired, it can be overridden by executing the
55 following command:</para>
56
57<screen role="nodump"><userinput>ln -sfv /dev/null /etc/systemd/system/tmp.mount</userinput></screen>
58
59 <para>Alternatively, if a separate partition for
60 <filename class="directory">/tmp</filename> is desired, specify that
61 partition in a <filename>/etc/fstab</filename> entry.</para>
62
63 <warning>
64 <para>
65 Do not create the symbolic link above if a separate partition is used
66 for <filename class="directory">/tmp</filename>. This will prevent the
67 root file system (/) from being remounted r/w and make the system
68 unusable when booted.
69 </para>
70 </warning>
71
72 </sect2>
73
74 <sect2>
75 <title>Configuring Automatic File Creation and Deletion</title>
76
77 <para>There are several services that create or delete files or
78 directories:</para>
79
80 <itemizedlist>
81 <listitem><para>systemd-tmpfiles-clean.service</para></listitem>
82 <listitem><para>systemd-tmpfiles-setup-dev.service</para></listitem>
83 <listitem><para>systemd-tmpfiles-setup.service</para></listitem>
84 </itemizedlist>
85
86 <para>The system location for the configuration files is
87 <filename>/usr/lib/tmpfiles.d/*.conf</filename>. The local
88 configuration files are in
89 <filename class="directory">/etc/tmpfiles.d</filename>. Files in
90 <filename class="directory">/etc/tmpfiles.d</filename> override
91 files with the same name in
92 <filename class="directory">/usr/lib/tmpfiles.d</filename>. See
93 <ulink role='man' url='&man;tmpfiles.d.5'>tmpfiles.d(5)</ulink> manual
94 page for file format details.</para>
95
96 <para>
97 Note that the syntax for the
98 <filename>/usr/lib/tmpfiles.d/*.conf</filename> files can be
99 confusing. For example, the default deletion of files in the /tmp directory
100 is located in <filename>/usr/lib/tmpfiles.d/tmp.conf</filename> with
101 the line:
102
103<screen role="nodump">q /tmp 1777 root root 10d</screen>
104
105 The type field, q, discusses creating a subvolume with quotas which
106 is really only applicable to btrfs filesystems. It references type v
107 which in turn references type d (directory). This then creates the
108 specified directory if it is not present and adjusts the permissions
109 and ownership as specified. Contents of the directory will be
110 subject to time based cleanup if the age argument is specified.
111 </para>
112
113 <para>
114 If the default parameters are not desired, then the file should
115 be copied to <filename class="directory">/etc/tmpfiles.d</filename>
116 and edited as desired. For example:
117
118<screen role="nodump"><userinput>mkdir -p /etc/tmpfiles.d
119cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d</userinput></screen>
120 </para>
121
122 </sect2>
123
124 <sect2>
125 <title>Overriding Default Services Behavior</title>
126
127 <para>The parameters of a unit can be overridden by creating a directory
128 and a configuration file in <filename
129 class="directory">/etc/systemd/system</filename>. For example:</para>
130
131<screen role="nodump"><userinput>mkdir -pv /etc/systemd/system/foobar.service.d
132
133cat > /etc/systemd/system/foobar.service.d/foobar.conf &lt;&lt; EOF
134<literal>[Service]
135Restart=always
136RestartSec=30</literal>
137EOF</userinput></screen>
138
139 <para>See <ulink role='man'
140 url='&man;systemd.unit.5'>systemd.unit(5)</ulink> manual page for more
141 information. After creating the configuration file, run
142 <userinput>systemctl daemon-reload</userinput> and <userinput>systemctl
143 restart foobar</userinput> to activate the changes to a service.</para>
144
145 </sect2>
146
147 <sect2>
148 <title>Debugging the Boot Sequence</title>
149
150 <para>Rather than plain shell scripts used in SysVinit or BSD style init
151 systems, systemd uses a unified format for different types of startup
152 files (or units). The command <command>systemctl</command> is used to
153 enable, disable, control state, and obtain status of unit files. Here
154 are some examples of frequently used commands:</para>
155
156 <itemizedlist>
157 <listitem>
158 <para><command>systemctl list-units -t <replaceable>&lt;service&gt;</replaceable> [--all]</command>:
159 lists loaded unit files of type service.</para>
160 </listitem>
161 <listitem>
162 <para><command>systemctl list-units -t <replaceable>&lt;target&gt;</replaceable> [--all]</command>:
163 lists loaded unit files of type target.</para>
164 </listitem>
165 <listitem>
166 <para><command>systemctl show -p Wants <replaceable>&lt;multi-user.target&gt;</replaceable></command>:
167 shows all units that depend on the multi-user target. Targets are
168 special unit files that are analogous to runlevels under
169 SysVinit.</para>
170 </listitem>
171 <listitem>
172 <para><command>systemctl status <replaceable>&lt;servicename.service&gt;</replaceable></command>:
173 shows the status of the servicename service. The .service extension
174 can be omitted if there are no other unit files with the same name,
175 such as .socket files (which create a listening socket that provides
176 similar functionality to inetd/xinetd).</para>
177 </listitem>
178 </itemizedlist>
179
180 </sect2>
181
182 <sect2>
183 <title>Working with the Systemd Journal</title>
184
185 <para>Logging on a system booted with systemd is handled with
186 systemd-journald (by default), rather than a typical unix syslog daemon.
187 You can also add a normal syslog daemon and have both operate side by
188 side if desired. The systemd-journald program stores journal entries in a
189 binary format rather than a plain text log file. To assist with
190 parsing the file, the command <command>journalctl</command> is provided.
191 Here are some examples of frequently used commands:</para>
192
193 <itemizedlist>
194 <listitem>
195 <para><command>journalctl -r</command>: shows all contents of the
196 journal in reverse chronological order.</para>
197 </listitem>
198 <listitem>
199 <para><command>journalctl -u <replaceable>UNIT</replaceable></command>:
200 shows the journal entries associated with the specified UNIT
201 file.</para>
202 </listitem>
203 <listitem>
204 <para><command>journalctl -b[=ID] -r</command>: shows the journal
205 entries since last successful boot (or for boot ID) in reverse
206 chronological order.</para>
207 </listitem>
208 <listitem>
209 <para><command>journalctl -f</command>: provides functionality similar
210 to tail -f (follow).</para>
211 </listitem>
212 </itemizedlist>
213
214 </sect2>
215
216 <sect2>
217 <title>Working with Core Dumps</title>
218
219 <para>Core dumps are useful to debug crashed programs, especially
220 when a daemon process crashes. On systemd booted systems the core
221 dumping is handled by <command>systemd-coredump</command>. It will
222 log the core dump in the journal and store the core dump itself in
223 <filename class="directory">/var/lib/systemd/coredump</filename>.
224 To retrieve and process core dumps, the <command>coredumpctl</command>
225 tool is provided. Here are some examples of frequently used commands:
226 </para>
227
228 <itemizedlist>
229 <listitem>
230 <para><command>coredumpctl -r</command>: lists all core dumps in
231 reverse chronological order.</para>
232 </listitem>
233 <listitem>
234 <para><command>coredumpctl -1 info</command>: shows the information
235 from the last core dump.</para>
236 </listitem>
237 <listitem>
238 <para><command>coredumpctl -1 debug</command>: loads the last core
239 dump into <ulink url="&blfs-book;general/gdb.html">GDB</ulink>.
240 </para>
241 </listitem>
242 </itemizedlist>
243
244 <para>Core dumps may use a lot of disk space. The maximum disk space
245 used by core dumps can be limited by creating a configuration file in
246 <filename class="directory">/etc/systemd/coredump.conf.d</filename>.
247 For example:</para>
248
249<screen role="nodump"><userinput>mkdir -pv /etc/systemd/coredump.conf.d
250
251cat &gt; /etc/systemd/coredump.conf.d/maxuse.conf &lt;&lt; EOF
252<literal>[Coredump]
253MaxUse=5G</literal>
254EOF</userinput></screen>
255
256 <para>See the <ulink role='man' url='&man;systemd-coredump.8'>systemd-coredump(8)</ulink>,
257 <ulink role='man' url='&man;coredumpctl.1'>coredumpctl(1)</ulink>, and
258 <ulink role='man'
259 url='&man;coredump.conf.d.5'>coredump.conf.d(5)</ulink> manual pages for
260 more information.</para>
261 </sect2>
262
263 <sect2>
264 <title>Long Running Processes</title>
265
266 <para>Beginning with systemd-230, all user processes are killed when a user
267 session is ended, even if nohup is used, or the process uses the
268 <function>daemon()</function> or <function>setsid()</function> functions.
269 This is a deliberate change from a historically permissive environment to a
270 more restrictive one. The new behavior may cause issues if you depend on
271 long running programs (e.g., <command>screen</command> or
272 <command>tmux</command>) to remain active after ending your user session.
273 There are three ways to enable lingering processes to remain after a user
274 session is ended.</para>
275
276 <itemizedlist>
277 <listitem>
278 <para>
279 <emphasis>Enable process lingering for only selected users</emphasis>:
280 Normal users have permission to enable process lingering
281 with the command <command>loginctl enable-linger</command> for their
282 own user. System administrators can use the same command with a
283 <parameter>user</parameter> argument to enable for a user. That user
284 can then use the <command>systemd-run</command> command to start
285 long running processes. For example: <command>systemd-run --scope
286 --user /usr/bin/screen</command>. If you enable lingering for your
287 user, the user@.service will remain even after all login sessions are
288 closed, and will automatically start at system boot. This has the
289 advantage of explicitly allowing and disallowing processes to run
290 after the user session has ended, but breaks backwards compatibility
291 with tools like <command>nohup</command> and utilities that use
292 <function>daemon()</function>.
293 </para>
294 </listitem>
295 <listitem>
296 <para>
297 <emphasis>Enable system-wide process lingering</emphasis>:
298 You can set <parameter>KillUserProcesses=no</parameter> in
299 <filename>/etc/systemd/logind.conf</filename> to enable process lingering
300 globally for all users. This has the benefit of leaving the old
301 method available to all users at the expense of explicit control.
302 </para>
303 </listitem>
304 <listitem>
305 <para>
306 <emphasis>Disable at build-time</emphasis>: You can disable
307 lingering by default while building systemd by adding the switch
308 <parameter>-Ddefault-kill-user-processes=false</parameter> to the
309 <command>meson</command> command for systemd. This completely
310 disables the ability of systemd to kill user processes at session
311 end.
312 </para>
313 </listitem>
314 </itemizedlist>
315
316 </sect2>
317
318</sect1>
Note: See TracBrowser for help on using the repository browser.