mirror of
https://github.com/systemd/systemd.git
synced 2024-12-05 00:04:02 +08:00
cae7c28272
Previously, systemd-analyze verify would return 0 even if warnings
were raised during analysis of the specified units or their
dependencies. With 3cc3dc7, verify was changed to return 1 when
warnings were raised.
This commit changes the default mode to _RECURSIVE_ERRORS_INVALID
so that verify returns zero again by default when warnings are
raised.
1279 lines
52 KiB
XML
1279 lines
52 KiB
XML
<?xml version='1.0'?> <!--*-nxml-*-->
|
|
<!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-or-later -->
|
|
|
|
<refentry id="systemd-analyze" conditional='ENABLE_ANALYZE'
|
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
|
|
<refentryinfo>
|
|
<title>systemd-analyze</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>systemd-analyze</refentrytitle>
|
|
<manvolnum>1</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>systemd-analyze</refname>
|
|
<refpurpose>Analyze and debug system manager</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>systemd-analyze</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<arg>time</arg>
|
|
</cmdsynopsis>
|
|
<cmdsynopsis>
|
|
<command>systemd-analyze</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<arg choice="plain">blame</arg>
|
|
</cmdsynopsis>
|
|
<cmdsynopsis>
|
|
<command>systemd-analyze</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<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">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>
|
|
<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">unit-paths</arg>
|
|
</cmdsynopsis>
|
|
<cmdsynopsis>
|
|
<command>systemd-analyze</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</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">capability</arg>
|
|
<arg choice="opt" rep="repeat"><replaceable>CAPABILITY</replaceable></arg>
|
|
</cmdsynopsis>
|
|
<cmdsynopsis>
|
|
<command>systemd-analyze</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</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">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">filesystems</arg>
|
|
<arg choice="opt"><replaceable>SET</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>SPEC</replaceable></arg>
|
|
</cmdsynopsis>
|
|
<cmdsynopsis>
|
|
<command>systemd-analyze</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</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">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">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">verify</arg>
|
|
<arg choice="opt" rep="repeat"><replaceable>FILE</replaceable></arg>
|
|
</cmdsynopsis>
|
|
<cmdsynopsis>
|
|
<command>systemd-analyze</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<arg choice="plain">security</arg>
|
|
<arg choice="plain" rep="repeat"><replaceable>UNIT</replaceable></arg>
|
|
</cmdsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para><command>systemd-analyze</command> may be used to determine
|
|
system boot-up performance statistics and retrieve other state and
|
|
tracing information from the system and service manager, and to
|
|
verify the correctness of unit files. It is also used to access
|
|
special functions useful for advanced system manager debugging.</para>
|
|
|
|
<para>If no command is passed, <command>systemd-analyze
|
|
time</command> is implied.</para>
|
|
|
|
<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 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 capability <optional><replaceable>CAPABILITY</replaceable>...</optional></command></title>
|
|
|
|
<para>This command prints a list of Linux capabilities along with their numeric IDs. See <citerefentry
|
|
project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
|
for details. If no argument is specified the full list of capabilities known to the service manager and
|
|
the kernel is shown. Capabilities defined by the kernel but not known to the service manager are shown
|
|
as <literal>cap_???</literal>. Optionally, if arguments are specified they may refer to specific
|
|
cabilities by name or numeric ID, in which case only the indicated capabilities are shown in the
|
|
table.</para>
|
|
|
|
<example>
|
|
<title><command>Show some example capability names</command></title>
|
|
|
|
<programlisting>$ systemd-analyze capability 0 1 {30..32}
|
|
NAME NUMBER
|
|
cap_chown 0
|
|
cap_dac_override 1
|
|
cap_audit_control 30
|
|
cap_setfcap 31
|
|
cap_mac_override 32</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 filesystems <optional><replaceable>SET</replaceable>...</optional></command></title>
|
|
|
|
<para>This command will list filesystems in the specified filesystem 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]
|
|
NAutoVTs=8
|
|
...
|
|
|
|
# /usr/lib/systemd/logind.conf.d/20-test.conf
|
|
... some override from another package
|
|
|
|
# /etc/systemd/logind.conf.d/50-override.conf
|
|
... some administrator override
|
|
</programlisting>
|
|
</example>
|
|
</refsect2>
|
|
|
|
<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. A unit's name on disk
|
|
can be overridden by specifying an alias after a colon; see below for an example. 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>
|
|
|
|
<example>
|
|
<title>Aliasing a unit</title>
|
|
|
|
<programlisting>$ cat /tmp/source
|
|
[Unit]
|
|
Description=Hostname printer
|
|
|
|
[Service]
|
|
Type=simple
|
|
ExecStart=/usr/bin/echo %H
|
|
MysteryKey=true
|
|
|
|
$ systemd-analyze verify /tmp/source
|
|
Failed to prepare filename /tmp/source: Invalid argument
|
|
|
|
$ systemd-analyze verify /tmp/source:alias.service
|
|
/tmp/systemd-analyze-XXXXXX/alias.service:7: Unknown key name 'MysteryKey' in section 'Service', ignoring.
|
|
</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>
|
|
|
|
<refsect2>
|
|
<title><command>systemd-analyze inspect-elf <replaceable>FILE</replaceable>...</command></title>
|
|
|
|
<para>This command will load the specified file(s), and if they are ELF objects (executables,
|
|
libraries, core files, etc.) it will parse the embedded packaging metadata, if any, and print
|
|
it in a table or json format. See the <ulink url="https://systemd.io/COREDUMP_PACKAGE_METADATA/">
|
|
Packaging Metadata</ulink> documentation for more information.</para>
|
|
|
|
<example>
|
|
<title>Table output</title>
|
|
|
|
<programlisting>$ systemd-analyze inspect-elf --json=pretty /tmp/core.fsverity.1000.f77dac5dc161402aa44e15b7dd9dcf97.58561.1637106137000000
|
|
{
|
|
"elfType" : "coredump",
|
|
"elfArchitecture" : "AMD x86-64",
|
|
"/home/bluca/git/fsverity-utils/fsverity" : {
|
|
"type" : "deb",
|
|
"name" : "fsverity-utils",
|
|
"version" : "1.3-1",
|
|
"buildId" : "7c895ecd2a271f93e96268f479fdc3c64a2ec4ee"
|
|
},
|
|
"/home/bluca/git/fsverity-utils/libfsverity.so.0" : {
|
|
"type" : "deb",
|
|
"name" : "fsverity-utils",
|
|
"version" : "1.3-1",
|
|
"buildId" : "b5e428254abf14237b0ae70ed85fffbb98a78f88"
|
|
}
|
|
}
|
|
</programlisting>
|
|
</example>
|
|
|
|
</refsect2>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Options</title>
|
|
|
|
<para>The following options are understood:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><option>--system</option></term>
|
|
|
|
<listitem><para>Operates on the system systemd instance. This
|
|
is the implied default.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--user</option></term>
|
|
|
|
<listitem><para>Operates on the user systemd
|
|
instance.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--global</option></term>
|
|
|
|
<listitem><para>Operates on the system-wide configuration for
|
|
user systemd instance.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--order</option></term>
|
|
<term><option>--require</option></term>
|
|
|
|
<listitem><para>When used in conjunction with the
|
|
<command>dot</command> command (see above), selects which
|
|
dependencies are shown in the dependency graph. If
|
|
<option>--order</option> is passed, only dependencies of type
|
|
<varname>After=</varname> or <varname>Before=</varname> are
|
|
shown. If <option>--require</option> is passed, only
|
|
dependencies of type <varname>Requires=</varname>,
|
|
<varname>Requisite=</varname>,
|
|
<varname>Wants=</varname> and <varname>Conflicts=</varname>
|
|
are shown. If neither is passed, this shows dependencies of
|
|
all these types.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--from-pattern=</option></term>
|
|
<term><option>--to-pattern=</option></term>
|
|
|
|
<listitem><para>When used in conjunction with the
|
|
<command>dot</command> command (see above), this selects which
|
|
relationships are shown in the dependency graph. Both options
|
|
require a
|
|
<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>
|
|
|
|
<para>Each of these can be used more than once, in which case
|
|
the unit name must match one of the values. When tests for
|
|
both sides of the relation are present, a relation must pass
|
|
both tests to be shown. When patterns are also specified as
|
|
positional arguments, they must match at least one side of the
|
|
relation. In other words, patterns specified with those two
|
|
options will trim the list of edges matched by the positional
|
|
arguments, if any are given, and fully determine the list of
|
|
edges shown otherwise.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--fuzz=</option><replaceable>timespan</replaceable></term>
|
|
|
|
<listitem><para>When used in conjunction with the
|
|
<command>critical-chain</command> command (see above), also
|
|
show units, which finished <replaceable>timespan</replaceable>
|
|
earlier, than the latest unit in the same level. The unit of
|
|
<replaceable>timespan</replaceable> is seconds unless
|
|
specified with a different unit, e.g.
|
|
"50ms".</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--man=no</option></term>
|
|
|
|
<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>
|
|
<term><option>--generators</option></term>
|
|
|
|
<listitem><para>Invoke unit generators, see
|
|
<citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
|
|
Some generators require root privileges. Under a normal user, running with
|
|
generators enabled will generally result in some warnings.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--recursive-errors=<replaceable>MODE</replaceable></option></term>
|
|
|
|
<listitem><para>Control verification of units and their dependencies and whether
|
|
<command>systemd-analyze verify</command> exits with a non-zero process exit status or not. With
|
|
<command>yes</command>, return a non-zero process exit status when warnings arise during verification
|
|
of either the specified unit or any of its associated dependencies. With <command>no</command>,
|
|
return a non-zero process exit status when warnings arise during verification of only the specified
|
|
unit. With <command>one</command>, return a non-zero process exit status when warnings arise during
|
|
verification of either the specified unit or its immediate dependencies. If this option is not
|
|
specified, zero is returned as the exit status regardless whether warnings arise during verification
|
|
or not.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--root=<replaceable>PATH</replaceable></option></term>
|
|
|
|
<listitem><para>With <command>cat-files</command> and <command>verify</command>,
|
|
operate on files underneath the specified root path <replaceable>PATH</replaceable>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--image=<replaceable>PATH</replaceable></option></term>
|
|
|
|
<listitem><para>With <command>cat-files</command> and <command>verify</command>,
|
|
operate on files inside the specified image path <replaceable>PATH</replaceable>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--offline=<replaceable>BOOL</replaceable></option></term>
|
|
|
|
<listitem><para>With <command>security</command>, perform an offline security review
|
|
of the specified unit file(s), i.e. does not have to rely on PID 1 to acquire security
|
|
information for the files like the <command>security</command> verb when used by itself does.
|
|
This means that <option>--offline=</option> can be used with <option>--root=</option> and
|
|
<option>--image=</option> as well. If a unit's overall exposure level is above that set by
|
|
<option>--threshold=</option> (default value is 100), <option>--offline=</option> will return
|
|
an error.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--profile=<replaceable>PATH</replaceable></option></term>
|
|
|
|
<listitem><para>With <command>security</command> <option>--offline=</option>, takes into
|
|
consideration the specified portable profile when assessing the unit(s) settings.
|
|
The profile can be passed by name, in which case the well-known system locations will
|
|
be searched, or it can be the full path to a specific drop-in file.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--threshold=<replaceable>NUMBER</replaceable></option></term>
|
|
|
|
<listitem><para>With <command>security</command>, allow the user to set a custom value
|
|
to compare the overall exposure level with, for the specified unit file(s). If a unit's
|
|
overall exposure level, is greater than that set by the user, <command>security</command>
|
|
will return an error. <option>--threshold=</option> can be used with <option>--offline=</option>
|
|
as well and its default value is 100.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--security-policy=<replaceable>PATH</replaceable></option></term>
|
|
|
|
<listitem><para>With <command>security</command>, allow the user to define a custom set of
|
|
requirements formatted as a JSON file against which to compare the specified unit file(s)
|
|
and determine their overall exposure level to security threats.</para>
|
|
|
|
<table>
|
|
<title>Accepted Assessment Test Identifiers</title>
|
|
|
|
<tgroup cols='1'>
|
|
<colspec colname='directive' />
|
|
<thead>
|
|
<row>
|
|
<entry>Assessment Test Identifier</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>UserOrDynamicUser</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SupplementaryGroups</entry>
|
|
</row>
|
|
<row>
|
|
<entry>PrivateMounts</entry>
|
|
</row>
|
|
<row>
|
|
<entry>PrivateDevices</entry>
|
|
</row>
|
|
<row>
|
|
<entry>PrivateTmp</entry>
|
|
</row>
|
|
<row>
|
|
<entry>PrivateNetwork</entry>
|
|
</row>
|
|
<row>
|
|
<entry>PrivateUsers</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ProtectControlGroups</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ProtectKernelModules</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ProtectKernelTunables</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ProtectKernelLogs</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ProtectClock</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ProtectHome</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ProtectHostname</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ProtectSystem</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RootDirectoryOrRootImage</entry>
|
|
</row>
|
|
<row>
|
|
<entry>LockPersonality</entry>
|
|
</row>
|
|
<row>
|
|
<entry>MemoryDenyWriteExecute</entry>
|
|
</row>
|
|
<row>
|
|
<entry>NoNewPrivileges</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_SYS_ADMIN</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_SET_UID_GID_PCAP</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_SYS_PTRACE</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_SYS_TIME</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_NET_ADMIN</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_SYS_RAWIO</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_SYS_MODULE</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_AUDIT</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_SYSLOG</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_SYS_NICE_RESOURCE</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_MKNOD</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_CHOWN_FSETID_SETFCAP</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_DAC_FOWNER_IPC_OWNER</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_KILL</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_NET_BIND_SERVICE_BROADCAST_RAW</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_SYS_BOOT</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_MAC</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_LINUX_IMMUTABLE</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_IPC_LOCK</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_SYS_CHROOT</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_BLOCK_SUSPEND</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_WAKE_ALARM</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_LEASE</entry>
|
|
</row>
|
|
<row>
|
|
<entry>CapabilityBoundingSet_CAP_SYS_TTY_CONFIG</entry>
|
|
</row>
|
|
<row>
|
|
<entry>UMask</entry>
|
|
</row>
|
|
<row>
|
|
<entry>KeyringMode</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ProtectProc</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ProcSubset</entry>
|
|
</row>
|
|
<row>
|
|
<entry>NotifyAccess</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RemoveIPC</entry>
|
|
</row>
|
|
<row>
|
|
<entry>Delegate</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictRealtime</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictSUIDSGID</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictNamespaces_user</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictNamespaces_mnt</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictNamespaces_ipc</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictNamespaces_pid</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictNamespaces_cgroup</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictNamespaces_uts</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictNamespaces_net</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictAddressFamilies_AF_INET_INET6</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictAddressFamilies_AF_UNIX</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictAddressFamilies_AF_NETLINK</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictAddressFamilies_AF_PACKET</entry>
|
|
</row>
|
|
<row>
|
|
<entry>RestrictAddressFamilies_OTHER</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SystemCallArchitectures</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SystemCallFilter_swap</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SystemCallFilter_obsolete</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SystemCallFilter_clock</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SystemCallFilter_cpu_emulation</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SystemCallFilter_debug</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SystemCallFilter_mount</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SystemCallFilter_module</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SystemCallFilter_raw_io</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SystemCallFilter_reboot</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SystemCallFilter_privileged</entry>
|
|
</row>
|
|
<row>
|
|
<entry>SystemCallFilter_resources</entry>
|
|
</row>
|
|
<row>
|
|
<entry>IPAddressDeny</entry>
|
|
</row>
|
|
<row>
|
|
<entry>DeviceAllow</entry>
|
|
</row>
|
|
<row>
|
|
<entry>AmbientCapabilities</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>See example "JSON Policy" below.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--json=<replaceable>MODE</replaceable></option></term>
|
|
|
|
<listitem><para>With the <command>security</command> command, generate a JSON formatted
|
|
output of the security analysis table. The format is a JSON array with objects
|
|
containing the following fields: <varname>set</varname> which indicates if the setting has
|
|
been enabled or not, <varname>name</varname> which is what is used to refer to the setting,
|
|
<varname>json_field</varname> which is the JSON compatible identifier of the setting,
|
|
<varname>description</varname> which is an outline of the setting state, and
|
|
<varname>exposure</varname> which is a number in the range 0.0…10.0, where a higher value
|
|
corresponds to a higher security threat. The JSON version of the table is printed to standard
|
|
output. The <replaceable>MODE</replaceable> passed to the option can be one of three:
|
|
<option>off</option> which is the default, <option>pretty</option> and <option>short</option>
|
|
which respectively output a prettified or shorted JSON version of the security table.</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>
|
|
|
|
<varlistentry>
|
|
<term><option>--unit=<replaceable>UNIT</replaceable></option></term>
|
|
|
|
<listitem><para>When used with the <command>condition</command> command, evaluate all the
|
|
<varname index="false">Condition*=...</varname> and <varname index="false">Assert*=...</varname>
|
|
assignments in the specified unit file. The full unit search path is formed by combining the
|
|
directories for the specified unit with 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 directory containing the specified unit will be used in preference to the
|
|
other paths.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<xi:include href="user-system-options.xml" xpointer="host" />
|
|
<xi:include href="user-system-options.xml" xpointer="machine" />
|
|
|
|
<varlistentry>
|
|
<term><option>--quiet</option></term>
|
|
|
|
<listitem><para>Suppress hints and other non-essential output.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<xi:include href="standard-options.xml" xpointer="help" />
|
|
<xi:include href="standard-options.xml" xpointer="version" />
|
|
<xi:include href="standard-options.xml" xpointer="no-pager" />
|
|
</variablelist>
|
|
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Exit status</title>
|
|
|
|
<para>On success, 0 is returned, a non-zero failure code
|
|
otherwise.</para>
|
|
</refsect1>
|
|
|
|
<xi:include href="common-variables.xml" />
|
|
|
|
<refsect1>
|
|
<title>Examples</title>
|
|
|
|
<example>
|
|
<title>JSON Policy</title>
|
|
|
|
<para>The JSON file passed as a path parameter to <option>--security-policy=</option> has a top-level
|
|
JSON object, with keys being the assessment test identifiers mentioned above. The values in the file
|
|
should be JSON objects with one or more of the following fields: <option>description_na</option>
|
|
(string), <option>description_good</option> (string), <option>description_bad</option> (string),
|
|
<option>weight</option> (unsigned integer), and <option>range</option> (unsigned integer). If any of
|
|
these fields corresponding to a specific id of the unit file is missing from the JSON object, the
|
|
default built-in field value corresponding to that same id is used for security analysis as default.
|
|
The weight and range fields are used in determining the overall exposure level of the unit files: the
|
|
value of each setting is assigned a badness score, which is multiplied by the policy weight and divided
|
|
by the policy range to determine the overall exposure that the setting implies. The computed badness is
|
|
summed across all settings in the unit file, normalized to the 1…100 range, and used to determine the
|
|
overall exposure level of the unit. By allowing users to manipulate these fields, the 'security' verb
|
|
gives them the option to decide for themself which ids are more important and hence should have a
|
|
greater effect on the exposure level. A weight of <literal>0</literal> means the setting will not be
|
|
checked.</para>
|
|
|
|
<programlisting>
|
|
{
|
|
"PrivateDevices":
|
|
{
|
|
"description_good": "Service has no access to hardware devices",
|
|
"description_bad": "Service potentially has access to hardware devices",
|
|
"weight": 1000,
|
|
"range": 1
|
|
},
|
|
"PrivateMounts":
|
|
{
|
|
"description_good": "Service cannot install system mounts",
|
|
"description_bad": "Service may install system mounts",
|
|
"weight": 1000,
|
|
"range": 1
|
|
},
|
|
"PrivateNetwork":
|
|
{
|
|
"description_good": "Service has no access to the host's network",
|
|
"description_bad": "Service has access to the host's network",
|
|
"weight": 2500,
|
|
"range": 1
|
|
},
|
|
"PrivateTmp":
|
|
{
|
|
"description_good": "Service has no access to other software's temporary files",
|
|
"description_bad": "Service has access to other software's temporary files",
|
|
"weight": 1000,
|
|
"range": 1
|
|
},
|
|
"PrivateUsers":
|
|
{
|
|
"description_good": "Service does not have access to other users",
|
|
"description_bad": "Service has access to other users",
|
|
"weight": 1000,
|
|
"range": 1
|
|
}
|
|
}
|
|
</programlisting>
|
|
</example>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
<para>
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|