source: chapter09/systemd-custom.xml@ 9e7475a

10.0 10.0-rc1 10.1 10.1-rc1 11.0 11.0-rc1 11.0-rc2 11.0-rc3 ml-11.0 multilib trunk xry111/git-transition xry111/glibc-2.34 xry111/tester-nohack xry111/usr-move
Last change on this file since 9e7475a was 9e7475a, checked in by Douglas R. Reno <renodr@…>, 18 months ago

Updates to chapter09 for systemd

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