mirror of
https://github.com/Dasharo/systemd.git
synced 2026-03-06 15:02:31 -08:00
Merge pull request #18827 from keszybz/a-bunch-of-man-page-updates
A bunch of man page updates
This commit is contained in:
Zbigniew Jędrzejewski-Szmek
GitHub
1
TODO
1
TODO
@@ -1272,6 +1272,7 @@ Features:
|
||||
- creating new directories/subvolumes/fifos/device nodes
|
||||
should not follow symlinks. None of the other adjustment or creation
|
||||
calls follow symlinks.
|
||||
- add --test mode
|
||||
|
||||
* make sure systemd-ask-password-wall does not shutdown systemd-ask-password-console too early
|
||||
|
||||
|
||||
@@ -7,6 +7,80 @@
|
||||
<title>Environment</title>
|
||||
|
||||
<variablelist class='environment-variables'>
|
||||
<varlistentry id='log-level'>
|
||||
<term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
|
||||
|
||||
<listitem><para id='log-level-body'>The maximum log level of emitted messages (messages with a higher
|
||||
log level, i.e. less important ones, will be suppressed). Either one of (in order of decreasing
|
||||
importance) <constant>emerg</constant>, <constant>alert</constant>, <constant>crit</constant>,
|
||||
<constant>err</constant>, <constant>warning</constant>, <constant>notice</constant>,
|
||||
<constant>info</constant>, <constant>debug</constant>, or an integer in the range 0…7. See
|
||||
<citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
for more information.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id='log-color'>
|
||||
<term><varname>$SYSTEMD_LOG_COLOR</varname></term>
|
||||
|
||||
<listitem><para id='log-color-body'>A boolean. If true, messages written to the tty will be colored
|
||||
according to priority.</para>
|
||||
|
||||
<para>This setting is only useful when messages are written directly to the terminal, because
|
||||
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> and
|
||||
other tools that display logs will color messages based on the log level on their own.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id='log-time'>
|
||||
<term><varname>$SYSTEMD_LOG_TIME</varname></term>
|
||||
|
||||
<listitem><para id='log-time-body'>A boolean. If true, log messages will be prefixed with a
|
||||
timestamp.</para>
|
||||
|
||||
<para>This setting is only useful when messages are written directly to the terminal or a file, because
|
||||
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> and
|
||||
other tools that display logs will attach timestamps based on the entry metadata on their own.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id='log-location'>
|
||||
<term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
|
||||
|
||||
<listitem><para id='log-location-body'>A boolean. If true, messages will be prefixed with a filename
|
||||
and line number in the source code where the message originates.</para>
|
||||
|
||||
<para>Note that the log location is often attached as metadata to journal entries anyway. Including it
|
||||
directly in the message text can nevertheless be convenient when debugging programs.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id='log-tid'>
|
||||
<term><varname>$SYSTEMD_LOG_TID</varname></term>
|
||||
|
||||
<listitem><para id='log-tid-body'>A boolean. If true, messages will be prefixed with the current
|
||||
numerical thread ID (TID).</para>
|
||||
|
||||
<para>Note that the this information is attached as metadata to journal entries anyway. Including it
|
||||
directly in the message text can nevertheless be convenient when debugging programs.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id='log-target'>
|
||||
<term><varname>$SYSTEMD_LOG_TARGET</varname></term>
|
||||
|
||||
<listitem><para id='log-target-body'>The destination for log messages. One of
|
||||
<constant>console</constant> (log to the attached tty), <constant>console-prefixed</constant> (log to
|
||||
the attached tty but with prefixes encoding the log level and "facility", see <citerefentry
|
||||
project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
||||
<constant>kmsg</constant> (log to the kernel circular log buffer), <constant>journal</constant> (log to
|
||||
the journal), <constant>journal-or-kmsg</constant> (log to the journal if available, and to kmsg
|
||||
otherwise), <constant>auto</constant> (dermine the appropriate log target automatically, the default),
|
||||
<constant>null</constant> (disable log output).</para>
|
||||
<!-- <constant>syslog</constant>, <constant>syslog-or-kmsg</constant> are deprecated -->
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id='pager'>
|
||||
<term><varname>$SYSTEMD_PAGER</varname></term>
|
||||
|
||||
@@ -324,35 +324,47 @@
|
||||
<title>Examples</title>
|
||||
|
||||
<example>
|
||||
<title>List all the core dumps of a program named foo</title>
|
||||
<title>List all the core dumps of a program</title>
|
||||
|
||||
<programlisting># coredumpctl list foo</programlisting>
|
||||
<programlisting>$ coredumpctl list /usr/lib64/firefox/firefox
|
||||
TIME PID UID GID SIG COREFILE EXE SIZE
|
||||
Tue … 8018 1000 1000 SIGSEGV missing /usr/lib64/firefox/firefox n/a
|
||||
Wed … 251609 1000 1000 SIGTRAP missing /usr/lib64/firefox/firefox n/a
|
||||
Fri … 552351 1000 1000 SIGSEGV present /usr/lib64/firefox/firefox 28.7M
|
||||
</programlisting>
|
||||
|
||||
<para>The journal has three entries pertaining to <filename>/usr/lib64/firefox/firefox</filename>, and
|
||||
only the last entry still has an available core file (in external storage on disk).</para>
|
||||
|
||||
<para>Note that <filename>coredumpctl</filename> needs access to the journal files to retrieve the
|
||||
relevant entries from the journal. Thus, an unprivileged user will normally only see information about
|
||||
crashing programs of this user.</para>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>Invoke gdb on the last core dump</title>
|
||||
<title>Invoke <command>gdb</command> on the last core dump</title>
|
||||
|
||||
<programlisting># coredumpctl debug</programlisting>
|
||||
<programlisting>$ coredumpctl debug</programlisting>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>Use gdb to display full register info from the last core dump</title>
|
||||
<title>Use <command>gdb</command> to display full register info from the last core dump</title>
|
||||
|
||||
<programlisting># coredumpctl debug --debugger-arguments="-batch -ex 'info all-registers'"</programlisting>
|
||||
<programlisting>$ coredumpctl debug --debugger-arguments="-batch -ex 'info all-registers'"</programlisting>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>Show information about a process that dumped core,
|
||||
matching by its PID 6654</title>
|
||||
|
||||
<programlisting># coredumpctl info 6654</programlisting>
|
||||
<programlisting>$ coredumpctl info 6654</programlisting>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>Extract the last core dump of /usr/bin/bar to a file named
|
||||
<filename index="false">bar.coredump</filename></title>
|
||||
|
||||
<programlisting># coredumpctl -o bar.coredump dump /usr/bin/bar</programlisting>
|
||||
<programlisting>$ coredumpctl -o bar.coredump dump /usr/bin/bar</programlisting>
|
||||
</example>
|
||||
</refsect1>
|
||||
|
||||
|
||||
@@ -848,7 +848,7 @@
|
||||
<para>On success, 0 is returned, a non-zero failure code otherwise.</para>
|
||||
</refsect1>
|
||||
|
||||
<xi:include href="less-variables.xml" />
|
||||
<xi:include href="common-variables.xml" />
|
||||
|
||||
<refsect1>
|
||||
<title>Examples</title>
|
||||
|
||||
@@ -992,7 +992,7 @@
|
||||
code is returned.</para>
|
||||
</refsect1>
|
||||
|
||||
<xi:include href="less-variables.xml" />
|
||||
<xi:include href="common-variables.xml" />
|
||||
|
||||
<refsect1>
|
||||
<title>Examples</title>
|
||||
|
||||
@@ -185,7 +185,7 @@
|
||||
otherwise.</para>
|
||||
</refsect1>
|
||||
|
||||
<xi:include href="less-variables.xml" />
|
||||
<xi:include href="common-variables.xml" />
|
||||
|
||||
<refsect1>
|
||||
<title>See Also</title>
|
||||
|
||||
@@ -415,7 +415,7 @@ Apr 09 14:40:30 laptop login[2325]: LOGIN ON tty3 BY fatima
|
||||
</example>
|
||||
</refsect1>
|
||||
|
||||
<xi:include href="less-variables.xml" />
|
||||
<xi:include href="common-variables.xml" />
|
||||
|
||||
<refsect1>
|
||||
<title>See Also</title>
|
||||
|
||||
@@ -37,12 +37,10 @@
|
||||
file without implementing a shell compatible execution
|
||||
engine.</para>
|
||||
|
||||
<para><filename>/etc/machine-info</filename> contains metadata
|
||||
about the machine that is set by the user or administrator.</para>
|
||||
|
||||
<para>Depending on the operating system other configuration files
|
||||
might be checked for machine information as well, however only as
|
||||
fallback.</para>
|
||||
<para><filename>/etc/machine-info</filename> contains metadata about the machine that is set by the user
|
||||
or administrator. The settings configured here have the highest precedence. When not set, appropriate
|
||||
values may be determined automatically, based on the information about the hardware or other
|
||||
configuration files. It is thus completely fine for this file to not be present.</para>
|
||||
|
||||
<para>You may use
|
||||
<citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
@@ -102,13 +100,11 @@
|
||||
as well as the special chassis types
|
||||
<literal>vm</literal> and
|
||||
<literal>container</literal> for
|
||||
virtualized systems that lack an immediate physical chassis.
|
||||
Note that many systems allow detection of the chassis type
|
||||
automatically (based on firmware information or suchlike).
|
||||
This setting (if set) shall take precedence over automatically
|
||||
detected information and is useful to override misdetected
|
||||
configuration or to manually configure the chassis type where
|
||||
automatic detection is not available.</para></listitem>
|
||||
virtualized systems that lack an immediate physical chassis.</para>
|
||||
|
||||
<para>Note that most systems allow detection of the chassis type automatically (based on firmware
|
||||
information or suchlike). This setting should only be used to override a misdetection or to manually
|
||||
configure the chassis type where automatic detection is not available.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@@ -980,7 +980,7 @@
|
||||
otherwise.</para>
|
||||
</refsect1>
|
||||
|
||||
<xi:include href="less-variables.xml" />
|
||||
<xi:include href="common-variables.xml" />
|
||||
|
||||
<refsect1>
|
||||
<title>See Also</title>
|
||||
|
||||
@@ -428,7 +428,7 @@
|
||||
<para>On success, 0 is returned, a non-zero failure code otherwise.</para>
|
||||
</refsect1>
|
||||
|
||||
<xi:include href="less-variables.xml" />
|
||||
<xi:include href="common-variables.xml" />
|
||||
|
||||
<refsect1>
|
||||
<title>See Also</title>
|
||||
|
||||
@@ -2407,12 +2407,17 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<xi:include href="less-variables.xml" xpointer="pager"/>
|
||||
<xi:include href="less-variables.xml" xpointer="less"/>
|
||||
<xi:include href="less-variables.xml" xpointer="lesscharset"/>
|
||||
<xi:include href="less-variables.xml" xpointer="lesssecure"/>
|
||||
<xi:include href="less-variables.xml" xpointer="colors"/>
|
||||
<xi:include href="less-variables.xml" xpointer="urlify"/>
|
||||
<xi:include href="common-variables.xml" xpointer="log-level"/>
|
||||
<xi:include href="common-variables.xml" xpointer="log-color"/>
|
||||
<xi:include href="common-variables.xml" xpointer="log-time"/>
|
||||
<xi:include href="common-variables.xml" xpointer="log-location"/>
|
||||
<xi:include href="common-variables.xml" xpointer="log-target"/>
|
||||
<xi:include href="common-variables.xml" xpointer="pager"/>
|
||||
<xi:include href="common-variables.xml" xpointer="less"/>
|
||||
<xi:include href="common-variables.xml" xpointer="lesscharset"/>
|
||||
<xi:include href="common-variables.xml" xpointer="lesssecure"/>
|
||||
<xi:include href="common-variables.xml" xpointer="colors"/>
|
||||
<xi:include href="common-variables.xml" xpointer="urlify"/>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
||||
@@ -782,7 +782,7 @@ Service b@0.service not loaded, b.socket cannot be started.
|
||||
otherwise.</para>
|
||||
</refsect1>
|
||||
|
||||
<xi:include href="less-variables.xml" />
|
||||
<xi:include href="common-variables.xml" />
|
||||
|
||||
<refsect1>
|
||||
<title>See Also</title>
|
||||
|
||||
@@ -32,29 +32,12 @@
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
<para><filename>systemd-coredump@.service</filename> is a system service that can acquire core
|
||||
dumps from the kernel and handle them in various ways. The <command>systemd-coredump</command>
|
||||
executable does the actual work. It is invoked twice: once as the handler by the kernel, and the
|
||||
second time in the <filename>systemd-coredump@.service</filename> to actually write the data to
|
||||
the journal.</para>
|
||||
|
||||
<para>When the kernel invokes <command>systemd-coredump</command> to handle a core dump, it runs
|
||||
in privileged mode, and will connect to the socket created by the
|
||||
<filename>systemd-coredump.socket</filename> unit, which in turn will spawn an unprivileged
|
||||
<filename>systemd-coredump@.service</filename> instance to process the core dump. Hence
|
||||
<filename>systemd-coredump.socket</filename> and <filename>systemd-coredump@.service</filename>
|
||||
are helper units which do the actual processing of core dumps and are subject to normal service
|
||||
management.</para>
|
||||
|
||||
<para>Core dumps can be written to the journal or saved as a file. Once saved they can be retrieved
|
||||
for further processing, for example in
|
||||
<citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
|
||||
</para>
|
||||
|
||||
<para>By default, <command>systemd-coredump</command> will log the core dump including a backtrace
|
||||
if possible to the journal and store the core dump itself in an external file in
|
||||
<filename>/var/lib/systemd/coredump</filename>. These core dumps are deleted after a few days by
|
||||
default; see <filename>/usr/lib/tmpfiles.d/systemd.conf</filename> for details.</para>
|
||||
<para><filename>systemd-coredump@.service</filename> is a system service to process core dumps. It will
|
||||
log a summary of the event to
|
||||
<citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
||||
including information about the process identifier, owner, the signal that killed the process, and the
|
||||
stack trace if possible. It may also save the core dump for later processing. See the "Information about
|
||||
the crashed process" section below.</para>
|
||||
|
||||
<para>The behavior of a specific program upon reception of a signal is governed by a few
|
||||
factors which are described in detail in
|
||||
@@ -62,14 +45,47 @@
|
||||
In particular, the core dump will only be processed when the related resource limits are sufficient.
|
||||
</para>
|
||||
|
||||
<para>It is also possible to invoke <command>systemd-coredump</command> with
|
||||
<option>--backtrace</option> option. In this case, <command>systemd-coredump</command> expects
|
||||
a journal entry in the journal
|
||||
<ulink url="https://www.freedesktop.org/wiki/Software/systemd/export">Journal Export Format</ulink>
|
||||
on standard input. The entry should contain a <varname>MESSAGE=</varname> field and any additional
|
||||
metadata fields the caller deems reasonable. <command>systemd-coredump</command> will append
|
||||
additional metadata fields in the same way it does for core dumps received from the kernel. In
|
||||
this mode, no core dump is stored in the journal.</para>
|
||||
<para>Core dumps can be written to the journal or saved as a file. In both cases, they can be retrieved
|
||||
for further processing, for example in
|
||||
<citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
|
||||
See <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
||||
in particular the <command>list</command> and <command>debug</command> verbs.</para>
|
||||
|
||||
<para>By default, <command>systemd-coredump</command> will log the core dump to the journal, including a
|
||||
backtrace if possible, and store the core dump (an image of the memory contents of the process) itself in
|
||||
an external file in <filename>/var/lib/systemd/coredump</filename>. These core dumps are deleted after a
|
||||
few days by default; see <filename>/usr/lib/tmpfiles.d/systemd.conf</filename> for details. Note that the
|
||||
removal of core files from the file system and the purging of journal entries are independent, and the
|
||||
core file may be present without the journal entry, and journal entries may point to since-removed core
|
||||
files. Metadata is attached to core files in the form of extended attributes, so the core files may be
|
||||
useful even without the full metadata available in the journal entry.
|
||||
</para>
|
||||
|
||||
<refsect2>
|
||||
<title>Invocation of <command>systemd-coredump</command></title>
|
||||
|
||||
<para>The <command>systemd-coredump</command> executable does the actual work. It is invoked twice:
|
||||
once as the handler by the kernel, and the second time in the
|
||||
<filename>systemd-coredump@.service</filename> to actually write the data to the journal and process
|
||||
and save the core file.</para>
|
||||
|
||||
<para>When the kernel invokes <command>systemd-coredump</command> to handle a core dump, it runs in
|
||||
privileged mode, and will connect to the socket created by the
|
||||
<filename>systemd-coredump.socket</filename> unit, which in turn will spawn an unprivileged
|
||||
<filename>systemd-coredump@.service</filename> instance to process the core dump. Hence
|
||||
<filename>systemd-coredump.socket</filename> and <filename>systemd-coredump@.service</filename> are
|
||||
helper units which do the actual processing of core dumps and are subject to normal service
|
||||
management.</para>
|
||||
|
||||
<para>It is also possible to invoke <command>systemd-coredump</command> with
|
||||
<option>--backtrace</option> option. In this case, <command>systemd-coredump</command> expects a
|
||||
journal entry in the journal
|
||||
<ulink url="https://www.freedesktop.org/wiki/Software/systemd/export">Journal Export Format</ulink>
|
||||
on standard input. The entry should contain a <varname>MESSAGE=</varname> field and any additional
|
||||
metadata fields the caller deems reasonable. <command>systemd-coredump</command> will append additional
|
||||
metadata fields in the same way it does for core dumps received from the kernel. In this mode, no core
|
||||
dump is stored in the journal.</para>
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@@ -118,22 +134,241 @@
|
||||
<refsect2>
|
||||
<title>Disabling coredump processing</title>
|
||||
|
||||
<para>To disable potentially resource-intensive processing by <command>systemd-coredump</command>,
|
||||
set <programlisting>Storage=none
|
||||
ProcessSizeMax=0</programlisting> in
|
||||
<para>To disable potentially resource-intensive processing by <command>systemd-coredump</command>, set
|
||||
<programlisting>Storage=none ProcessSizeMax=0</programlisting> in
|
||||
<citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
||||
</para>
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Usage</title>
|
||||
<para>Data stored in the journal can be viewed with
|
||||
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
as usual.
|
||||
<citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
can be used to retrieve saved core dumps independent of their location, to display information and to process
|
||||
them e.g. by passing to the GNU debugger (gdb).</para>
|
||||
<title>Information about the crashed process</title>
|
||||
|
||||
<para><citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> can
|
||||
be used to retrieve saved core dumps independently of their location, to display information, and to
|
||||
process them e.g. by passing to the GNU debugger (gdb).</para>
|
||||
|
||||
<para>Data stored in the journal can be also viewed with
|
||||
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> as usual
|
||||
(or from any other process, using the
|
||||
<citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry> API).
|
||||
The relevant messages have <constant>MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1</constant>:</para>
|
||||
<programlisting>$ journalctl MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 -o verbose
|
||||
…
|
||||
MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1
|
||||
COREDUMP_PID=552351
|
||||
COREDUMP_UID=1000
|
||||
COREDUMP_GID=1000
|
||||
COREDUMP_SIGNAL_NAME=SIGSEGV
|
||||
COREDUMP_SIGNAL=11
|
||||
COREDUMP_TIMESTAMP=1614342930000000
|
||||
COREDUMP_COMM=Web Content
|
||||
COREDUMP_EXE=/usr/lib64/firefox/firefox
|
||||
COREDUMP_USER_UNIT=app-gnome-firefox-552136.scope
|
||||
COREDUMP_CMDLINE=/usr/lib64/firefox/firefox -contentproc -childID 5 -isForBrowser …
|
||||
COREDUMP_CGROUP=/user.slice/user-1000.slice/user@1000.service/app.slice/app-….scope
|
||||
COREDUMP_FILENAME=/var/lib/systemd/coredump/core.Web….552351.….zst
|
||||
…
|
||||
</programlisting>
|
||||
|
||||
<para>The following fields are saved (if known) with the journal entry</para>
|
||||
|
||||
<variablelist class='journal-directives'>
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_UID=</varname></term>
|
||||
<term><varname>COREDUMP_PID=</varname></term>
|
||||
<term><varname>COREDUMP_GID=</varname></term>
|
||||
<listitem><para>The process number (PID) and owner (UID and GID) of the crashed process.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_TIMESTAMP=</varname></term>
|
||||
<listitem><para>The time of the crash as reported by the kernel (in µs since the epoch).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_RLIMIT=</varname></term>
|
||||
<listitem><para>The core file size soft resource limit, see
|
||||
<citerefentry project='man-pages'><refentrytitle>getrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_UNIT=</varname></term>
|
||||
<term><varname>COREDUMP_SLICE=</varname></term>
|
||||
<listitem><para>The system unit and slice names.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_CGROUP=</varname></term>
|
||||
<listitem><para>Control group information in the format used in
|
||||
<filename>/proc/self/cgroup</filename>. On systems with the unified cgroup hierarchy, this is a
|
||||
single path prefixed with <literal>0::</literal>, and multiple paths prefixed with controller numbers
|
||||
on legacy systems.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_OWNER_UID=</varname></term>
|
||||
<term><varname>COREDUMP_USER_UNIT=</varname></term>
|
||||
<listitem><para>The numerical UID of the user owning the login session or systemd user unit of the
|
||||
crashed process, and the user manager unit. Both fields are only present for user processes.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_SIGNAL_NAME=</varname></term>
|
||||
<term><varname>COREDUMP_SIGNAL=</varname></term>
|
||||
|
||||
<listitem><para>The terminating signal name and numerical value. (Both are included because signal
|
||||
numbers vary by architecture.)</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_CWD=</varname></term>
|
||||
<term><varname>COREDUMP_ROOT=</varname></term>
|
||||
|
||||
<listitem><para>The current working directory and root directory of the crashed process.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_OPEN_FDS=</varname></term>
|
||||
|
||||
<listitem><para>Information about open file descriptors, in the following format:</para>
|
||||
<programlisting><replaceable>fd</replaceable>:<replaceable>/path/to/file</replaceable>
|
||||
pos: ...
|
||||
flags: ...
|
||||
...
|
||||
|
||||
<replaceable>fd</replaceable>:<replaceable>/path/to/file</replaceable>
|
||||
pos: ...
|
||||
flags: ...
|
||||
...
|
||||
</programlisting>
|
||||
|
||||
<para>The first line contains the file descriptor number <replaceable>fd</replaceable> and the path,
|
||||
while subsequent lines show the contents of
|
||||
<filename>/proc/<replaceable>pid</replaceable>/fdinfo/<replaceable>fd</replaceable></filename>.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_COMM=</varname></term>
|
||||
<term><varname>COREDUMP_EXE=</varname></term>
|
||||
<term><varname>COREDUMP_PROC_STATUS=</varname></term>
|
||||
<term><varname>COREDUMP_PROC_MAPS=</varname></term>
|
||||
<term><varname>COREDUMP_PROC_LIMITS=</varname></term>
|
||||
<term><varname>COREDUMP_PROC_MOUNTINFO=</varname></term>
|
||||
<term><varname>COREDUMP_ENVIRON=</varname></term>
|
||||
|
||||
<listitem><para>Fields that map the per-process entries in the <filename>/proc/</filename>
|
||||
filesystem: <filename>/proc/<replaceable>pid</replaceable>/comm</filename> (the command name
|
||||
associated with the process), <filename>/proc/<replaceable>pid</replaceable>/exe</filename> (the
|
||||
filename of the executed command), <filename>/proc/<replaceable>pid</replaceable>/status</filename>
|
||||
(various metadata about the process), <filename>/proc/<replaceable>pid</replaceable>/maps</filename>
|
||||
(memory regions visible to the process and their access permissions),
|
||||
<filename>/proc/<replaceable>pid</replaceable>/limits</filename> (the soft and hard resource limits),
|
||||
<filename>/proc/<replaceable>pid</replaceable>/mountinfo</filename> (mount points in the process's
|
||||
mount namespace), <filename>/proc/<replaceable>pid</replaceable>/environ</filename>
|
||||
(the environemnt block of the crashed process).</para>
|
||||
|
||||
<para>See
|
||||
<citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
for more information.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_HOSTNAME=</varname></term>
|
||||
|
||||
<listitem><para>The system hostname.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_CONTAINER_CMDLINE=</varname></term>
|
||||
|
||||
<listitem><para>For processes running in a container, the commandline of the process spawning the
|
||||
container (the first parent process with a different mount namespace).</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP=</varname></term>
|
||||
|
||||
<listitem><para>When the core is stored in the journal, the core image itself.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_FILENAME=</varname></term>
|
||||
|
||||
<listitem><para>When the core is stored externally, the path the the core file.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>COREDUMP_TRUNCATED=</varname></term>
|
||||
|
||||
<listitem><para>Set to <literal>1</literal> when the saved coredump was truncated. (A partial core
|
||||
image may still be processed by some tools, though obviously not all information is available.)
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>MESSAGE=</varname></term>
|
||||
|
||||
<listitem><para>The message generated by <command>systemd-coredump</command> that includes the
|
||||
backtrace if it was successfully generated. When <command>systemd-coredump</command> is invoked with
|
||||
<option>--backtrace</option>, this field is provided by the caller.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>Various other fields exist in the journal entry, but pertain to the logging process,
|
||||
i.e. <command>systemd-coredump</command>, not the crashed process. See
|
||||
<citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
|
||||
</para>
|
||||
|
||||
<para>The following fields are saved (if known) with the external file listed in
|
||||
<varname>COREDUMP_FILENAME=</varname> as extended attributes:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><varname>user.coredump.pid</varname></term>
|
||||
<term><varname>user.coredump.uid</varname></term>
|
||||
<term><varname>user.coredump.gid</varname></term>
|
||||
<term><varname>user.coredump.signal</varname></term>
|
||||
<term><varname>user.coredump.timestamp</varname></term>
|
||||
<term><varname>user.coredump.rlimit</varname></term>
|
||||
<term><varname>user.coredump.hostname</varname></term>
|
||||
<term><varname>user.coredump.comm</varname></term>
|
||||
<term><varname>user.coredump.exe</varname></term>
|
||||
|
||||
<listitem><para>Those are the same as <varname>COREDUMP_PID=</varname>,
|
||||
<varname>COREDUMP_UID=</varname>, <varname>COREDUMP_GID=</varname>,
|
||||
<varname>COREDUMP_SIGNAL=</varname>, <varname>COREDUMP_TIMESTAMP=</varname>,
|
||||
<varname>COREDUMP_RLIMIT=</varname>, <varname>COREDUMP_HOSTNAME=</varname>,
|
||||
<varname>COREDUMP_COMM=</varname>, and <varname>COREDUMP_EXE=</varname>, described above.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>Those can be viewed using
|
||||
<citerefentry project='man-pages'><refentrytitle>getfattr</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
|
||||
For the core file described in the journal entry shown above:
|
||||
<programlisting>$ getfattr --absolute-names -d /var/lib/systemd/coredump/core.Web….552351.….zst
|
||||
# file: /var/lib/systemd/coredump/core.Web….552351.….zst
|
||||
user.coredump.pid="552351"
|
||||
user.coredump.uid="1000"
|
||||
user.coredump.gid="1000"
|
||||
user.coredump.signal="11"
|
||||
user.coredump.timestamp="1614342930000000"
|
||||
user.coredump.comm="Web Content"
|
||||
user.coredump.exe="/usr/lib64/firefox/firefox"
|
||||
…
|
||||
</programlisting>
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
||||
@@ -141,7 +141,7 @@
|
||||
doing so.</para>
|
||||
</refsect1>
|
||||
|
||||
<xi:include href="less-variables.xml" />
|
||||
<xi:include href="common-variables.xml" />
|
||||
|
||||
<refsect1>
|
||||
<title>See Also</title>
|
||||
|
||||
@@ -1486,7 +1486,7 @@
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
||||
<xi:include href="less-variables.xml" />
|
||||
<xi:include href="common-variables.xml" />
|
||||
|
||||
<refsect1>
|
||||
<title>Examples</title>
|
||||
|
||||
@@ -115,8 +115,8 @@
|
||||
<refsect1>
|
||||
<title>Protocols and Routing</title>
|
||||
|
||||
<para>Lookup requests are routed to the available DNS servers, LLMNR, and MulticastDNS interfaces
|
||||
according to the following rules:</para>
|
||||
<para>The lookup requests that <filename>systemd-resolved.service</filename> receives are routed to the
|
||||
available DNS servers, LLMNR, and MulticastDNS interfaces according to the following rules:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Names for which synthetic records are generated (the local hostname,
|
||||
@@ -172,7 +172,8 @@
|
||||
<citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
|
||||
description of globally configured DNS settings.</para>
|
||||
|
||||
<para>The following query routing logic applies for unicast DNS traffic:</para>
|
||||
<para>The following query routing logic applies for unicast DNS lookups initiated by
|
||||
<filename>systemd-resolved.service</filename>:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>If a name to look up matches (that is: is equal to or has as suffix) any of the
|
||||
@@ -228,8 +229,22 @@
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Some names are always resolved internally (see Synthetic Records above). Traditionally
|
||||
they would be resolved by <filename>nss-files</filename>, and only if provided in
|
||||
<filename>/etc/hosts</filename>.</para></listitem>
|
||||
they would be resolved by <filename>nss-files</filename> if provided in
|
||||
<filename>/etc/hosts</filename>. But note that the details of how a query is constructed are under the
|
||||
control of the client library. <filename>nss-dns</filename> will first try to resolve names using
|
||||
search domains and even if those queries are routed to <filename>systemd-resolved</filename>, it will
|
||||
send them out over the network using the usual rules for multi-label name routing <footnote><para>For
|
||||
example, if <filename>/etc/nsswitch.conf</filename> has <programlisting>nameserver 127.0.0.53
|
||||
search foobar.com barbar.com
|
||||
</programlisting>and we look up <literal>localhost</literal>, <filename>nss-dns</filename> will send
|
||||
the following queries to <filename>systemd-resolved</filename> listening on 127.0.0.53:53: first
|
||||
<literal>localhost.foobar.com</literal>, then <literal>localhost.barbar.com</literal>, and finally
|
||||
<literal>localhost</literal>. If (hopefully) the first two queries fail,
|
||||
<filename>systemd-resolved</filename> will synthesize an answer for the third query.</para>
|
||||
|
||||
<para>When using <filename>nss-dns</filename> with any search domains, it is thus crucial to always
|
||||
configure <filename>nss-files</filename> with higher priority and provide mappings for names that
|
||||
should not be resolved using search domains.</para></footnote>.</para></listitem>
|
||||
|
||||
<listitem><para>Single-label names are not resolved for A and AAAA records using unicast DNS (unless
|
||||
overridden with <varname>ResolveUnicastSingleLabel=</varname>, see
|
||||
@@ -246,13 +261,13 @@
|
||||
has failed, as absolute, while other names would be resolved in opposite order. The
|
||||
<varname>ndots</varname> option in <filename>/etc/resolv.conf</filename> was used to control how many
|
||||
dots the name needs to have to be resolved as relative first. This stub resolver does not implement
|
||||
this at all: multi-label names are only resolved as FQDNs. (There are currently more than 1500
|
||||
top-level domain names defined, and new ones are added regularly, often using "attractive" names that
|
||||
are also likely to be used locally. Not looking up multi-label names in this fashion avoids fragility
|
||||
in both directions: a valid global name could be obscured by a local name, and resolution of a relative
|
||||
local name could suddenly break when a new top-level domain is created, or when a new subdomain of a
|
||||
top-level domain in registered. Resolving any given name as either relative or absolute avoids this
|
||||
ambiguity.)</para></listitem>
|
||||
this at all: multi-label names are only resolved as FQDNs.<footnote><para>There are currently more than
|
||||
1500 top-level domain names defined, and new ones are added regularly, often using "attractive" names
|
||||
that are also likely to be used locally. Not looking up multi-label names in this fashion avoids
|
||||
fragility in both directions: a valid global name could be obscured by a local name, and resolution of
|
||||
a relative local name could suddenly break when a new top-level domain is created, or when a new
|
||||
subdomain of a top-level domain in registered. Resolving any given name as either relative or absolute
|
||||
avoids this ambiguity.)</para></footnote></para></listitem>
|
||||
|
||||
<listitem><para>This resolver has a notion of the special <literal>.local</literal> domain used for
|
||||
MulticastDNS, and will not route queries with that suffix to unicast DNS servers unless explicitly
|
||||
|
||||
@@ -60,6 +60,20 @@
|
||||
<citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Environment</title>
|
||||
|
||||
<para>Special variables understood by <command>systemd-sysv-generator</command>:</para>
|
||||
|
||||
<variablelist class='environment-variables'>
|
||||
<varlistentry>
|
||||
<term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
|
||||
|
||||
<listitem><para>Controls where systemd looks for SysV init scripts.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>See Also</title>
|
||||
<para>
|
||||
|
||||
@@ -48,23 +48,20 @@
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para><command>systemd-tmpfiles</command> creates, deletes, and
|
||||
cleans up volatile and temporary files and directories, based on
|
||||
the configuration file format and location specified in
|
||||
<citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
||||
</para>
|
||||
<para><command>systemd-tmpfiles</command> creates, deletes, and cleans up volatile and temporary files
|
||||
and directories, using the configuration file format and location specified in
|
||||
<citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>. It must
|
||||
be invoked with one or more options <option>--create</option>, <option>--remove</option>, and
|
||||
<option>--clean</option>, to select the respective subset of operations.</para>
|
||||
|
||||
<para>If invoked with no arguments, it applies all directives from all configuration
|
||||
files. When invoked with <option>--replace=<replaceable>PATH</replaceable></option>,
|
||||
arguments specified on the command line are used instead of the configuration file
|
||||
<replaceable>PATH</replaceable>. Otherwise, if one or more absolute filenames are
|
||||
passed on the command line, only the directives in these files are applied. If
|
||||
<literal>-</literal> is specified instead of a filename, directives are read from
|
||||
standard input. If only the basename of a configuration file is specified, all
|
||||
configuration directories as specified in
|
||||
<citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
are searched for a matching file and the file found that has the highest priority is
|
||||
executed.</para>
|
||||
<para>By default, directives from all configuration files are applied. When invoked with
|
||||
<option>--replace=<replaceable>PATH</replaceable></option>, arguments specified on the command line are
|
||||
used instead of the configuration file <replaceable>PATH</replaceable>. Otherwise, if one or more
|
||||
absolute filenames are passed on the command line, only the directives in these files are applied. If
|
||||
<literal>-</literal> is specified instead of a filename, directives are read from standard input. If only
|
||||
the basename of a configuration file is specified, all configuration directories as specified in
|
||||
<citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> are
|
||||
searched for a matching file and the file found that has the highest priority is executed.</para>
|
||||
|
||||
<para>System services (<filename>systemd-tmpfiles-setup.service</filename>,
|
||||
<filename>systemd-tmpfiles-setup-dev.service</filename>,
|
||||
@@ -81,6 +78,12 @@
|
||||
system instance, such as the one typically configured for <filename>/tmp/</filename>, will thus also
|
||||
affect files created by the user instance if they are placed in <filename>/tmp/</filename>, even if the
|
||||
user instance's time-based cleanup is turned off.</para>
|
||||
|
||||
<para>To re-apply settings after configuration has been modified, simply restart
|
||||
<filename>systemd-tmpfiles-clean.service</filename>, which will apply any settings which can be safely
|
||||
executed at runtime. To debug <command>systemd-tmpfiles</command>, it may be useful to invoke it
|
||||
directly from the command line with increased log level (see <varname>$SYSTEMD_LOG_LEVEL</varname>
|
||||
below).</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@@ -227,6 +230,24 @@
|
||||
<programlisting>systemd-tmpfiles --remove --create</programlisting>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Environment</title>
|
||||
|
||||
<variablelist class='environment-variables'>
|
||||
<xi:include href="common-variables.xml" xpointer="log-level" />
|
||||
<xi:include href="common-variables.xml" xpointer="log-color" />
|
||||
<xi:include href="common-variables.xml" xpointer="log-time" />
|
||||
<xi:include href="common-variables.xml" xpointer="log-location" />
|
||||
<xi:include href="common-variables.xml" xpointer="log-target" />
|
||||
<xi:include href="common-variables.xml" xpointer="pager" />
|
||||
<xi:include href="common-variables.xml" xpointer="less" />
|
||||
<xi:include href="common-variables.xml" xpointer="lesscharset" />
|
||||
<xi:include href="common-variables.xml" xpointer="lesssecure" />
|
||||
<xi:include href="common-variables.xml" xpointer="colors" />
|
||||
<xi:include href="common-variables.xml" xpointer="urlify" />
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Unprivileged --cleanup operation</title>
|
||||
|
||||
|
||||
@@ -2263,18 +2263,24 @@ SystemCallErrorNumber=EPERM</programlisting>
|
||||
<varlistentry>
|
||||
<term><varname>Environment=</varname></term>
|
||||
|
||||
<listitem><para>Sets environment variables for executed processes. Takes a space-separated list of
|
||||
variable assignments. This option may be specified more than once, in which case all listed variables
|
||||
will be set. If the same variable is set twice, the later setting will override the earlier
|
||||
setting. If the empty string is assigned to this option, the list of environment variables is reset,
|
||||
all prior assignments have no effect. Variable expansion is not performed inside the strings,
|
||||
however, specifier expansion is possible. The <literal>$</literal> character has no special
|
||||
meaning. If you need to assign a value containing spaces or the equals sign to a variable, use double
|
||||
quotes (") for the assignment.</para>
|
||||
<listitem><para>Sets environment variables for executed processes. Each line is unquoted using the
|
||||
rules described in "Quoting" section in
|
||||
<citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
and becomes a list of variable assignments. If you need to assign a value containing spaces or the
|
||||
equals sign to a variable, put quotes around the whole assignment. Variable expansion is not
|
||||
performed inside the strings and the <literal>$</literal> character has no special meaning. Specifier
|
||||
expansion is performed, see the "Specifiers" section in
|
||||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
||||
</para>
|
||||
|
||||
<para>The names of the variables can contain ASCII letters, digits, and the underscore
|
||||
character. Variable names cannot be empty or start with a digit. In variable values, most characters
|
||||
are allowed, but non-printable characters are currently rejected.</para>
|
||||
<para>This option may be specified more than once, in which case all listed variables will be set. If
|
||||
the same variable is listed twice, the later setting will override the earlier setting. If the empty
|
||||
string is assigned to this option, the list of environment variables is reset, all prior assignments
|
||||
have no effect.</para>
|
||||
|
||||
<para>The names of the variables can contain ASCII letters, digits, and the underscore character.
|
||||
Variable names cannot be empty or start with a digit. In variable values, most characters are
|
||||
allowed, but non-printable characters are currently rejected.</para>
|
||||
|
||||
<para>Example:
|
||||
<programlisting>Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"</programlisting>
|
||||
@@ -2284,10 +2290,9 @@ SystemCallErrorNumber=EPERM</programlisting>
|
||||
<literal>word3</literal>, <literal>$word 5 6</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
See <citerefentry
|
||||
project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details
|
||||
about environment variables.</para>
|
||||
<para>See <citerefentry
|
||||
project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
||||
details about environment variables.</para>
|
||||
|
||||
<para>Note that environment variables are not suitable for passing secrets (such as passwords, key
|
||||
material, …) to service processes. Environment variables set for a unit are exposed to unprivileged
|
||||
|
||||
@@ -1107,11 +1107,9 @@
|
||||
</variablelist>
|
||||
|
||||
<para>Check
|
||||
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
and
|
||||
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
for more settings.</para>
|
||||
|
||||
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> and
|
||||
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more
|
||||
settings.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@@ -1126,21 +1124,13 @@
|
||||
<varname>ExecStop=</varname>, and
|
||||
<varname>ExecStopPost=</varname> options.</para>
|
||||
|
||||
<para>Multiple command lines may be concatenated in a single
|
||||
directive by separating them with semicolons (these semicolons
|
||||
must be passed as separate words). Lone semicolons may be escaped
|
||||
as <literal>\;</literal>.</para>
|
||||
<para>Multiple command lines may be concatenated in a single directive by separating them with semicolons
|
||||
(these semicolons must be passed as separate words). Lone semicolons may be escaped as
|
||||
<literal>\;</literal>.</para>
|
||||
|
||||
<para>Each command line is split on whitespace, with the first item being the command to
|
||||
execute, and the subsequent items being the arguments. Double quotes ("…") and single quotes
|
||||
('…') may be used to wrap a whole item (the opening quote may appear only at the beginning or
|
||||
after whitespace that is not quoted, and the closing quote must be followed by whitespace or the
|
||||
end of line), in which case everything until the next matching quote becomes part of the same
|
||||
argument. Quotes themselves are removed. C-style escapes are also supported. The table below
|
||||
contains the list of known escape patterns. Only escape patterns which match the syntax in the
|
||||
table are allowed; other patterns may be added in the future and unknown patterns will result in
|
||||
a warning. In particular, any backslashes should be doubled. Finally, a trailing backslash
|
||||
(<literal>\</literal>) may be used to merge lines.</para>
|
||||
<para>Each command line is unquoted using the rules described in "Quoting" section in
|
||||
<citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
|
||||
first item becomes the command to execute, and the subsequent items the arguments.</para>
|
||||
|
||||
<para>This syntax is inspired by shell syntax, but only the meta-characters and expansions
|
||||
described in the following paragraphs are understood, and the expansion of variables is
|
||||
@@ -1240,74 +1230,6 @@ ls</programlisting>
|
||||
<literal>>/dev/null</literal>,
|
||||
<literal>&</literal>, <literal>;</literal>, and
|
||||
<literal>ls</literal>.</para>
|
||||
|
||||
<table>
|
||||
<title>C escapes supported in command lines and environment variables</title>
|
||||
<tgroup cols='2'>
|
||||
<colspec colname='escape' />
|
||||
<colspec colname='meaning' />
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Literal</entry>
|
||||
<entry>Actual value</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><literal>\a</literal></entry>
|
||||
<entry>bell</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>\b</literal></entry>
|
||||
<entry>backspace</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>\f</literal></entry>
|
||||
<entry>form feed</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>\n</literal></entry>
|
||||
<entry>newline</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>\r</literal></entry>
|
||||
<entry>carriage return</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>\t</literal></entry>
|
||||
<entry>tab</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>\v</literal></entry>
|
||||
<entry>vertical tab</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>\\</literal></entry>
|
||||
<entry>backslash</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>\"</literal></entry>
|
||||
<entry>double quotation mark</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>\'</literal></entry>
|
||||
<entry>single quotation mark</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>\s</literal></entry>
|
||||
<entry>space</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>\x<replaceable>xx</replaceable></literal></entry>
|
||||
<entry>character number <replaceable>xx</replaceable> in hexadecimal encoding</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>\<replaceable>nnn</replaceable></literal></entry>
|
||||
<entry>character number <replaceable>nnn</replaceable> in octal encoding</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user