source: chapter07/systemd-custom.xml@ 4d796ca

10.0 10.0-rc1 10.1 10.1-rc1 11.0 11.0-rc1 11.0-rc2 11.0-rc3 cross-chap5 ml-11.0 multilib old-trunk trunk xry111/git-transition xry111/glibc-2.34 xry111/tester-nohack xry111/usr-move
Last change on this file since 4d796ca was 4d796ca, checked in by Xi Ruoyao <xry111@…>, 23 months ago

systemd-custom: add a section discussing core dumps

git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@11781 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

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