1SYSTEMD-ANALYZE(1)              systemd-analyze             SYSTEMD-ANALYZE(1)
2
3
4

NAME

6       systemd-analyze - Analyze and debug system manager
7

SYNOPSIS

9       systemd-analyze [OPTIONS...] [time]
10
11       systemd-analyze [OPTIONS...] blame
12
13       systemd-analyze [OPTIONS...] critical-chain [UNIT...]
14
15       systemd-analyze [OPTIONS...] dump
16
17       systemd-analyze [OPTIONS...] plot [>file.svg]
18
19       systemd-analyze [OPTIONS...] dot [PATTERN...] [>file.dot]
20
21       systemd-analyze [OPTIONS...] unit-paths
22
23       systemd-analyze [OPTIONS...] exit-status [STATUS...]
24
25       systemd-analyze [OPTIONS...] condition CONDITION...
26
27       systemd-analyze [OPTIONS...] syscall-filter [SET...]
28
29       systemd-analyze [OPTIONS...] calendar SPEC...
30
31       systemd-analyze [OPTIONS...] timestamp TIMESTAMP...
32
33       systemd-analyze [OPTIONS...] timespan SPAN...
34
35       systemd-analyze [OPTIONS...] cat-config NAME|PATH...
36
37       systemd-analyze [OPTIONS...] verify [FILE...]
38
39       systemd-analyze [OPTIONS...] security UNIT...
40

DESCRIPTION

42       systemd-analyze may be used to determine system boot-up performance
43       statistics and retrieve other state and tracing information from the
44       system and service manager, and to verify the correctness of unit
45       files. It is also used to access special functions useful for advanced
46       system manager debugging.
47
48       If no command is passed, systemd-analyze time is implied.
49
50   systemd-analyze time
51       This command prints the time spent in the kernel before userspace has
52       been reached, the time spent in the initial RAM disk (initrd) before
53       normal system userspace has been reached, and the time normal system
54       userspace took to initialize. Note that these measurements simply
55       measure the time passed up to the point where all system services have
56       been spawned, but not necessarily until they fully finished
57       initialization or the disk is idle.
58
59       Example 1. Show how long the boot took
60
61           # in a container
62           $ systemd-analyze time
63           Startup finished in 296ms (userspace)
64           multi-user.target reached after 275ms in userspace
65
66           # on a real machine
67           $ systemd-analyze time
68           Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s
69           multi-user.target reached after 47.820s in userspace
70
71   systemd-analyze blame
72       This command prints a list of all running units, ordered by the time
73       they took to initialize. This information may be used to optimize
74       boot-up times. Note that the output might be misleading as the
75       initialization of one service might be slow simply because it waits for
76       the initialization of another service to complete. Also note:
77       systemd-analyze blame doesn't display results for services with
78       Type=simple, because systemd considers such services to be started
79       immediately, hence no measurement of the initialization delays can be
80       done. Also note that this command only shows the time units took for
81       starting up, it does not show how long unit jobs spent in the execution
82       queue. In particular it shows the time units spent in "activating"
83       state, which is not defined for units such as device units that
84       transition directly from "inactive" to "active". This command hence
85       gives an impression of the performance of program code, but cannot
86       accurately reflect latency introduced by waiting for hardware and
87       similar events.
88
89       Example 2. Show which units took the most time during boot
90
91           $ systemd-analyze blame
92                    32.875s pmlogger.service
93                    20.905s systemd-networkd-wait-online.service
94                    13.299s dev-vda1.device
95                    ...
96                       23ms sysroot.mount
97                       11ms initrd-udevadm-cleanup-db.service
98                        3ms sys-kernel-config.mount
99
100
101   systemd-analyze critical-chain [UNIT...]
102       This command prints a tree of the time-critical chain of units (for
103       each of the specified UNITs or for the default target otherwise). The
104       time after the unit is active or started is printed after the "@"
105       character. The time the unit takes to start is printed after the "+"
106       character. Note that the output might be misleading as the
107       initialization of services might depend on socket activation and
108       because of the parallel execution of units. Also, similar to the blame
109       command, this only takes into account the time units spent in
110       "activating" state, and hence does not cover units that never went
111       through an "activating" state (such as device units that transition
112       directly from "inactive" to "active"). Moreover it does not show
113       information on jobs (and in particular not jobs that timed out).
114
115       Example 3. systemd-analyze critical-chain
116
117           $ systemd-analyze critical-chain
118           multi-user.target @47.820s
119           └─pmie.service @35.968s +548ms
120             └─pmcd.service @33.715s +2.247s
121               └─network-online.target @33.712s
122                 └─systemd-networkd-wait-online.service @12.804s +20.905s
123                   └─systemd-networkd.service @11.109s +1.690s
124                     └─systemd-udevd.service @9.201s +1.904s
125                       └─systemd-tmpfiles-setup-dev.service @7.306s +1.776s
126                         └─kmod-static-nodes.service @6.976s +177ms
127                           └─systemd-journald.socket
128                             └─system.slice
129                               └─-.slice
130
131   systemd-analyze dump
132       This command outputs a (usually very long) human-readable serialization
133       of the complete server state. Its format is subject to change without
134       notice and should not be parsed by applications.
135
136       Example 4. Show the internal state of user manager
137
138           $ systemd-analyze --user dump
139           Timestamp userspace: Thu 2019-03-14 23:28:07 CET
140           Timestamp finish: Thu 2019-03-14 23:28:07 CET
141           Timestamp generators-start: Thu 2019-03-14 23:28:07 CET
142           Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET
143           Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET
144           Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET
145           -> Unit proc-timer_list.mount:
146                   Description: /proc/timer_list
147                   ...
148           -> Unit default.target:
149                   Description: Main user target
150           ...
151
152   systemd-analyze plot
153       This command prints an SVG graphic detailing which system services have
154       been started at what time, highlighting the time they spent on
155       initialization.
156
157       Example 5. Plot a bootchart
158
159           $ systemd-analyze plot >bootup.svg
160           $ eog bootup.svg&
161
162   systemd-analyze dot [pattern...]
163       This command generates textual dependency graph description in dot
164       format for further processing with the GraphViz dot(1) tool. Use a
165       command line like systemd-analyze dot | dot -Tsvg >systemd.svg to
166       generate a graphical dependency tree. Unless --order or --require is
167       passed, the generated graph will show both ordering and requirement
168       dependencies. Optional pattern globbing style specifications (e.g.
169       *.target) may be given at the end. A unit dependency is included in the
170       graph if any of these patterns match either the origin or destination
171       node.
172
173       Example 6. Plot all dependencies of any unit whose name starts with
174       "avahi-daemon"
175
176           $ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg
177           $ eog avahi.svg
178
179       Example 7. Plot the dependencies between all known target units
180
181           $ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' \
182                 | dot -Tsvg >targets.svg
183           $ eog targets.svg
184
185   systemd-analyze unit-paths
186       This command outputs a list of all directories from which unit files,
187       .d overrides, and .wants, .requires symlinks may be loaded. Combine
188       with --user to retrieve the list for the user manager instance, and
189       --global for the global configuration of user manager instances.
190
191       Example 8. Show all paths for generated units
192
193           $ systemd-analyze unit-paths | grep '^/run'
194           /run/systemd/system.control
195           /run/systemd/transient
196           /run/systemd/generator.early
197           /run/systemd/system
198           /run/systemd/system.attached
199           /run/systemd/generator
200           /run/systemd/generator.late
201
202       Note that this verb prints the list that is compiled into
203       systemd-analyze itself, and does not communicate with the running
204       manager. Use
205
206           systemctl [--user] [--global] show -p UnitPath --value
207
208       to retrieve the actual list that the manager uses, with any empty
209       directories omitted.
210
211   systemd-analyze exit-status [STATUS...]
212       This command prints a list of exit statuses along with their "class",
213       i.e. the source of the definition (one of "glibc", "systemd", "LSB", or
214       "BSD"), see the Process Exit Codes section in systemd.exec(5). If no
215       additional arguments are specified, all known statuses are are shown.
216       Otherwise, only the definitions for the specified codes are shown.
217
218       Example 9. Show some example exit status names
219
220           $ systemd-analyze exit-status 0 1 {63..65}
221           NAME    STATUS CLASS
222           SUCCESS 0      glibc
223           FAILURE 1      glibc
224           -       63     -
225           USAGE   64     BSD
226           DATAERR 65     BSD
227
228   systemd-analyze condition CONDITION...
229       This command will evaluate Condition*=...  and Assert*=...
230       assignments, and print their values, and the resulting value of the
231       combined condition set. See systemd.unit(5) for a list of available
232       conditions and asserts.
233
234       Example 10. Evaluate conditions that check kernel versions
235
236           $ systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
237                   'ConditionKernelVersion = >=5.1' \
238                   'ConditionACPower=|false' \
239                   'ConditionArchitecture=|!arm' \
240                   'AssertPathExists=/etc/os-release'
241           test.service: AssertPathExists=/etc/os-release succeeded.
242           Asserts succeeded.
243           test.service: ConditionArchitecture=|!arm succeeded.
244           test.service: ConditionACPower=|false failed.
245           test.service: ConditionKernelVersion=>=5.1 succeeded.
246           test.service: ConditionKernelVersion=!<4.0 succeeded.
247           Conditions succeeded.
248
249   systemd-analyze syscall-filter [SET...]
250       This command will list system calls contained in the specified system
251       call set SET, or all known sets if no sets are specified. Argument SET
252       must include the "@" prefix.
253
254   systemd-analyze calendar EXPRESSION...
255       This command will parse and normalize repetitive calendar time events,
256       and will calculate when they elapse next. This takes the same input as
257       the OnCalendar= setting in systemd.timer(5), following the syntax
258       described in systemd.time(7). By default, only the next time the
259       calendar expression will elapse is shown; use --iterations= to show the
260       specified number of next times the expression elapses. Each time the
261       expression elapses forms a timestamp, see the timestamp verb below.
262
263       Example 11. Show leap days in the near future
264
265           $ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'
266             Original form: *-2-29 0:0:0
267           Normalized form: *-02-29 00:00:00
268               Next elapse: Sat 2020-02-29 00:00:00 UTC
269                  From now: 11 months 15 days left
270                  Iter. #2: Thu 2024-02-29 00:00:00 UTC
271                  From now: 4 years 11 months left
272                  Iter. #3: Tue 2028-02-29 00:00:00 UTC
273                  From now: 8 years 11 months left
274                  Iter. #4: Sun 2032-02-29 00:00:00 UTC
275                  From now: 12 years 11 months left
276                  Iter. #5: Fri 2036-02-29 00:00:00 UTC
277                  From now: 16 years 11 months left
278
279   systemd-analyze timestamp TIMESTAMP...
280       This command parses a timestamp (i.e. a single point in time) and
281       outputs the normalized form and the difference between this timestamp
282       and now. The timestamp should adhere to the syntax documented in
283       systemd.time(7), section "PARSING TIMESTAMPS".
284
285       Example 12. Show parsing of timestamps
286
287           $ systemd-analyze timestamp yesterday now tomorrow
288             Original form: yesterday
289           Normalized form: Mon 2019-05-20 00:00:00 CEST
290                  (in UTC): Sun 2019-05-19 22:00:00 UTC
291              UNIX seconds: @15583032000
292                  From now: 1 day 9h ago
293
294             Original form: now
295           Normalized form: Tue 2019-05-21 09:48:39 CEST
296                  (in UTC): Tue 2019-05-21 07:48:39 UTC
297              UNIX seconds: @1558424919.659757
298                  From now: 43us ago
299
300             Original form: tomorrow
301           Normalized form: Wed 2019-05-22 00:00:00 CEST
302                  (in UTC): Tue 2019-05-21 22:00:00 UTC
303              UNIX seconds: @15584760000
304                  From now: 14h left
305
306   systemd-analyze timespan EXPRESSION...
307       This command parses a time span (i.e. a difference between two
308       timestamps) and outputs the normalized form and the equivalent value in
309       microseconds. The time span should adhere to the syntax documented in
310       systemd.time(7), section "PARSING TIME SPANS". Values without units are
311       parsed as seconds.
312
313       Example 13. Show parsing of timespans
314
315           $ systemd-analyze timespan 1s 300s '1year 0.000001s'
316           Original: 1s
317                 μs: 1000000
318              Human: 1s
319
320           Original: 300s
321                 μs: 300000000
322              Human: 5min
323
324           Original: 1year 0.000001s
325                 μs: 31557600000001
326              Human: 1y 1us
327
328   systemd-analyze cat-config NAME|PATH...
329       This command is similar to systemctl cat, but operates on config files.
330       It will copy the contents of a config file and any drop-ins to standard
331       output, using the usual systemd set of directories and rules for
332       precedence. Each argument must be either an absolute path including the
333       prefix (such as /etc/systemd/logind.conf or
334       /usr/lib/systemd/logind.conf), or a name relative to the prefix (such
335       as systemd/logind.conf).
336
337       Example 14. Showing logind configuration
338
339           $ systemd-analyze cat-config systemd/logind.conf
340           # /etc/systemd/logind.conf
341           ...
342           [Login]
343           NAutoVTs=8
344           ...
345
346           # /usr/lib/systemd/logind.conf.d/20-test.conf
347           ... some override from another package
348
349           # /etc/systemd/logind.conf.d/50-override.conf
350           ... some administrator override
351
352
353   systemd-analyze verify FILE...
354       This command will load unit files and print warnings if any errors are
355       detected. Files specified on the command line will be loaded, but also
356       any other units referenced by them. The full unit search path is formed
357       by combining the directories for all command line arguments, and the
358       usual unit load paths. The variable $SYSTEMD_UNIT_PATH is supported,
359       and may be used to replace or augment the compiled in set of unit load
360       paths; see systemd.unit(5). All units files present in the directories
361       containing the command line arguments will be used in preference to the
362       other paths.
363
364       The following errors are currently detected:
365
366       ·   unknown sections and directives,
367
368       ·   missing dependencies which are required to start the given unit,
369
370       ·   man pages listed in Documentation= which are not found in the
371           system,
372
373       ·   commands listed in ExecStart= and similar which are not found in
374           the system or not executable.
375
376       Example 15. Misspelt directives
377
378           $ cat ./user.slice
379           [Unit]
380           WhatIsThis=11
381           Documentation=man:nosuchfile(1)
382           Requires=different.service
383
384           [Service]
385           Description=x
386
387           $ systemd-analyze verify ./user.slice
388           [./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
389           [./user.slice:13] Unknown section 'Service'. Ignoring.
390           Error: org.freedesktop.systemd1.LoadFailed:
391              Unit different.service failed to load:
392              No such file or directory.
393           Failed to create user.slice/start: Invalid argument
394           user.slice: man nosuchfile(1) command failed with code 16
395
396
397       Example 16. Missing service units
398
399           $ tail ./a.socket ./b.socket
400           ==> ./a.socket <==
401           [Socket]
402           ListenStream=100
403
404           ==> ./b.socket <==
405           [Socket]
406           ListenStream=100
407           Accept=yes
408
409           $ systemd-analyze verify ./a.socket ./b.socket
410           Service a.service not loaded, a.socket cannot be started.
411           Service b@0.service not loaded, b.socket cannot be started.
412
413
414   systemd-analyze security [UNIT...]
415       This command analyzes the security and sandboxing settings of one or
416       more specified service units. If at least one unit name is specified
417       the security settings of the specified service units are inspected and
418       a detailed analysis is shown. If no unit name is specified, all
419       currently loaded, long-running service units are inspected and a terse
420       table with results shown. The command checks for various
421       security-related service settings, assigning each a numeric "exposure
422       level" value, depending on how important a setting is. It then
423       calculates an overall exposure level for the whole unit, which is an
424       estimation in the range 0.0...10.0 indicating how exposed a service is
425       security-wise. High exposure levels indicate very little applied
426       sandboxing. Low exposure levels indicate tight sandboxing and strongest
427       security restrictions. Note that this only analyzes the per-service
428       security features systemd itself implements. This means that any
429       additional security mechanisms applied by the service code itself are
430       not accounted for. The exposure level determined this way should not be
431       misunderstood: a high exposure level neither means that there is no
432       effective sandboxing applied by the service code itself, nor that the
433       service is actually vulnerable to remote or local attacks. High
434       exposure levels do indicate however that most likely the service might
435       benefit from additional settings applied to them.
436
437       Please note that many of the security and sandboxing settings
438       individually can be circumvented — unless combined with others. For
439       example, if a service retains the privilege to establish or undo mount
440       points many of the sandboxing options can be undone by the service code
441       itself. Due to that is essential that each service uses the most
442       comprehensive and strict sandboxing and security settings possible. The
443       tool will take into account some of these combinations and
444       relationships between the settings, but not all. Also note that the
445       security and sandboxing settings analyzed here only apply to the
446       operations executed by the service code itself. If a service has access
447       to an IPC system (such as D-Bus) it might request operations from other
448       services that are not subject to the same restrictions. Any
449       comprehensive security and sandboxing analysis is hence incomplete if
450       the IPC access policy is not validated too.
451
452       Example 17. Analyze systemd-logind.service
453
454           $ systemd-analyze security --no-pager systemd-logind.service
455             NAME                DESCRIPTION                              EXPOSURE
456           ✗ PrivateNetwork=     Service has access to the host's network      0.5
457           ✗ User=/DynamicUser=  Service runs as root user                     0.4
458           ✗ DeviceAllow=        Service has no device ACL                     0.2
459           ✓ IPAddressDeny=      Service blocks all IP address ranges
460           ...
461           → Overall exposure level for systemd-logind.service: 4.1 OK 🙂
462

OPTIONS

464       The following options are understood:
465
466       --system
467           Operates on the system systemd instance. This is the implied
468           default.
469
470       --user
471           Operates on the user systemd instance.
472
473       --global
474           Operates on the system-wide configuration for user systemd
475           instance.
476
477       --order, --require
478           When used in conjunction with the dot command (see above), selects
479           which dependencies are shown in the dependency graph. If --order is
480           passed, only dependencies of type After= or Before= are shown. If
481           --require is passed, only dependencies of type Requires=,
482           Requisite=, Wants= and Conflicts= are shown. If neither is passed,
483           this shows dependencies of all these types.
484
485       --from-pattern=, --to-pattern=
486           When used in conjunction with the dot command (see above), this
487           selects which relationships are shown in the dependency graph. Both
488           options require a glob(7) pattern as an argument, which will be
489           matched against the left-hand and the right-hand, respectively,
490           nodes of a relationship.
491
492           Each of these can be used more than once, in which case the unit
493           name must match one of the values. When tests for both sides of the
494           relation are present, a relation must pass both tests to be shown.
495           When patterns are also specified as positional arguments, they must
496           match at least one side of the relation. In other words, patterns
497           specified with those two options will trim the list of edges
498           matched by the positional arguments, if any are given, and fully
499           determine the list of edges shown otherwise.
500
501       --fuzz=timespan
502           When used in conjunction with the critical-chain command (see
503           above), also show units, which finished timespan earlier, than the
504           latest unit in the same level. The unit of timespan is seconds
505           unless specified with a different unit, e.g. "50ms".
506
507       --man=no
508           Do not invoke man(1) to verify the existence of man pages listed in
509           Documentation=.
510
511       --generators
512           Invoke unit generators, see systemd.generator(7). Some generators
513           require root privileges. Under a normal user, running with
514           generators enabled will generally result in some warnings.
515
516       --root=PATH
517           With cat-files, show config files underneath the specified root
518           path PATH.
519
520       --iterations=NUMBER
521           When used with the calendar command, show the specified number of
522           iterations the specified calendar expression will elapse next.
523           Defaults to 1.
524
525       --base-time=TIMESTAMP
526           When used with the calendar command, show next iterations relative
527           to the specified point in time. If not specified defaults to the
528           current time.
529
530       -H, --host=
531           Execute the operation remotely. Specify a hostname, or a username
532           and hostname separated by "@", to connect to. The hostname may
533           optionally be suffixed by a port ssh is listening on, separated by
534           ":", and then a container name, separated by "/", which connects
535           directly to a specific container on the specified host. This will
536           use SSH to talk to the remote machine manager instance. Container
537           names may be enumerated with machinectl -H HOST. Put IPv6 addresses
538           in brackets.
539
540       -M, --machine=
541           Execute operation on a local container. Specify a container name to
542           connect to.
543
544       -h, --help
545           Print a short help text and exit.
546
547       --version
548           Print a short version string and exit.
549
550       --no-pager
551           Do not pipe output into a pager.
552

EXIT STATUS

554       On success, 0 is returned, a non-zero failure code otherwise.
555

ENVIRONMENT

557       $SYSTEMD_PAGER
558           Pager to use when --no-pager is not given; overrides $PAGER. If
559           neither $SYSTEMD_PAGER nor $PAGER are set, a set of well-known
560           pager implementations are tried in turn, including less(1) and
561           more(1), until one is found. If no pager implementation is
562           discovered no pager is invoked. Setting this environment variable
563           to an empty string or the value "cat" is equivalent to passing
564           --no-pager.
565
566       $SYSTEMD_LESS
567           Override the options passed to less (by default "FRSXMK").
568
569           Users might want to change two options in particular:
570
571           K
572               This option instructs the pager to exit immediately when Ctrl+C
573               is pressed. To allow less to handle Ctrl+C itself to switch
574               back to the pager command prompt, unset this option.
575
576               If the value of $SYSTEMD_LESS does not include "K", and the
577               pager that is invoked is less, Ctrl+C will be ignored by the
578               executable, and needs to be handled by the pager.
579
580           X
581               This option instructs the pager to not send termcap
582               initialization and deinitialization strings to the terminal. It
583               is set by default to allow command output to remain visible in
584               the terminal even after the pager exits. Nevertheless, this
585               prevents some pager functionality from working, in particular
586               paged output cannot be scrolled with the mouse.
587
588           See less(1) for more discussion.
589
590       $SYSTEMD_LESSCHARSET
591           Override the charset passed to less (by default "utf-8", if the
592           invoking terminal is determined to be UTF-8 compatible).
593
594       $SYSTEMD_PAGERSECURE
595           Takes a boolean argument. When true, the "secure" mode of the pager
596           is enabled; if false, disabled. If $SYSTEMD_PAGERSECURE is not set
597           at all, secure mode is enabled if the effective UID is not the same
598           as the owner of the login session, see geteuid(2) and
599           sd_pid_get_owner_uid(3). In secure mode, LESSSECURE=1 will be set
600           when invoking the pager, and the pager shall disable commands that
601           open or create new files or start new subprocesses. When
602           $SYSTEMD_PAGERSECURE is not set at all, pagers which are not known
603           to implement secure mode will not be used. (Currently only less(1)
604           implements secure mode.)
605
606           Note: when commands are invoked with elevated privileges, for
607           example under sudo(8) or pkexec(1), care must be taken to ensure
608           that unintended interactive features are not enabled. "Secure" mode
609           for the pager may be enabled automatically as describe above.
610           Setting SYSTEMD_PAGERSECURE=0 or not removing it from the inherited
611           environment allows the user to invoke arbitrary commands. Note that
612           if the $SYSTEMD_PAGER or $PAGER variables are to be honoured,
613           $SYSTEMD_PAGERSECURE must be set too. It might be reasonable to
614           completly disable the pager using --no-pager instead.
615
616       $SYSTEMD_COLORS
617           The value must be a boolean. Controls whether colorized output
618           should be generated. This can be specified to override the decision
619           that systemd makes based on $TERM and what the console is connected
620           to.
621
622       $SYSTEMD_URLIFY
623           The value must be a boolean. Controls whether clickable links
624           should be generated in the output for terminal emulators supporting
625           this. This can be specified to override the decision that systemd
626           makes based on $TERM and other conditions.
627

SEE ALSO

629       systemd(1), systemctl(1)
630
631
632
633systemd 246                                                 SYSTEMD-ANALYZE(1)
Impressum