<?xml version='1.0'?> <!--*-nxml-*-->
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<!--
- SPDX-License-Identifier: LGPL-2.1+
--->
+<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="systemd-analyze"
xmlns:xi="http://www.w3.org/2001/XInclude">
<arg choice="plain">critical-chain</arg>
<arg choice="opt" rep="repeat"><replaceable>UNIT</replaceable></arg>
</cmdsynopsis>
+
<cmdsynopsis>
<command>systemd-analyze</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
- <arg choice="plain">plot</arg>
- <arg choice="opt">> file.svg</arg>
+ <arg choice="plain">dump</arg>
</cmdsynopsis>
+
<cmdsynopsis>
<command>systemd-analyze</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
- <arg choice="plain">dot</arg>
- <arg choice="opt" rep="repeat"><replaceable>PATTERN</replaceable></arg>
- <arg choice="opt">> file.dot</arg>
+ <arg choice="plain">plot</arg>
+ <arg choice="opt">>file.svg</arg>
</cmdsynopsis>
<cmdsynopsis>
<command>systemd-analyze</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
- <arg choice="plain">dump</arg>
+ <arg choice="plain">dot</arg>
+ <arg choice="opt" rep="repeat"><replaceable>PATTERN</replaceable></arg>
+ <arg choice="opt">>file.dot</arg>
</cmdsynopsis>
+
<cmdsynopsis>
<command>systemd-analyze</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
- <arg choice="plain">cat-config</arg>
- <arg choice="plain" rep="repeat"><replaceable>NAME</replaceable>|<replaceable>PATH</replaceable></arg>
+ <arg choice="plain">unit-paths</arg>
</cmdsynopsis>
<cmdsynopsis>
<command>systemd-analyze</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
- <arg choice="plain">unit-paths</arg>
+ <arg choice="plain">exit-status</arg>
+ <arg choice="opt" rep="repeat"><replaceable>STATUS</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>systemd-analyze</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
- <arg choice="plain">log-level</arg>
- <arg choice="opt"><replaceable>LEVEL</replaceable></arg>
+ <arg choice="plain">condition</arg>
+ <arg choice="plain"><replaceable>CONDITION</replaceable>…</arg>
</cmdsynopsis>
<cmdsynopsis>
<command>systemd-analyze</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
- <arg choice="plain">log-target</arg>
- <arg choice="opt"><replaceable>TARGET</replaceable></arg>
+ <arg choice="plain">syscall-filter</arg>
+ <arg choice="opt"><replaceable>SET</replaceable>…</arg>
</cmdsynopsis>
<cmdsynopsis>
<command>systemd-analyze</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
- <arg choice="plain">syscall-filter</arg>
- <arg choice="opt"><replaceable>SET</replaceable>…</arg>
+ <arg choice="plain">calendar</arg>
+ <arg choice="plain" rep="repeat"><replaceable>SPEC</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>systemd-analyze</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
- <arg choice="plain">verify</arg>
- <arg choice="opt" rep="repeat"><replaceable>FILES</replaceable></arg>
+ <arg choice="plain">timestamp</arg>
+ <arg choice="plain" rep="repeat"><replaceable>TIMESTAMP</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>systemd-analyze</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
- <arg choice="plain">calendar</arg>
- <arg choice="plain" rep="repeat"><replaceable>SPECS</replaceable></arg>
+ <arg choice="plain">timespan</arg>
+ <arg choice="plain" rep="repeat"><replaceable>SPAN</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>systemd-analyze</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
- <arg choice="plain">service-watchdogs</arg>
- <arg choice="opt"><replaceable>BOOL</replaceable></arg>
+ <arg choice="plain">cat-config</arg>
+ <arg choice="plain" rep="repeat"><replaceable>NAME</replaceable>|<replaceable>PATH</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>systemd-analyze</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
- <arg choice="plain">timespan</arg>
- <arg choice="plain" rep="repeat"><replaceable>SPAN</replaceable></arg>
+ <arg choice="plain">verify</arg>
+ <arg choice="opt" rep="repeat"><replaceable>FILE</replaceable></arg>
</cmdsynopsis>
<cmdsynopsis>
<command>systemd-analyze</command>
verify the correctness of unit files. It is also used to access
special functions useful for advanced system manager debugging.</para>
- <para><command>systemd-analyze time</command> prints the time
- spent in the kernel before userspace has been reached, the time
- spent in the initial RAM disk (initrd) before normal system
- userspace has been reached, and the time normal system userspace
- took to initialize. Note that these measurements simply measure
- the time passed up to the point where all system services have
- been spawned, but not necessarily until they fully finished
- initialization or the disk is idle.</para>
-
- <para><command>systemd-analyze blame</command> prints a list of
- all running units, ordered by the time they took to initialize.
- This information may be used to optimize boot-up times. Note that
- the output might be misleading as the initialization of one
- service might be slow simply because it waits for the
- initialization of another service to complete.
- Also note: <command>systemd-analyze blame</command> doesn't display
- results for services with <varname>Type=simple</varname>,
- because systemd considers such services to be started immediately,
- hence no measurement of the initialization delays can be done.</para>
-
- <para><command>systemd-analyze critical-chain
- [<replaceable>UNIT…</replaceable>]</command> prints a tree of
- the time-critical chain of units (for each of the specified
- <replaceable>UNIT</replaceable>s or for the default target
- otherwise). The time after the unit is active or started is
- printed after the "@" character. The time the unit takes to start
- is printed after the "+" character. Note that the output might be
- misleading as the initialization of one service might depend on
- socket activation and because of the parallel execution of
- units.</para>
-
- <para><command>systemd-analyze plot</command> prints an SVG
- graphic detailing which system services have been started at what
- time, highlighting the time they spent on initialization.</para>
-
- <para><command>systemd-analyze dot</command> generates textual
- dependency graph description in dot format for further processing
- with the GraphViz
- <citerefentry project='die-net'><refentrytitle>dot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
- tool. Use a command line like <command>systemd-analyze dot | dot
- -Tsvg > systemd.svg</command> to generate a graphical dependency
- tree. Unless <option>--order</option> or
- <option>--require</option> is passed, the generated graph will
- show both ordering and requirement dependencies. Optional pattern
- globbing style specifications (e.g. <filename>*.target</filename>)
- may be given at the end. A unit dependency is included in the
- graph if any of these patterns match either the origin or
- destination node.</para>
-
- <para><command>systemd-analyze dump</command> outputs a (usually
- very long) human-readable serialization of the complete server
- state. Its format is subject to change without notice and should
- not be parsed by applications.</para>
-
- <para><command>systemd-analyze cat-config</command> is similar
- to <command>systemctl cat</command>, but operates on config files.
- It will copy the contents of a config file and any drop-ins to standard
- output, using the usual systemd set of directories and rules for
- precedence. Each argument must be either an absolute path including
- the prefix (such as <filename>/etc/systemd/logind.conf</filename> or
- <filename>/usr/lib/systemd/logind.conf</filename>), or a name
- relative to the prefix (such as <filename>systemd/logind.conf</filename>).
- </para>
+ <para>If no command is passed, <command>systemd-analyze
+ time</command> is implied.</para>
- <example>
- <title>Showing logind configuration</title>
- <programlisting>$ systemd-analyze cat-config systemd/logind.conf
+ <refsect2>
+ <title><command>systemd-analyze time</command></title>
+
+ <para>This command prints the time spent in the kernel before userspace has been reached, the time
+ spent in the initial RAM disk (initrd) before normal system userspace has been reached, and the time
+ normal system userspace took to initialize. Note that these measurements simply measure the time passed
+ up to the point where all system services have been spawned, but not necessarily until they fully
+ finished initialization or the disk is idle.</para>
+
+ <example>
+ <title><command>Show how long the boot took</command></title>
+
+ <programlisting># in a container
+$ systemd-analyze time
+Startup finished in 296ms (userspace)
+multi-user.target reached after 275ms in userspace
+
+# on a real machine
+$ systemd-analyze time
+Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s
+multi-user.target reached after 47.820s in userspace
+</programlisting>
+ </example>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze blame</command></title>
+
+ <para>This command prints a list of all running units, ordered by the time they took to initialize.
+ This information may be used to optimize boot-up times. Note that the output might be misleading as the
+ initialization of one service might be slow simply because it waits for the initialization of another
+ service to complete. Also note: <command>systemd-analyze blame</command> doesn't display results for
+ services with <varname>Type=simple</varname>, because systemd considers such services to be started
+ immediately, hence no measurement of the initialization delays can be done. Also note that this command
+ only shows the time units took for starting up, it does not show how long unit jobs spent in the
+ execution queue. In particular it shows the time units spent in <literal>activating</literal> state,
+ which is not defined for units such as device units that transition directly from
+ <literal>inactive</literal> to <literal>active</literal>. This command hence gives an impression of the
+ performance of program code, but cannot accurately reflect latency introduced by waiting for
+ hardware and similar events.</para>
+
+ <example>
+ <title><command>Show which units took the most time during boot</command></title>
+
+ <programlisting>$ systemd-analyze blame
+ 32.875s pmlogger.service
+ 20.905s systemd-networkd-wait-online.service
+ 13.299s dev-vda1.device
+ ...
+ 23ms sysroot.mount
+ 11ms initrd-udevadm-cleanup-db.service
+ 3ms sys-kernel-config.mount
+ </programlisting>
+ </example>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze critical-chain <optional><replaceable>UNIT</replaceable>...</optional></command></title>
+
+ <para>This command prints a tree of the time-critical chain of units (for each of the specified
+ <replaceable>UNIT</replaceable>s or for the default target otherwise). The time after the unit is
+ active or started is printed after the "@" character. The time the unit takes to start is printed after
+ the "+" character. Note that the output might be misleading as the initialization of services might
+ depend on socket activation and because of the parallel execution of units. Also, similar to the
+ <command>blame</command> command, this only takes into account the time units spent in
+ <literal>activating</literal> state, and hence does not cover units that never went through an
+ <literal>activating</literal> state (such as device units that transition directly from
+ <literal>inactive</literal> to <literal>active</literal>). Moreover it does not show information on
+ jobs (and in particular not jobs that timed out).</para>
+
+ <example>
+ <title><command>systemd-analyze critical-chain</command></title>
+
+ <programlisting>$ systemd-analyze critical-chain
+multi-user.target @47.820s
+└─pmie.service @35.968s +548ms
+ └─pmcd.service @33.715s +2.247s
+ └─network-online.target @33.712s
+ └─systemd-networkd-wait-online.service @12.804s +20.905s
+ └─systemd-networkd.service @11.109s +1.690s
+ └─systemd-udevd.service @9.201s +1.904s
+ └─systemd-tmpfiles-setup-dev.service @7.306s +1.776s
+ └─kmod-static-nodes.service @6.976s +177ms
+ └─systemd-journald.socket
+ └─system.slice
+ └─-.slice
+</programlisting>
+ </example>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze dump</command></title>
+
+ <para>This command outputs a (usually very long) human-readable serialization of the complete server
+ state. Its format is subject to change without notice and should not be parsed by applications.</para>
+
+ <example>
+ <title>Show the internal state of user manager</title>
+
+ <programlisting>$ systemd-analyze --user dump
+Timestamp userspace: Thu 2019-03-14 23:28:07 CET
+Timestamp finish: Thu 2019-03-14 23:28:07 CET
+Timestamp generators-start: Thu 2019-03-14 23:28:07 CET
+Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET
+Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET
+Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET
+-> Unit proc-timer_list.mount:
+ Description: /proc/timer_list
+ ...
+-> Unit default.target:
+ Description: Main user target
+...
+</programlisting>
+ </example>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze plot</command></title>
+
+ <para>This command prints an SVG graphic detailing which system services have been started at what
+ time, highlighting the time they spent on initialization.</para>
+
+ <example>
+ <title><command>Plot a bootchart</command></title>
+
+ <programlisting>$ systemd-analyze plot >bootup.svg
+$ eog bootup.svg&
+</programlisting>
+ </example>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze dot [<replaceable>pattern</replaceable>...]</command></title>
+
+ <para>This command generates textual dependency graph description in dot format for further processing
+ with the GraphViz
+ <citerefentry project='die-net'><refentrytitle>dot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ tool. Use a command line like <command>systemd-analyze dot | dot -Tsvg >systemd.svg</command> to
+ generate a graphical dependency tree. Unless <option>--order</option> or <option>--require</option> is
+ passed, the generated graph will show both ordering and requirement dependencies. Optional pattern
+ globbing style specifications (e.g. <filename>*.target</filename>) may be given at the end. A unit
+ dependency is included in the graph if any of these patterns match either the origin or destination
+ node.</para>
+
+ <example>
+ <title>Plot all dependencies of any unit whose name starts with <literal>avahi-daemon</literal>
+ </title>
+
+ <programlisting>$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg
+$ eog avahi.svg</programlisting>
+ </example>
+
+ <example>
+ <title>Plot the dependencies between all known target units</title>
+
+ <programlisting>$ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' \
+ | dot -Tsvg >targets.svg
+$ eog targets.svg</programlisting>
+ </example>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze unit-paths</command></title>
+
+ <para>This command outputs a list of all directories from which unit files, <filename>.d</filename>
+ overrides, and <filename>.wants</filename>, <filename>.requires</filename> symlinks may be
+ loaded. Combine with <option>--user</option> to retrieve the list for the user manager instance, and
+ <option>--global</option> for the global configuration of user manager instances.</para>
+
+ <example>
+ <title><command>Show all paths for generated units</command></title>
+
+ <programlisting>$ systemd-analyze unit-paths | grep '^/run'
+/run/systemd/system.control
+/run/systemd/transient
+/run/systemd/generator.early
+/run/systemd/system
+/run/systemd/system.attached
+/run/systemd/generator
+/run/systemd/generator.late
+</programlisting>
+ </example>
+
+ <para>Note that this verb prints the list that is compiled into <command>systemd-analyze</command>
+ itself, and does not communicate with the running manager. Use
+ <programlisting>systemctl [--user] [--global] show -p UnitPath --value</programlisting>
+ to retrieve the actual list that the manager uses, with any empty directories omitted.</para>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze exit-status <optional><replaceable>STATUS</replaceable>...</optional></command></title>
+
+ <para>This command prints a list of exit statuses along with their "class", i.e. the source of the
+ definition (one of <literal>glibc</literal>, <literal>systemd</literal>, <literal>LSB</literal>, or
+ <literal>BSD</literal>), see the Process Exit Codes section in
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ If no additional arguments are specified, all known statuses are are shown. Otherwise, only the
+ definitions for the specified codes are shown.</para>
+
+ <example>
+ <title><command>Show some example exit status names</command></title>
+
+ <programlisting>$ systemd-analyze exit-status 0 1 {63..65}
+NAME STATUS CLASS
+SUCCESS 0 glibc
+FAILURE 1 glibc
+- 63 -
+USAGE 64 BSD
+DATAERR 65 BSD
+</programlisting>
+ </example>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze condition <replaceable>CONDITION</replaceable>...</command></title>
+
+ <para>This command will evaluate <varname index="false">Condition*=...</varname> and
+ <varname index="false">Assert*=...</varname> assignments, and print their values, and
+ the resulting value of the combined condition set. See
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for a list of available conditions and asserts.</para>
+
+ <example>
+ <title>Evaluate conditions that check kernel versions</title>
+
+ <programlisting>$ systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
+ 'ConditionKernelVersion = >=5.1' \
+ 'ConditionACPower=|false' \
+ 'ConditionArchitecture=|!arm' \
+ 'AssertPathExists=/etc/os-release'
+test.service: AssertPathExists=/etc/os-release succeeded.
+Asserts succeeded.
+test.service: ConditionArchitecture=|!arm succeeded.
+test.service: ConditionACPower=|false failed.
+test.service: ConditionKernelVersion=>=5.1 succeeded.
+test.service: ConditionKernelVersion=!<4.0 succeeded.
+Conditions succeeded.</programlisting>
+ </example>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze syscall-filter <optional><replaceable>SET</replaceable>...</optional></command></title>
+
+ <para>This command will list system calls contained in the specified system call set
+ <replaceable>SET</replaceable>, or all known sets if no sets are specified. Argument
+ <replaceable>SET</replaceable> must include the <literal>@</literal> prefix.</para>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze calendar <replaceable>EXPRESSION</replaceable>...</command></title>
+
+ <para>This command will parse and normalize repetitive calendar time events, and will calculate when
+ they elapse next. This takes the same input as the <varname>OnCalendar=</varname> setting in
+ <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ following the syntax described in
+ <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>. By
+ default, only the next time the calendar expression will elapse is shown; use
+ <option>--iterations=</option> to show the specified number of next times the expression
+ elapses. Each time the expression elapses forms a timestamp, see the <command>timestamp</command>
+ verb below.</para>
+
+ <example>
+ <title>Show leap days in the near future</title>
+
+ <programlisting>$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'
+ Original form: *-2-29 0:0:0
+Normalized form: *-02-29 00:00:00
+ Next elapse: Sat 2020-02-29 00:00:00 UTC
+ From now: 11 months 15 days left
+ Iter. #2: Thu 2024-02-29 00:00:00 UTC
+ From now: 4 years 11 months left
+ Iter. #3: Tue 2028-02-29 00:00:00 UTC
+ From now: 8 years 11 months left
+ Iter. #4: Sun 2032-02-29 00:00:00 UTC
+ From now: 12 years 11 months left
+ Iter. #5: Fri 2036-02-29 00:00:00 UTC
+ From now: 16 years 11 months left
+</programlisting>
+ </example>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze timestamp <replaceable>TIMESTAMP</replaceable>...</command></title>
+
+ <para>This command parses a timestamp (i.e. a single point in time) and outputs the normalized form and
+ the difference between this timestamp and now. The timestamp should adhere to the syntax documented in
+ <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+ section "PARSING TIMESTAMPS".</para>
+
+ <example>
+ <title>Show parsing of timestamps</title>
+
+ <programlisting>$ systemd-analyze timestamp yesterday now tomorrow
+ Original form: yesterday
+Normalized form: Mon 2019-05-20 00:00:00 CEST
+ (in UTC): Sun 2019-05-19 22:00:00 UTC
+ UNIX seconds: @15583032000
+ From now: 1 day 9h ago
+
+ Original form: now
+Normalized form: Tue 2019-05-21 09:48:39 CEST
+ (in UTC): Tue 2019-05-21 07:48:39 UTC
+ UNIX seconds: @1558424919.659757
+ From now: 43us ago
+
+ Original form: tomorrow
+Normalized form: Wed 2019-05-22 00:00:00 CEST
+ (in UTC): Tue 2019-05-21 22:00:00 UTC
+ UNIX seconds: @15584760000
+ From now: 14h left
+</programlisting>
+ </example>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze timespan <replaceable>EXPRESSION</replaceable>...</command></title>
+
+ <para>This command parses a time span (i.e. a difference between two timestamps) and outputs the
+ normalized form and the equivalent value in microseconds. The time span should adhere to the syntax
+ documented in
+ <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+ section "PARSING TIME SPANS". Values without units are parsed as seconds.</para>
+
+ <example>
+ <title>Show parsing of timespans</title>
+
+ <programlisting>$ systemd-analyze timespan 1s 300s '1year 0.000001s'
+Original: 1s
+ μs: 1000000
+ Human: 1s
+
+Original: 300s
+ μs: 300000000
+ Human: 5min
+
+Original: 1year 0.000001s
+ μs: 31557600000001
+ Human: 1y 1us
+</programlisting>
+ </example>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze cat-config</command>
+ <replaceable>NAME</replaceable>|<replaceable>PATH</replaceable>...</title>
+
+ <para>This command is similar to <command>systemctl cat</command>, but operates on config files. It
+ will copy the contents of a config file and any drop-ins to standard output, using the usual systemd
+ set of directories and rules for precedence. Each argument must be either an absolute path including
+ the prefix (such as <filename>/etc/systemd/logind.conf</filename> or
+ <filename>/usr/lib/systemd/logind.conf</filename>), or a name relative to the prefix (such as
+ <filename>systemd/logind.conf</filename>).</para>
+
+ <example>
+ <title>Showing logind configuration</title>
+ <programlisting>$ systemd-analyze cat-config systemd/logind.conf
# /etc/systemd/logind.conf
...
[Login]
# /etc/systemd/logind.conf.d/50-override.conf
... some administrator override
- </programlisting>
- </example>
-
- <para><command>systemd-analyze unit-paths</command> outputs a list of all
- directories from which unit files, <filename>.d</filename> overrides, and
- <filename>.wants</filename>, <filename>.requires</filename> symlinks may be
- loaded. Combine with <option>--user</option> to retrieve the list for the user
- manager instance, and <option>--global</option> for the global configuration of
- user manager instances. Note that this verb prints the list that is compiled into
- <command>systemd-analyze</command> itself, and does not comunicate with the
- running manager. Use
- <programlisting>systemctl [--user] [--global] show -p UnitPath --value</programlisting>
- to retrieve the actual list that the manager uses, with any empty directories
- omitted.</para>
-
- <para><command>systemd-analyze log-level</command>
- prints the current log level of the <command>systemd</command> daemon.
- If an optional argument <replaceable>LEVEL</replaceable> is provided, then the command changes the current log
- level of the <command>systemd</command> daemon to <replaceable>LEVEL</replaceable> (accepts the same values as
- <option>--log-level=</option> described in
- <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>).</para>
-
- <para><command>systemd-analyze log-target</command>
- prints the current log target of the <command>systemd</command> daemon.
- If an optional argument <replaceable>TARGET</replaceable> is provided, then the command changes the current log
- target of the <command>systemd</command> daemon to <replaceable>TARGET</replaceable> (accepts the same values as
- <option>--log-target=</option>, described in
- <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>).</para>
-
- <para><command>systemd-analyze syscall-filter <optional><replaceable>SET</replaceable>…</optional></command>
- will list system calls contained in the specified system call set <replaceable>SET</replaceable>,
- or all known sets if no sets are specified. Argument <replaceable>SET</replaceable> must include
- the <literal>@</literal> prefix.</para>
-
- <para><command>systemd-analyze verify</command> will load unit files and print
- warnings if any errors are detected. Files specified on the command line will be
- loaded, but also any other units referenced by them. The full unit search path is
- formed by combining the directories for all command line arguments, and the usual unit
- load paths (variable <varname>$SYSTEMD_UNIT_PATH</varname> is supported, and may be
- used to replace or augment the compiled in set of unit load paths; see
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
- All units files present in the directories containing the command line arguments will
- be used in preference to the other paths.</para>
-
- <para><command>systemd-analyze calendar</command> will parse and normalize repetitive calendar time events, and
- will calculate when they will elapse next. This takes the same input as the <varname>OnCalendar=</varname> setting
- in <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>, following the
- syntax described in
- <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
-
- <para><command>systemd-analyze service-watchdogs</command>
- prints the current state of service runtime watchdogs of the <command>systemd</command> daemon.
- If an optional boolean argument is provided, then globally enables or disables the service
- runtime watchdogs (<option>WatchdogSec=</option>) and emergency actions (e.g.
- <option>OnFailure=</option> or <option>StartLimitAction=</option>); see
- <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
- The hardware watchdog is not affected by this setting.</para>
-
- <para><command>systemd-analyze timespan</command> parses a time span and outputs the equivalent value in microseconds, and as a reformatted timespan.
- The time span should adhere to the same syntax documented in <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
- Values without associated magnitudes are parsed as seconds.</para>
-
- <para><command>systemd-analyze security</command> analyzes the security and sandboxing settings of one or more
- specified service units. If at least one unit name is specified the security settings of the specified service
- units are inspected and a detailed analysis is shown. If no unit name is specified, all currently loaded,
- long-running service units are inspected and a terse table with results shown. The command checks for various
- security-related service settings, assigning each a numeric "exposure level" value, depending on how important a
- setting is. It then calculates an overall exposure level for the whole unit, which is an estimation in the range
- 0.0…10.0 indicating how exposed a service is security-wise. High exposure levels indicate very little applied
- sandboxing. Low exposure levels indicate tight sandboxing and strongest security restrictions. Note that this only
- analyzes the per-service security features systemd itself implements. This means that any additional security
- mechanisms applied by the service code itself are not accounted for. The exposure level determined this way should
- not be misunderstood: a high exposure level neither means that there is no effective sandboxing applied by the
- service code itself, nor that the service is actually vulnerable to remote or local attacks. High exposure levels
- do indicate however that most likely the service might benefit from additional settings applied to them. Please
- note that many of the security and sandboxing settings individually can be circumvented — unless combined with
- others. For example, if a service retains the privilege to establish or undo mount points many of the sandboxing
- options can be undone by the service code itself. Due to that is essential that each service uses the most
- comprehensive and strict sandboxing and security settings possible. The tool will take into account some of these
- combinations and relationships between the settings, but not all. Also note that the security and sandboxing
- settings analyzed here only apply to the operations executed by the service code itself. If a service has access to
- an IPC system (such as D-Bus) it might request operations from other services that are not subject to the same
- restrictions. Any comprehensive security and sandboxing analysis is hence incomplete if the IPC access policy is
- not validated too.</para>
+ </programlisting>
+ </example>
+ </refsect2>
- <para>If no command is passed, <command>systemd-analyze
- time</command> is implied.</para>
+ <refsect2>
+ <title><command>systemd-analyze verify <replaceable>FILE</replaceable>...</command></title>
+
+ <para>This command will load unit files and print warnings if any errors are detected. Files specified
+ on the command line will be loaded, but also any other units referenced by them. The full unit search
+ path is formed by combining the directories for all command line arguments, and the usual unit load
+ paths. The variable <varname>$SYSTEMD_UNIT_PATH</varname> is supported, and may be used to replace or
+ augment the compiled in set of unit load paths; see
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. All
+ units files present in the directories containing the command line arguments will be used in preference
+ to the other paths.</para>
+
+ <para>The following errors are currently detected:</para>
+ <itemizedlist>
+ <listitem><para>unknown sections and directives,</para></listitem>
+
+ <listitem><para>missing dependencies which are required to start the given unit,</para></listitem>
+
+ <listitem><para>man pages listed in <varname>Documentation=</varname> which are not found in the
+ system,</para></listitem>
+
+ <listitem><para>commands listed in <varname>ExecStart=</varname> and similar which are not found in
+ the system or not executable.</para></listitem>
+ </itemizedlist>
+
+ <example>
+ <title>Misspelt directives</title>
+
+ <programlisting>$ cat ./user.slice
+[Unit]
+WhatIsThis=11
+Documentation=man:nosuchfile(1)
+Requires=different.service
+[Service]
+Description=x
+
+$ systemd-analyze verify ./user.slice
+[./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
+[./user.slice:13] Unknown section 'Service'. Ignoring.
+Error: org.freedesktop.systemd1.LoadFailed:
+ Unit different.service failed to load:
+ No such file or directory.
+Failed to create user.slice/start: Invalid argument
+user.slice: man nosuchfile(1) command failed with code 16
+ </programlisting>
+ </example>
+
+ <example>
+ <title>Missing service units</title>
+
+ <programlisting>$ tail ./a.socket ./b.socket
+==> ./a.socket <==
+[Socket]
+ListenStream=100
+
+==> ./b.socket <==
+[Socket]
+ListenStream=100
+Accept=yes
+
+$ systemd-analyze verify ./a.socket ./b.socket
+Service a.service not loaded, a.socket cannot be started.
+Service b@0.service not loaded, b.socket cannot be started.
+ </programlisting>
+ </example>
+ </refsect2>
+
+ <refsect2>
+ <title><command>systemd-analyze security <optional><replaceable>UNIT</replaceable>...</optional></command></title>
+
+ <para>This command analyzes the security and sandboxing settings of one or more specified service
+ units. If at least one unit name is specified the security settings of the specified service units are
+ inspected and a detailed analysis is shown. If no unit name is specified, all currently loaded,
+ long-running service units are inspected and a terse table with results shown. The command checks for
+ various security-related service settings, assigning each a numeric "exposure level" value, depending
+ on how important a setting is. It then calculates an overall exposure level for the whole unit, which
+ is an estimation in the range 0.0…10.0 indicating how exposed a service is security-wise. High exposure
+ levels indicate very little applied sandboxing. Low exposure levels indicate tight sandboxing and
+ strongest security restrictions. Note that this only analyzes the per-service security features systemd
+ itself implements. This means that any additional security mechanisms applied by the service code
+ itself are not accounted for. The exposure level determined this way should not be misunderstood: a
+ high exposure level neither means that there is no effective sandboxing applied by the service code
+ itself, nor that the service is actually vulnerable to remote or local attacks. High exposure levels do
+ indicate however that most likely the service might benefit from additional settings applied to
+ them.</para>
+
+ <para>Please note that many of the security and sandboxing settings individually can be circumvented —
+ unless combined with others. For example, if a service retains the privilege to establish or undo mount
+ points many of the sandboxing options can be undone by the service code itself. Due to that is
+ essential that each service uses the most comprehensive and strict sandboxing and security settings
+ possible. The tool will take into account some of these combinations and relationships between the
+ settings, but not all. Also note that the security and sandboxing settings analyzed here only apply to
+ the operations executed by the service code itself. If a service has access to an IPC system (such as
+ D-Bus) it might request operations from other services that are not subject to the same
+ restrictions. Any comprehensive security and sandboxing analysis is hence incomplete if the IPC access
+ policy is not validated too.</para>
+
+ <example>
+ <title>Analyze <filename index="false">systemd-logind.service</filename></title>
+
+ <programlisting>$ systemd-analyze security --no-pager systemd-logind.service
+ NAME DESCRIPTION EXPOSURE
+✗ PrivateNetwork= Service has access to the host's network 0.5
+✗ User=/DynamicUser= Service runs as root user 0.4
+✗ DeviceAllow= Service has no device ACL 0.2
+✓ IPAddressDeny= Service blocks all IP address ranges
+...
+→ Overall exposure level for systemd-logind.service: 4.1 OK 🙂
+</programlisting>
+ </example>
+ </refsect2>
</refsect1>
<refsect1>
<command>dot</command> command (see above), this selects which
relationships are shown in the dependency graph. Both options
require a
- <citerefentry project='die-net'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
pattern as an argument, which will be matched against the
left-hand and the right-hand, respectively, nodes of a
relationship.</para>
<varlistentry>
<term><option>--man=no</option></term>
- <listitem><para>Do not invoke man to verify the existence of
- man pages listed in <varname>Documentation=</varname>.
- </para></listitem>
+ <listitem><para>Do not invoke
+ <citerefentry project='man-pages'><refentrytitle>man</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ to verify the existence of man pages listed in <varname>Documentation=</varname>.</para></listitem>
</varlistentry>
<varlistentry>
the specified root path <replaceable>PATH</replaceable>.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><option>--iterations=<replaceable>NUMBER</replaceable></option></term>
+
+ <listitem><para>When used with the <command>calendar</command> command, show the specified number of
+ iterations the specified calendar expression will elapse next. Defaults to 1.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>--base-time=<replaceable>TIMESTAMP</replaceable></option></term>
+
+ <listitem><para>When used with the <command>calendar</command> command, show next iterations relative
+ to the specified point in time. If not specified defaults to the current time.</para></listitem>
+ </varlistentry>
+
<xi:include href="user-system-options.xml" xpointer="host" />
<xi:include href="user-system-options.xml" xpointer="machine" />
otherwise.</para>
</refsect1>
- <refsect1>
- <title>Examples for <command>dot</command></title>
-
- <example>
- <title>Plots all dependencies of any unit whose name starts with
- <literal>avahi-daemon</literal></title>
-
- <programlisting>$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > avahi.svg
-$ eog avahi.svg</programlisting>
- </example>
-
- <example>
- <title>Plots the dependencies between all known target units</title>
-
- <programlisting>$ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' | dot -Tsvg > targets.svg
-$ eog targets.svg</programlisting>
- </example>
- </refsect1>
-
- <refsect1>
- <title>Examples for <command>verify</command></title>
-
- <para>The following errors are currently detected:</para>
- <itemizedlist>
- <listitem><para>unknown sections and directives,
- </para></listitem>
-
- <listitem><para>missing dependencies which are required to start
- the given unit,</para></listitem>
-
- <listitem><para>man pages listed in
- <varname>Documentation=</varname> which are not found in the
- system,</para></listitem>
-
- <listitem><para>commands listed in <varname>ExecStart=</varname>
- and similar which are not found in the system or not
- executable.</para></listitem>
- </itemizedlist>
-
- <example>
- <title>Misspelt directives</title>
-
- <programlisting>$ cat ./user.slice
-[Unit]
-WhatIsThis=11
-Documentation=man:nosuchfile(1)
-Requires=different.service
-
-[Service]
-Description=x
-
-$ systemd-analyze verify ./user.slice
-[./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
-[./user.slice:13] Unknown section 'Service'. Ignoring.
-Error: org.freedesktop.systemd1.LoadFailed:
- Unit different.service failed to load:
- No such file or directory.
-Failed to create user.slice/start: Invalid argument
-user.slice: man nosuchfile(1) command failed with code 16
- </programlisting>
- </example>
-
- <example>
- <title>Missing service units</title>
-
- <programlisting>$ tail ./a.socket ./b.socket
-==> ./a.socket <==
-[Socket]
-ListenStream=100
-
-==> ./b.socket <==
-[Socket]
-ListenStream=100
-Accept=yes
-
-$ systemd-analyze verify ./a.socket ./b.socket
-Service a.service not loaded, a.socket cannot be started.
-Service b@0.service not loaded, b.socket cannot be started.
- </programlisting>
- </example>
- </refsect1>
-
<xi:include href="less-variables.xml" />
<refsect1>
projects / thirdparty / systemd.git / blobdiff