| <?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> |
| <arg choice="opt" rep="repeat"><replaceable>PATTERN</replaceable></arg> |
| </cmdsynopsis> |
| |
| <cmdsynopsis> |
| <command>systemd-analyze</command> |
| <arg choice="opt" rep="repeat">OPTIONS</arg> |
| <arg choice="plain">plot</arg> |
| <arg choice="opt">>file.svg</arg> |
| </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-files</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">compare-versions</arg> |
| <arg choice="plain"><replaceable>VERSION1</replaceable></arg> |
| <arg choice="opt"><replaceable>OP</replaceable></arg> |
| <arg choice="plain"><replaceable>VERSION2</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> |
| <cmdsynopsis> |
| <command>systemd-analyze</command> |
| <arg choice="opt" rep="repeat">OPTIONS</arg> |
| <arg choice="plain">inspect-elf</arg> |
| <arg choice="plain" rep="repeat"><replaceable>FILE</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 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, similarly 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 [<replaceable>pattern</replaceable>…]</command></title> |
| |
| <para>Without any parameter, this command outputs a (usually very long) human-readable serialization of |
| the complete service manager state. Optional glob pattern may be specified, causing the output to be |
| limited to units whose names match one of the patterns. The output 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 either an SVG graphic, detailing which system services have been started at what |
| time, highlighting the time they spent on initialization, or the raw time data in JSON or table format.</para> |
| |
| <example> |
| <title><command>Plot a bootchart</command></title> |
| |
| <programlisting>$ systemd-analyze plot >bootup.svg |
| $ eog bootup.svg& |
| </programlisting> |
| </example> |
| |
| <para>Note that this plot is based on the most recent per-unit timing data of loaded units. This means |
| that if a unit gets started, then stopped and then started again the information shown will cover the |
| most recent start cycle, not the first one. Thus it's recommended to consult this information only |
| shortly after boot, so that this distinction doesn't matter. Moreover, units that are not referenced by |
| any other unit through a dependency might be unloaded by the service manager once they terminate (and |
| did not fail). Such units will not show up in the plot.</para> |
| </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 compare-versions |
| <replaceable>VERSION1</replaceable> |
| <optional><replaceable>OP</replaceable></optional> |
| <replaceable>VERSION2</replaceable></command></title> |
| |
| <para>This command has two distinct modes of operation, depending on whether the operator |
| <replaceable>OP</replaceable> is specified.</para> |
| |
| <para>In the first mode — when <replaceable>OP</replaceable> is not specified — it will compare the two |
| version strings and print either <literal><replaceable>VERSION1</replaceable> < |
| <replaceable>VERSION2</replaceable></literal>, or <literal><replaceable>VERSION1</replaceable> == |
| <replaceable>VERSION2</replaceable></literal>, or <literal><replaceable>VERSION1</replaceable> > |
| <replaceable>VERSION2</replaceable></literal> as appropriate.</para> |
| |
| <para>The exit status is <constant>0</constant> if the versions are equal, <constant>11</constant> if |
| the version of the right is smaller, and <constant>12</constant> if the version of the left is |
| smaller. (This matches the convention used by <command>rpmdev-vercmp</command>.)</para> |
| |
| <para>In the second mode — when <replaceable>OP</replaceable> is specified — it will compare the two |
| version strings using the operation <replaceable>OP</replaceable> and return <constant>0</constant> |
| (success) if they condition is satisfied, and <constant>1</constant> (failure) |
| otherwise. <constant>OP</constant> may be <command>lt</command>, <command>le</command>, |
| <command>eq</command>, <command>ne</command>, <command>ge</command>, <command>gt</command>. In this |
| mode, no output is printed. |
| (This matches the convention used by |
| <citerefentry project='die-net'><refentrytitle>dpkg</refentrytitle><manvolnum>1</manvolnum></citerefentry> |
| <option>--compare-versions</option>.)</para> |
| |
| <example> |
| <title>Compare versions of a package</title> |
| |
| <programlisting> |
| $ systemd-analyze compare-versions systemd-250~rc1.fc36.aarch64 systemd-251.fc36.aarch64 |
| systemd-250~rc1.fc36.aarch64 < systemd-251.fc36.aarch64 |
| $ echo $? |
| 12 |
| |
| $ systemd-analyze compare-versions 1 lt 2; echo $? |
| 0 |
| $ systemd-analyze compare-versions 1 ge 2; echo $? |
| 1 |
| </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 files, 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 files, 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 unit 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 files. 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. |
| |
| With the <command>plot</command> command, generate a JSON formatted output of the raw time data. |
| The format is a JSON array with objects containing the following fields: <varname>name</varname> |
| which is the unit name, <varname>activated</varname> which is the time after startup the |
| service was activated, <varname>activating</varname> which is how long after startup the service |
| was initially started, <varname>time</varname> which is how long the service took to activate |
| from when it was initially started, <varname>deactivated</varname> which is the time after startup |
| that the service was deactivated, <varname>deactivating</varname> which is the time after startup |
| that the service was initially told to deactivate. |
| </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> |
| |
| <varlistentry> |
| <term><option>--table</option></term> |
| |
| <listitem><para>When used with the <command>plot</command> command, the raw time data is output in a table. |
| </para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><option>--no-legend</option></term> |
| |
| <listitem><para>When used with the <command>plot</command> command in combination with either |
| <option>--table</option> or <option>--json=</option>, no legends or hints are included in the output. |
| </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>For most commands, 0 is returned on success, and a non-zero failure code otherwise.</para> |
| |
| <para>With the verb <command>compare-versions</command>, in the two-argument form, |
| <constant>12</constant>, <constant>0</constant>, <constant>11</constant> is returned if the second |
| version string is respectively larger, equal, or smaller to the first. In the three-argument form, |
| <constant>0</constant> or <constant>1</constant> if the condition is respectively true or false.</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> |
