mirror of
https://github.com/systemd/systemd
synced 2024-10-14 20:17:52 +00:00
man: reorder and add examples to systemd-analyze(1)
The number of verbs supported by systemd-analyze has grown quite a bit, and the man page has become an unreadable wall of text. Let's put each verb in a separate subsection, grouping similar verbs together, and add a lot of examples to guide the user.
This commit is contained in:
parent
827f62c3f2
commit
d323a99001
|
@ -38,35 +38,7 @@
|
||||||
<arg choice="plain">critical-chain</arg>
|
<arg choice="plain">critical-chain</arg>
|
||||||
<arg choice="opt" rep="repeat"><replaceable>UNIT</replaceable></arg>
|
<arg choice="opt" rep="repeat"><replaceable>UNIT</replaceable></arg>
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
<cmdsynopsis>
|
|
||||||
<command>systemd-analyze</command>
|
|
||||||
<arg choice="opt" rep="repeat">OPTIONS</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">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">dump</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>
|
|
||||||
</cmdsynopsis>
|
|
||||||
<cmdsynopsis>
|
|
||||||
<command>systemd-analyze</command>
|
|
||||||
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
||||||
<arg choice="plain">unit-paths</arg>
|
|
||||||
</cmdsynopsis>
|
|
||||||
<cmdsynopsis>
|
<cmdsynopsis>
|
||||||
<command>systemd-analyze</command>
|
<command>systemd-analyze</command>
|
||||||
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
||||||
|
@ -82,14 +54,40 @@
|
||||||
<cmdsynopsis>
|
<cmdsynopsis>
|
||||||
<command>systemd-analyze</command>
|
<command>systemd-analyze</command>
|
||||||
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
||||||
<arg choice="plain">syscall-filter</arg>
|
<arg choice="plain">service-watchdogs</arg>
|
||||||
<arg choice="opt"><replaceable>SET</replaceable>…</arg>
|
<arg choice="opt"><replaceable>BOOL</replaceable></arg>
|
||||||
|
</cmdsynopsis>
|
||||||
|
|
||||||
|
<cmdsynopsis>
|
||||||
|
<command>systemd-analyze</command>
|
||||||
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
||||||
|
<arg choice="plain">dump</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>
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
<cmdsynopsis>
|
<cmdsynopsis>
|
||||||
<command>systemd-analyze</command>
|
<command>systemd-analyze</command>
|
||||||
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
||||||
<arg choice="plain">verify</arg>
|
<arg choice="plain">dot</arg>
|
||||||
<arg choice="opt" rep="repeat"><replaceable>FILES</replaceable></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">unit-paths</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>
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
<cmdsynopsis>
|
<cmdsynopsis>
|
||||||
<command>systemd-analyze</command>
|
<command>systemd-analyze</command>
|
||||||
|
@ -100,14 +98,20 @@
|
||||||
<cmdsynopsis>
|
<cmdsynopsis>
|
||||||
<command>systemd-analyze</command>
|
<command>systemd-analyze</command>
|
||||||
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
||||||
<arg choice="plain">service-watchdogs</arg>
|
<arg choice="plain">timespan</arg>
|
||||||
<arg choice="opt"><replaceable>BOOL</replaceable></arg>
|
<arg choice="plain" rep="repeat"><replaceable>SPAN</replaceable></arg>
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
<cmdsynopsis>
|
<cmdsynopsis>
|
||||||
<command>systemd-analyze</command>
|
<command>systemd-analyze</command>
|
||||||
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
||||||
<arg choice="plain">timespan</arg>
|
<arg choice="plain">cat-config</arg>
|
||||||
<arg choice="plain" rep="repeat"><replaceable>SPAN</replaceable></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">verify</arg>
|
||||||
|
<arg choice="opt" rep="repeat"><replaceable>FILE</replaceable></arg>
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
<cmdsynopsis>
|
<cmdsynopsis>
|
||||||
<command>systemd-analyze</command>
|
<command>systemd-analyze</command>
|
||||||
|
@ -126,73 +130,299 @@
|
||||||
verify the correctness of unit files. It is also used to access
|
verify the correctness of unit files. It is also used to access
|
||||||
special functions useful for advanced system manager debugging.</para>
|
special functions useful for advanced system manager debugging.</para>
|
||||||
|
|
||||||
<para><command>systemd-analyze time</command> prints the time
|
<para>If no command is passed, <command>systemd-analyze
|
||||||
spent in the kernel before userspace has been reached, the time
|
time</command> is implied.</para>
|
||||||
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
|
<refsect2>
|
||||||
all running units, ordered by the time they took to initialize.
|
<title><command>systemd-analyze time</command></title>
|
||||||
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
|
<para>This command prints the time spent in the kernel before userspace has been reached, the time
|
||||||
[<replaceable>UNIT…</replaceable>]</command> prints a tree of
|
spent in the initial RAM disk (initrd) before normal system userspace has been reached, and the time
|
||||||
the time-critical chain of units (for each of the specified
|
normal system userspace took to initialize. Note that these measurements simply measure the time passed
|
||||||
<replaceable>UNIT</replaceable>s or for the default target
|
up to the point where all system services have been spawned, but not necessarily until they fully
|
||||||
otherwise). The time after the unit is active or started is
|
finished initialization or the disk is idle.</para>
|
||||||
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
|
<example>
|
||||||
graphic detailing which system services have been started at what
|
<title><command>Show how long the boot took</command></title>
|
||||||
time, highlighting the time they spent on initialization.</para>
|
|
||||||
|
|
||||||
<para><command>systemd-analyze dot</command> generates textual
|
<programlisting># in a container
|
||||||
dependency graph description in dot format for further processing
|
$ systemd-analyze time
|
||||||
with the GraphViz
|
Startup finished in 296ms (userspace)
|
||||||
<citerefentry project='die-net'><refentrytitle>dot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
multi-user.target reached after 275ms in userspace
|
||||||
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
|
# on a real machine
|
||||||
very long) human-readable serialization of the complete server
|
$ systemd-analyze time
|
||||||
state. Its format is subject to change without notice and should
|
Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s
|
||||||
not be parsed by applications.</para>
|
multi-user.target reached after 47.820s in userspace
|
||||||
|
</programlisting>
|
||||||
|
</example>
|
||||||
|
</refsect2>
|
||||||
|
|
||||||
<para><command>systemd-analyze cat-config</command> is similar
|
<refsect2>
|
||||||
to <command>systemctl cat</command>, but operates on config files.
|
<title><command>systemd-analyze blame</command></title>
|
||||||
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>
|
<para>This command prints a list of all running units, ordered by the time they took to initialize.
|
||||||
<title>Showing logind configuration</title>
|
This information may be used to optimize boot-up times. Note that the output might be misleading as the
|
||||||
<programlisting>$ systemd-analyze cat-config systemd/logind.conf
|
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>
|
||||||
|
|
||||||
|
<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.</para>
|
||||||
|
|
||||||
|
<example>
|
||||||
|
<title><command>systemd-analyze time</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 log-level [<replaceable>LEVEL</replaceable>]</command></title>
|
||||||
|
|
||||||
|
<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>
|
||||||
|
</refsect2>
|
||||||
|
|
||||||
|
<refsect2>
|
||||||
|
<title><command>systemd-analyze log-target [<replaceable>TARGET</replaceable>]</command></title>
|
||||||
|
|
||||||
|
<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>
|
||||||
|
</refsect2>
|
||||||
|
|
||||||
|
<refsect2>
|
||||||
|
<title><command>systemd-analyze service-watchdogs [yes|no]</command></title>
|
||||||
|
|
||||||
|
<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>
|
||||||
|
</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 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>
|
||||||
|
</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.</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 timespan <replaceable>EXPRESSION</replaceable>...</command></title>
|
||||||
|
|
||||||
|
<para>This command parses a time span and outputs the normalized form and the equivalent value in
|
||||||
|
microseconds. 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>
|
||||||
|
|
||||||
|
<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
|
# /etc/systemd/logind.conf
|
||||||
...
|
...
|
||||||
[Login]
|
[Login]
|
||||||
|
@ -204,97 +434,122 @@ NAutoVTs=8
|
||||||
|
|
||||||
# /etc/systemd/logind.conf.d/50-override.conf
|
# /etc/systemd/logind.conf.d/50-override.conf
|
||||||
... some administrator override
|
... some administrator override
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</example>
|
</example>
|
||||||
|
</refsect2>
|
||||||
|
|
||||||
<para><command>systemd-analyze unit-paths</command> outputs a list of all
|
<refsect2>
|
||||||
directories from which unit files, <filename>.d</filename> overrides, and
|
<title><command>systemd-analyze verify <replaceable>FILE</replaceable>...</command></title>
|
||||||
<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>
|
<para>This command will load unit files and print warnings if any errors are detected. Files specified
|
||||||
prints the current log level of the <command>systemd</command> daemon.
|
on the command line will be loaded, but also any other units referenced by them. The full unit search
|
||||||
If an optional argument <replaceable>LEVEL</replaceable> is provided, then the command changes the current log
|
path is formed by combining the directories for all command line arguments, and the usual unit load
|
||||||
level of the <command>systemd</command> daemon to <replaceable>LEVEL</replaceable> (accepts the same values as
|
paths (variable <varname>$SYSTEMD_UNIT_PATH</varname> is supported, and may be used to replace or
|
||||||
<option>--log-level=</option> described in
|
augment the compiled in set of unit load paths; see
|
||||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>).</para>
|
<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 log-target</command>
|
<para>The following errors are currently detected:</para>
|
||||||
prints the current log target of the <command>systemd</command> daemon.
|
<itemizedlist>
|
||||||
If an optional argument <replaceable>TARGET</replaceable> is provided, then the command changes the current log
|
<listitem><para>unknown sections and directives,</para></listitem>
|
||||||
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>
|
<listitem><para>missing dependencies which are required to start the given unit,</para></listitem>
|
||||||
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
|
<listitem><para>man pages listed in <varname>Documentation=</varname> which are not found in the
|
||||||
warnings if any errors are detected. Files specified on the command line will be
|
system,</para></listitem>
|
||||||
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
|
<listitem><para>commands listed in <varname>ExecStart=</varname> and similar which are not found in
|
||||||
events, and will calculate when they will elapse next. This takes the same input as the
|
the system or not executable.</para></listitem>
|
||||||
<varname>OnCalendar=</varname> setting in
|
</itemizedlist>
|
||||||
<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.</para>
|
|
||||||
|
|
||||||
<para><command>systemd-analyze service-watchdogs</command>
|
<example>
|
||||||
prints the current state of service runtime watchdogs of the <command>systemd</command> daemon.
|
<title>Misspelt directives</title>
|
||||||
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.
|
<programlisting>$ cat ./user.slice
|
||||||
The time span should adhere to the same syntax documented in <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
|
[Unit]
|
||||||
Values without associated magnitudes are parsed as seconds.</para>
|
WhatIsThis=11
|
||||||
|
Documentation=man:nosuchfile(1)
|
||||||
|
Requires=different.service
|
||||||
|
|
||||||
<para><command>systemd-analyze security</command> analyzes the security and sandboxing settings of one or more
|
[Service]
|
||||||
specified service units. If at least one unit name is specified the security settings of the specified service
|
Description=x
|
||||||
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>
|
|
||||||
|
|
||||||
<para>If no command is passed, <command>systemd-analyze
|
$ systemd-analyze verify ./user.slice
|
||||||
time</command> is implied.</para>
|
[./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 noindex="true">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>
|
||||||
|
|
||||||
<refsect1>
|
<refsect1>
|
||||||
|
@ -425,88 +680,6 @@ NAutoVTs=8
|
||||||
otherwise.</para>
|
otherwise.</para>
|
||||||
</refsect1>
|
</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" />
|
<xi:include href="less-variables.xml" />
|
||||||
|
|
||||||
<refsect1>
|
<refsect1>
|
||||||
|
|
Loading…
Reference in a new issue