source: chapter07/systemd-custom.xml@ 1af5572

10.0 10.0-rc1 10.1 10.1-rc1 11.0 11.0-rc1 11.0-rc2 11.0-rc3 8.1 8.1-rc1 8.1-rc2 8.2 8.2-rc1 8.3 8.3-rc1 8.3-rc2 8.4 8.4-rc1 9.0 9.0-rc1 9.1 9.1-rc1 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 1af5572 was 1af5572, checked in by Bruce Dubbs <bdubbs@…>, 5 years ago

More spelling fixes

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

  • Property mode set to 100644
File size: 9.4 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-scripts-systemd-custom" revision="systemd">
9 <?dbhtml filename="systemd-custom.html"?>
11 <title>Systemd Usage and Configuration</title>
13 <indexterm zone="ch-scripts-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 <filename>systemd-system.conf(5)</filename> manual page for details on
25 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 the following:</para>
54<screen role="nodump"><userinput>ln -sfv /dev/null /etc/systemd/system/tmp.mount</userinput></screen>
56 <para>This is not necessary if there is a separate partition for
57 <filename class="directory">/tmp</filename> specified in
58 <filename>/etc/fstab</filename>.</para>
60 </sect2>
62 <sect2>
63 <title>Configuring Automatic File Creation and Deletion</title>
65 <para>There are several services that create or delete files or
66 directories:</para>
68 <itemizedlist>
69 <listitem><para>systemd-tmpfiles-clean.service</para></listitem>
70 <listitem><para>systemd-tmpfiles-setup-dev.service</para></listitem>
71 <listitem><para>systemd-tmpfiles-setup.service</para></listitem>
72 </itemizedlist>
74 <para>The system location for the configuration files is
75 <filename>/usr/lib/tmpfiles.d/*.conf</filename>. The local
76 configuration files are in
77 <filename class="directory">/etc/tmpfiles.d</filename>. Files in
78 <filename class="directory">/etc/tmpfiles.d</filename> override
79 files with the same name in
80 <filename class="directory">/usr/lib/tmpfiles.d</filename>. See
81 <filename>tmpfiles.d(5)</filename> manual page for file format
82 details.</para>
84 </sect2>
86 <sect2>
87 <title>Overriding Default Services Behavior</title>
89 <para>The parameter of a unit can be overriden by creating a directory
90 and a configuration file in <filename
91 class="directory">/etc/systemd/system</filename>. For example:</para>
93<screen role="nodump"><userinput>mkdir -pv /etc/systemd/system/foobar.service.d
95cat > /etc/systemd/system/foobar.service.d/foobar.conf &lt;&lt; EOF
101 <para>See <filename>systemd.unit(5)</filename> manual page for more
102 information. After creating the configuration file, run
103 <userinput>systemctl daemon-reload</userinput> and <userinput>systemctl
104 restart foobar</userinput> to activate the changes to a service.</para>
106 </sect2>
108 <sect2>
109 <title>Debugging the Boot Sequence</title>
111 <para>Rather than plain shell scripts used in SysVinit or BSD style init
112 systems, systemd uses a unified format for different types of startup
113 files (or units). The command <command>systemctl</command> is used to
114 enable, disable, control state, and obtain status of unit files. Here
115 are some examples of frequently used commands:</para>
117 <itemizedlist>
118 <listitem>
119 <para><command>systemctl list-units -t <replaceable>&lt;service&gt;</replaceable> [--all]</command>:
120 lists loaded unit files of type service.</para>
121 </listitem>
122 <listitem>
123 <para><command>systemctl list-units -t <replaceable>&lt;target&gt;</replaceable> [--all]</command>:
124 lists loaded unit files of type target.</para>
125 </listitem>
126 <listitem>
127 <para><command>systemctl show -p Wants <replaceable>&lt;;</replaceable></command>:
128 shows all units that depend on the multi-user target. Targets are
129 special unit files that are anogalous to runlevels under
130 SysVinit.</para>
131 </listitem>
132 <listitem>
133 <para><command>systemctl status <replaceable>&lt;servicename.service&gt;</replaceable></command>:
134 shows the status of the servicename service. The .service extension
135 can be omitted if there are no other unit files with the same name,
136 such as .socket files (which create a listening socket that provides
137 similar functionality to inetd/xinetd).</para>
138 </listitem>
139 </itemizedlist>
141 </sect2>
143 <sect2>
144 <title>Working with the Systemd Journal</title>
146 <para>Logging on a system booted with systemd is handled with
147 systemd-journald (by default), rather than a typical unix syslog daemon.
148 You can also add a normal syslog daemon and have both work side by
149 side if desired. The systemd-journald program stores journal entries in a
150 binary format rather than a plain text log file. To assist with
151 parsing the file, the command <command>journalctl</command> is provided.
152 Here are some examples of frequently used commands:</para>
154 <itemizedlist>
155 <listitem>
156 <para><command>journalctl -r</command>: shows all contents of the
157 journal in reverse chronological order.</para>
158 </listitem>
159 <listitem>
160 <para><command>journalctl -u <replaceable>UNIT</replaceable></command>:
161 shows the journal entries associated with the specified UNIT
162 file.</para>
163 </listitem>
164 <listitem>
165 <para><command>journalctl -b[=ID] -r</command>: shows the journal
166 entries since last successful boot (or for boot ID) in reverse
167 chronological order.</para>
168 </listitem>
169 <listitem>
170 <para><command>journalctl -f</command>: povides functionality similar
171 to tail -f (follow).</para>
172 </listitem>
173 </itemizedlist>
175 </sect2>
177 <sect2>
178 <title>Long Running Processes</title>
180 <para>Beginning with systemd-230, all user processes are killed when a
181 user session is ended, even if nohup is used, or the process uses
182 <function>daemon()</function> or <function>setsid()</function>. This is a
183 deliberate change from a historically permissive environment to a more
184 restrictive one. The new behavior may cause issues if you depend on long
185 running programs (e.g., <command>screen</command> or
186 <command>tmux</command>) to remain active after ending your user
187 session. There are three ways to enable lingering processes to remain after
188 a user session is ended.</para>
190 <itemizedlist>
191 <listitem>
192 <para>
193 <emphasis>Enable process lingering for only needed users</emphasis>:
194 normal users have permission to enable process lingering
195 with the command <command>loginctl enable-linger</command> for their
196 own user. System administrators can use the same command with a
197 <parameter>user</parameter> argument to enable for a user. That user
198 can then use the <command>systemd-run</command> command to start
199 long running processes. For example: <command>systemd-run --scope
200 --user /usr/bin/screen</command>. If you enable lingering for your
201 user, the user@.service will remain even after all login sessions are
202 closed, and will automatically start at system boot. This has the
203 advantage of explicitly allowing and disallowing processes to run
204 after the user session has ended, but breaks backwards compatibility
205 with tools like <command>nohup</command> and utilities that use
206 <function>deamon()</function>.
207 </para>
208 </listitem>
209 <listitem>
210 <para>
211 <emphasis>Enable system-wide process lingering</emphasis>:
212 you can set <parameter>KillUserProcesses=no</parameter> in
213 <filename>/etc/logind.conf</filename> to enable process lingering
214 globally for all users. This has the benefit of leaving the old
215 method available to all users at the expense of explicit control.
216 </para>
217 </listitem>
218 <listitem>
219 <para>
220 <emphasis>Disable at build-time</emphasis>: You can enable
221 lingering by default while building systemd by adding the switch
222 <parameter>--without-kill-user-processes</parameter> to the
223 <command>configure</command> command for systemd. This completely
224 disables the ability of systemd to kill user processes at session
225 end.
226 </para>
227 </listitem>
228 </itemizedlist>
230 </sect2>
Note: See TracBrowser for help on using the repository browser.