source: chapter09/systemd-custom.xml@ 4567d8b

10.0 10.1 10.1-rc1 11.0 11.0-rc1 11.0-rc2 11.0-rc3 11.1 11.1-rc1 11.2 11.2-rc1 11.3 11.3-rc1 12.0 12.0-rc1 arm bdubbs/gcc13 ml-11.0 multilib renodr/libudev-from-systemd s6-init trunk xry111/arm64 xry111/arm64-12.0 xry111/clfs-ng xry111/lfs-next xry111/loongarch xry111/loongarch-12.0 xry111/parallelism xry111/pip3 xry111/rust-wip-20221008
Last change on this file since 4567d8b was 4567d8b, checked in by Bruce Dubbs <bdubbs@…>, 3 years ago


git-svn-id: 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

  • Property mode set to 100644
File size: 12.6 KB
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "" [
4 <!ENTITY % general-entities SYSTEM "../general.ent">
5 %general-entities;
8<sect1 id="ch-config-systemd-custom" revision="systemd">
9 <?dbhtml filename="systemd-custom.html"?>
11 <title>Systemd Usage and Configuration</title>
13 <indexterm zone="ch-config-systemd-custom">
14 <primary sortas="e-Systemd">Systemd Customization</primary>
15 </indexterm>
17 <sect2>
18 <title>Basic Configuration</title>
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>
27 </sect2>
29 <sect2>
30 <title>Disabling Screen Clearing at Boot Time</title>
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>
36<screen role="nodump"><userinput>mkdir -pv /etc/systemd/system/getty@tty1.service.d
38cat &gt; /etc/systemd/system/getty@tty1.service.d/noclear.conf &lt;&lt; EOF
43 <para>The boot messages can always be reviewed by using the
44 <userinput>journalctl -b</userinput> command as the root user.</para>
46 </sect2>
48 <sect2>
49 <title>Disabling tmpfs for /tmp</title>
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>
55<screen role="nodump"><userinput>ln -sfv /dev/null /etc/systemd/system/tmp.mount</userinput></screen>
57 <para>Alternatively, if a separate partition for
58 <filename class="directory">/tmp</filename> is desired, specify that
59 partition in a <filename>/etc/fstab</filename> entry.</para>
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>
70 </sect2>
72 <sect2>
73 <title>Configuring Automatic File Creation and Deletion</title>
75 <para>There are several services that create or delete files or
76 directories:</para>
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>
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>
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:
101<screen role="nodump">q /tmp 1777 root root 10d</screen>
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 it 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>
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:
116<screen role="nodump"><userinput>mkdir -p /etc/tmpfiles.d
117cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d</userinput></screen>
118 </para>
120 </sect2>
122 <sect2>
123 <title>Overriding Default Services Behavior</title>
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>
129<screen role="nodump"><userinput>mkdir -pv /etc/systemd/system/foobar.service.d
131cat > /etc/systemd/system/foobar.service.d/foobar.conf &lt;&lt; EOF
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>
142 </sect2>
144 <sect2>
145 <title>Debugging the Boot Sequence</title>
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>
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;;</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>
177 </sect2>
179 <sect2>
180 <title>Working with the Systemd Journal</title>
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>
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>
211 </sect2>
213 <sect2>
214 <title>Working with Core Dumps</title>
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>
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>
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>
246<screen role="nodump"><userinput>mkdir -pv /etc/systemd/coredump.conf.d
248cat &gt; /etc/systemd/coredump.conf.d/maxuse.conf &lt;&lt; EOF
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>
259 <sect2>
260 <title>Long Running Processes</title>
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>
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>
312 </sect2>
Note: See TracBrowser for help on using the repository browser.