+ <para>The following specifiers are interpreted in the
+ Install section: %n, %N, %p, %i, %U, %u, %m, %H, %b, %v.
+ For their meaning see the next section.
+ </para>
+ </refsect1>
+
+ <refsect1>
+ <title>Specifiers</title>
+
+ <para>Many settings resolve specifiers which may be
+ used to write generic unit files referring to runtime
+ or unit parameters that are replaced when the unit
+ files are loaded. The following specifiers are
+ understood:</para>
+
+ <table>
+ <title>Specifiers available in unit files</title>
+ <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+ <colspec colname="spec" />
+ <colspec colname="mean" />
+ <colspec colname="detail" />
+ <thead>
+ <row>
+ <entry>Specifier</entry>
+ <entry>Meaning</entry>
+ <entry>Details</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><literal>%n</literal></entry>
+ <entry>Full unit name</entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry><literal>%N</literal></entry>
+ <entry>Unescaped full unit name</entry>
+ <entry>Same as <literal>%n</literal>, but with escaping undone</entry>
+ </row>
+ <row>
+ <entry><literal>%p</literal></entry>
+ <entry>Prefix name</entry>
+ <entry>For instantiated units, this refers to the string before the <literal>@</literal> character of the unit name. For non-instantiated units, this refers to the name of the unit with the type suffix removed.</entry>
+ </row>
+ <row>
+ <entry><literal>%P</literal></entry>
+ <entry>Unescaped prefix name</entry>
+ <entry>Same as <literal>%p</literal>, but with escaping undone</entry>
+ </row>
+ <row>
+ <entry><literal>%i</literal></entry>
+ <entry>Instance name</entry>
+ <entry>For instantiated units: this is the string between the <literal>@</literal> character and the suffix of the unit name.</entry>
+ </row>
+ <row>
+ <entry><literal>%I</literal></entry>
+ <entry>Unescaped instance name</entry>
+ <entry>Same as <literal>%i</literal>, but with escaping undone</entry>
+ </row>
+ <row>
+ <entry><literal>%f</literal></entry>
+ <entry>Unescaped filename</entry>
+ <entry>This is either the unescaped instance name (if applicable) with <filename>/</filename> prepended (if applicable), or the prefix name prepended with <filename>/</filename>.</entry>
+ </row>
+ <row>
+ <entry><literal>%c</literal></entry>
+ <entry>Control group path of the unit</entry>
+ <entry>This path does not include the <filename>/sys/fs/cgroup/systemd/</filename> prefix.</entry>
+ </row>
+ <row>
+ <entry><literal>%r</literal></entry>
+ <entry>Control group path of the slice the unit is placed in</entry>
+ <entry>This usually maps to the parent cgroup path of <literal>%c</literal>.</entry>
+ </row>
+ <row>
+ <entry><literal>%R</literal></entry>
+ <entry>Root control group path below which slices and units are placed</entry>
+ <entry>For system instances, this resolves to <filename>/</filename>, except in containers, where this maps to the container's root control group path.</entry>
+ </row>
+ <row>
+ <entry><literal>%t</literal></entry>
+ <entry>Runtime directory</entry>
+ <entry>This is either <filename>/run</filename> (for the system manager) or the path <literal>$XDG_RUNTIME_DIR</literal> resolves to (for user managers).</entry>
+ </row>
+ <row>
+ <entry><literal>%u</literal></entry>
+ <entry>User name</entry>
+ <entry>This is the name of the configured user of the unit, or (if none is set) the user running the systemd instance.</entry>
+ </row>
+ <row>
+ <entry><literal>%U</literal></entry>
+ <entry>User UID</entry>
+ <entry>This is the numeric UID of the configured user of the unit, or (if none is set) the user running the systemd user instance. Note that this specifier is not available for units run by the systemd system instance (as opposed to those run by a systemd user instance), unless the user has been configured as a numeric UID in the first place or the configured user is the root user.</entry>
+ </row>
+ <row>
+ <entry><literal>%h</literal></entry>
+ <entry>User home directory</entry>
+ <entry>This is the home directory of the configured user of the unit, or (if none is set) the user running the systemd user instance. Similar to <literal>%U</literal>, this specifier is not available for units run by the systemd system instance, unless the configured user is the root user.</entry>
+ </row>
+ <row>
+ <entry><literal>%s</literal></entry>
+ <entry>User shell</entry>
+ <entry>This is the shell of the configured user of the unit, or (if none is set) the user running the systemd user instance. Similar to <literal>%U</literal>, this specifier is not available for units run by the systemd system instance, unless the configured user is the root user.</entry>
+ </row>
+ <row>
+ <entry><literal>%m</literal></entry>
+ <entry>Machine ID</entry>
+ <entry>The machine ID of the running system, formatted as string. See <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+ </row>
+ <row>
+ <entry><literal>%b</literal></entry>
+ <entry>Boot ID</entry>
+ <entry>The boot ID of the running system, formatted as string. See <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more information.</entry>
+ </row>
+ <row>
+ <entry><literal>%H</literal></entry>
+ <entry>Host name</entry>
+ <entry>The hostname of the running system at the point in time the unit configuation is loaded.</entry>
+ </row>
+ <row>
+ <entry><literal>%v</literal></entry>
+ <entry>Kernel release</entry>
+ <entry>Identical to <command>uname -r</command> output</entry>
+ </row>
+ <row>
+ <entry><literal>%%</literal></entry>
+ <entry>Single percent sign</entry>
+ <entry>Use <literal>%%</literal> in place of <literal>%</literal> to specify a single percent sign.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>Please note that specifiers
+ <literal>%U</literal>, <literal>%h</literal>,
+ <literal>%s</literal> are mostly useless when systemd
+ is running in system mode. PID 1 cannot query the
+ user account database for information, so the
+ specifiers only work as shortcuts for things which are
+ already specified in a different way in the unit
+ file. They are fully functional when systemd is
+ running in <option>--user</option> mode.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Examples</title>
+
+ <example>
+ <title>Allowing units to be enabled</title>
+
+ <para>The following snippet (highlighted)
+ allows a unit (e.g.
+ <filename>foo.service</filename>) to be
+ enabled via
+ <command>systemctl enable</command>:</para>
+
+ <programlisting>[Unit]
+Description=Foo
+
+[Service]
+ExecStart=/usr/sbin/foo-daemon
+
+<emphasis>[Install]</emphasis>
+<emphasis>WantedBy=multi-user.target</emphasis></programlisting>
+
+ <para>After running
+ <command>systemctl enable</command>, a symlink
+ <filename>/etc/systemd/system/multi-user.target.wants/foo.service</filename>
+ linking to the actual unit will be created. It
+ tells systemd to pull in the unit when starting
+ <filename>multi-user.target</filename>. The
+ inverse <command>systemctl disable</command>
+ will remove that symlink again.</para>
+ </example>
+
+ <example>
+ <title>Overriding vendor settings</title>
+
+ <para>There are two methods of overriding
+ vendor settings in unit files: copying the unit
+ file from
+ <filename>/usr/lib/systemd/system</filename>
+ to <filename>/etc/systemd/system</filename> and
+ modifying the chosen settings. Alternatively,
+ one can create a directory named
+ <filename><replaceable>unit</replaceable>.d/</filename>
+ within
+ <filename>/etc/systemd/system</filename> and
+ place a drop-in file
+ <filename><replaceable>name</replaceable>.conf</filename>
+ there that only changes the specific settings
+ one is interested in. Note that multiple such
+ drop-in files are read if present.</para>
+
+ <para>The advantage of the first method is
+ that one easily overrides the complete unit,
+ the vendor unit is not parsed at all anymore.
+ It has the disadvantage that improvements to
+ the unit file by the vendor are not
+ automatically incorporated on updates.</para>
+
+ <para>The advantage of the second method is
+ that one only overrides the settings one
+ specifically wants, where updates to the unit
+ by the vendor automatically apply. This has the
+ disadvantage that some future updates by the
+ vendor might be incompatible with the local
+ changes.</para>
+
+ <para>Note that for drop-in files, if one wants
+ to remove entries from a setting that is parsed
+ as a list (and is not a dependency), such as
+ <varname>ConditionPathExists=</varname> (or
+ e.g. <varname>ExecStart=</varname> in service
+ units), one needs to first clear the list
+ before re-adding all entries except the one
+ that is to be removed. See below for an
+ example.</para>
+
+ <para>This also applies for user instances of
+ systemd, but with different locations for the
+ unit files. See the section on unit load paths
+ for further details.</para>
+
+ <para>Suppose there is a vendor-supplied unit
+ <filename>/usr/lib/systemd/system/httpd.service</filename>
+ with the following contents:</para>
+
+ <programlisting>[Unit]
+Description=Some HTTP server
+After=remote-fs.target sqldb.service
+Requires=sqldb.service
+AssertPathExists=/srv/webserver
+
+[Service]
+Type=notify
+ExecStart=/usr/sbin/some-fancy-httpd-server
+Nice=5
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+ <para>Now one wants to change some settings as
+ an administrator: firstly, in the local setup,
+ <filename>/srv/webserver</filename> might not
+ exit, because the HTTP server is configured to
+ use <filename>/srv/www</filename> instead.
+ Secondly, the local configuration makes the
+ HTTP server also depend on a memory cache
+ service,
+ <filename>memcached.service</filename>, that
+ should be pulled in
+ (<varname>Requires=</varname>) and also be
+ ordered appropriately
+ (<varname>After=</varname>). Thirdly, in order
+ to harden the service a bit more, the
+ administrator would like to set the
+ <varname>PrivateTmp=</varname>
+ setting (see
+ <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details). And lastly, the administrator
+ would like to reset the niceness of the service
+ to its default value of 0.</para>
+
+ <para>The first possibility is to copy the unit
+ file to
+ <filename>/etc/systemd/system/httpd.service</filename>
+ and change the chosen settings:</para>
+
+ <programlisting>[Unit]
+Description=Some HTTP server
+After=remote-fs.target sqldb.service <emphasis>memcached.service</emphasis>
+Requires=sqldb.service <emphasis>memcached.service</emphasis>
+AssertPathExists=<emphasis>/srv/www</emphasis>
+
+[Service]
+Type=notify
+ExecStart=/usr/sbin/some-fancy-httpd-server
+<emphasis>Nice=0</emphasis>
+<emphasis>PrivateTmp=yes</emphasis>
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+ <para>Alternatively, the administrator could
+ create a drop-in file
+ <filename>/etc/systemd/system/httpd.service.d/local.conf</filename>
+ with the following contents:</para>
+
+ <programlisting>[Unit]
+After=memcached.service
+Requires=memcached.service
+# Reset all assertions and then re-add the condition we want
+AssertPathExists=
+AssertPathExists=/srv/www
+
+[Service]
+Nice=0
+PrivateTmp=yes</programlisting>
+
+ <para>Note that dependencies
+ (<varname>After=</varname>, etc.) cannot be
+ reset to an empty list, so dependencies can
+ only be added in drop-ins. If you want to
+ remove dependencies, you have to override the
+ entire unit.</para>
+ </example>