chapter07/systemd-custom.xml

   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-scripts-systemd-custom" revision="systemd">
   9   <?dbhtml filename="systemd-custom.html"?>
  10
  11   <title>Systemd Usage and Configuration</title>
  12
  13   <indexterm zone="ch-scripts-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 <filename>systemd-system.conf(5)</filename> manual page for details on
  25     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
  38 cat &gt; /etc/systemd/system/getty@tty1.service.d/noclear.conf &lt;&lt; EOF
  39 <literal>[Service]
  40 TTYVTDisallocate=no</literal>
  41 EOF</userinput></screen>
  42
  43     <para>The boot messages can always be revied 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 the following:</para>
  53
  54 <screen role="nodump"><userinput>ln -sfv /dev/null /etc/systemd/system/tmp.mount</userinput></screen>
  55
  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>
  59
  60   </sect2>
  61
  62   <sect2>
  63     <title>Configuring Automatic File Creation and Deletion</title>
  64
  65     <para>There are several services that create or delete files or
  66     directories:</para>
  67
  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>
  73
  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>
  83
  84   </sect2>
  85
  86   <sect2>
  87     <title>Overriding Default Services Behavior</title>
  88
  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>
  92
  93 <screen role="nodump"><userinput>mkdir -pv /etc/systemd/system/foobar.service.d
  94
  95 cat > /etc/systemd/system/foobar.service.d/foobar.conf &lt;&lt; EOF
  96 <literal>[Service]
  97 Restart=always
  98 RestartSec=30</literal>
  99 EOF</userinput></screen>
 100
 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>
 105
 106   </sect2>
 107
 108   <sect2>
 109     <title>Debugging the Boot Sequence</title>
 110
 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, controll state, and obtain status of unit files. Here
 115     are some examples of frequently used commands:</para>
 116
 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;multi-user.target&gt;</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>
 140
 141   </sect2>
 142
 143   <sect2>
 144     <title>Working with the Systemd Journal</title>
 145
 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>
 153
 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 successfull 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>
 174
 175   </sect2>
 176
 177   <sect2>
 178     <title>Long Running Processes</title>
 179
 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>
 189
 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>
 229
 230   </sect2>
 231
 232 </sect1>