systemd-custom.xml 13 KB

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