source: chapter09/systemd-custom.xml@ 0be020f

multilib-10.1
Last change on this file since 0be020f was 0be020f, checked in by Thomas Trepl <thomas@…>, 3 years ago

Merge changes from trunk to multilib

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