1SYSTEMD-ANALYZE(1) systemd-analyze SYSTEMD-ANALYZE(1)
2
6 systemd-analyze - Analyze and debug system manager
7
9 systemd-analyze [OPTIONS...] [time]
10 systemd-analyze [OPTIONS...] blame
12 systemd-analyze [OPTIONS...] critical-chain [UNIT...]
14 systemd-analyze [OPTIONS...] plot [> file.svg]
16 systemd-analyze [OPTIONS...] dot [PATTERN...] [> file.dot]
18 systemd-analyze [OPTIONS...] dump
20 systemd-analyze [OPTIONS...] cat-config NAME|PATH...
22 systemd-analyze [OPTIONS...] unit-paths
24 systemd-analyze [OPTIONS...] log-level [LEVEL]
26 systemd-analyze [OPTIONS...] log-target [TARGET]
28 systemd-analyze [OPTIONS...] syscall-filter [SET...]
30 systemd-analyze [OPTIONS...] verify [FILES...]
32 systemd-analyze [OPTIONS...] calendar SPECS...
34 systemd-analyze [OPTIONS...] service-watchdogs [BOOL]
36 systemd-analyze [OPTIONS...] timespan SPAN...
38 systemd-analyze [OPTIONS...] security UNIT...
40
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 systemd-analyze time prints the time spent in the kernel before
49 userspace has been reached, the time spent in the initial RAM disk
50 (initrd) before normal system userspace has been reached, and the time
51 normal system userspace took to initialize. Note that these
52 measurements simply measure the time passed up to the point where all
53 system services have been spawned, but not necessarily until they fully
54 finished initialization or the disk is idle.
55 systemd-analyze blame prints a list of all running units, ordered by
57 the time they took to initialize. This information may be used to
58 optimize boot-up times. Note that the output might be misleading as the
59 initialization of one service might be slow simply because it waits for
60 the initialization of another service to complete. Also note:
61 systemd-analyze blame doesn't display results for services with
62 Type=simple, because systemd considers such services to be started
63 immediately, hence no measurement of the initialization delays can be
64 done.
65 systemd-analyze critical-chain [UNIT...] prints a tree of the
67 time-critical chain of units (for each of the specified UNITs or for
68 the default target otherwise). The time after the unit is active or
69 started is printed after the "@" character. The time the unit takes to
70 start is printed after the "+" character. Note that the output might be
71 misleading as the initialization of one service might depend on socket
72 activation and because of the parallel execution of units.
73 systemd-analyze plot prints an SVG graphic detailing which system
75 services have been started at what time, highlighting the time they
76 spent on initialization.
77 systemd-analyze dot generates textual dependency graph description in
79 dot format for further processing with the GraphViz dot(1) tool. Use a
80 command line like systemd-analyze dot | dot -Tsvg > systemd.svg to
81 generate a graphical dependency tree. Unless --order or --require is
82 passed, the generated graph will show both ordering and requirement
83 dependencies. Optional pattern globbing style specifications (e.g.
84 *.target) may be given at the end. A unit dependency is included in the
85 graph if any of these patterns match either the origin or destination
86 node.
87 systemd-analyze dump outputs a (usually very long) human-readable
89 serialization of the complete server state. Its format is subject to
90 change without notice and should not be parsed by applications.
91 systemd-analyze cat-config is similar to systemctl cat, but operates on
93 config files. It will copy the contents of a config file and any
94 drop-ins to standard output, using the usual systemd set of directories
95 and rules for precedence. Each argument must be either an absolute path
96 including the prefix (such as /etc/systemd/logind.conf or
97 /usr/lib/systemd/logind.conf), or a name relative to the prefix (such
98 as systemd/logind.conf).
99 Example 1. Showing logind configuration
101 $ systemd-analyze cat-config systemd/logind.conf
103 # /etc/systemd/logind.conf
104 ...
105 [Login]
106 NAutoVTs=8
107 ...
108 # /usr/lib/systemd/logind.conf.d/20-test.conf
110 ... some override from another package
111 # /etc/systemd/logind.conf.d/50-override.conf
113 ... some administrator override
114 systemd-analyze unit-paths outputs a list of all directories from which
117 unit files, .d overrides, and .wants, .requires symlinks may be loaded.
118 Combine with --user to retrieve the list for the user manager instance,
119 and --global for the global configuration of user manager instances.
120 Note that this verb prints the list that is compiled into
121 systemd-analyze itself, and does not comunicate with the running
122 manager. Use
123 systemctl [--user] [--global] show -p UnitPath --value
125 to retrieve the actual list that the manager uses, with any empty
127 directories omitted.
128 systemd-analyze log-level prints the current log level of the systemd
130 daemon. If an optional argument LEVEL is provided, then the command
131 changes the current log level of the systemd daemon to LEVEL (accepts
132 the same values as --log-level= described in systemd(1)).
133 systemd-analyze log-target prints the current log target of the systemd
135 daemon. If an optional argument TARGET is provided, then the command
136 changes the current log target of the systemd daemon to TARGET (accepts
137 the same values as --log-target=, described in systemd(1)).
138 systemd-analyze syscall-filter [SET...] will list system calls
140 contained in the specified system call set SET, or all known sets if no
141 sets are specified. Argument SET must include the "@" prefix.
142 systemd-analyze verify will load unit files and print warnings if any
144 errors are detected. Files specified on the command line will be
145 loaded, but also any other units referenced by them. The full unit
146 search path is formed by combining the directories for all command line
147 arguments, and the usual unit load paths (variable $SYSTEMD_UNIT_PATH
148 is supported, and may be used to replace or augment the compiled in set
149 of unit load paths; see systemd.unit(5)). All units files present in
150 the directories containing the command line arguments will be used in
151 preference to the other paths.
152 systemd-analyze calendar will parse and normalize repetitive calendar
154 time events, and will calculate when they will elapse next. This takes
155 the same input as the OnCalendar= setting in systemd.timer(5),
156 following the syntax described in systemd.time(7).
157 systemd-analyze service-watchdogs prints the current state of service
159 runtime watchdogs of the systemd daemon. If an optional boolean
160 argument is provided, then globally enables or disables the service
161 runtime watchdogs (WatchdogSec=) and emergency actions (e.g.
162 OnFailure= or StartLimitAction=); see systemd.service(5). The hardware
163 watchdog is not affected by this setting.
164 systemd-analyze timespan parses a time span and outputs the equivalent
166 value in microseconds, and as a reformatted timespan. The time span
167 should adhere to the same syntax documented in systemd.time(7). Values
168 without associated magnitudes are parsed as seconds.
169 systemd-analyze security analyzes the security and sandboxing settings
171 of one or more specified service units. If at least one unit name is
172 specified the security settings of the specified service units are
173 inspected and a detailed analysis is shown. If no unit name is
174 specified, all currently loaded, long-running service units are
175 inspected and a terse table with results shown. The command checks for
176 various security-related service settings, assigning each a numeric
177 "exposure level" value, depending on how important a setting is. It
178 then calculates an overall exposure level for the whole unit, which is
179 an estimation in the range 0.0...10.0 indicating how exposed a service
180 is security-wise. High exposure levels indicate very little applied
181 sandboxing. Low exposure levels indicate tight sandboxing and strongest
182 security restrictions. Note that this only analyzes the per-service
183 security features systemd itself implements. This means that any
184 additional security mechanisms applied by the service code itself are
185 not accounted for. The exposure level determined this way should not be
186 misunderstood: a high exposure level neither means that there is no
187 effective sandboxing applied by the service code itself, nor that the
188 service is actually vulnerable to remote or local attacks. High
189 exposure levels do indicate however that most likely the service might
190 benefit from additional settings applied to them. Please note that many
191 of the security and sandboxing settings individually can be
192 circumvented — unless combined with others. For example, if a service
193 retains the privilege to establish or undo mount points many of the
194 sandboxing options can be undone by the service code itself. Due to
195 that is essential that each service uses the most comprehensive and
196 strict sandboxing and security settings possible. The tool will take
197 into account some of these combinations and relationships between the
198 settings, but not all. Also note that the security and sandboxing
199 settings analyzed here only apply to the operations executed by the
200 service code itself. If a service has access to an IPC system (such as
201 D-Bus) it might request operations from other services that are not
202 subject to the same restrictions. Any comprehensive security and
203 sandboxing analysis is hence incomplete if the IPC access policy is not
204 validated too.
205 If no command is passed, systemd-analyze time is implied.
207
209 The following options are understood:
210 --system
212 Operates on the system systemd instance. This is the implied
213 default.
214 --user
216 Operates on the user systemd instance.
217 --global
219 Operates on the system-wide configuration for user systemd
220 instance.
221 --order, --require
223 When used in conjunction with the dot command (see above), selects
224 which dependencies are shown in the dependency graph. If --order is
225 passed, only dependencies of type After= or Before= are shown. If
226 --require is passed, only dependencies of type Requires=,
227 Requisite=, Wants= and Conflicts= are shown. If neither is passed,
228 this shows dependencies of all these types.
229 --from-pattern=, --to-pattern=
231 When used in conjunction with the dot command (see above), this
232 selects which relationships are shown in the dependency graph. Both
233 options require a glob(7) pattern as an argument, which will be
234 matched against the left-hand and the right-hand, respectively,
235 nodes of a relationship.
236 Each of these can be used more than once, in which case the unit
238 name must match one of the values. When tests for both sides of the
239 relation are present, a relation must pass both tests to be shown.
240 When patterns are also specified as positional arguments, they must
241 match at least one side of the relation. In other words, patterns
242 specified with those two options will trim the list of edges
243 matched by the positional arguments, if any are given, and fully
244 determine the list of edges shown otherwise.
245 --fuzz=timespan
247 When used in conjunction with the critical-chain command (see
248 above), also show units, which finished timespan earlier, than the
249 latest unit in the same level. The unit of timespan is seconds
250 unless specified with a different unit, e.g. "50ms".
251 --man=no
253 Do not invoke man to verify the existence of man pages listed in
254 Documentation=.
255 --generators
257 Invoke unit generators, see systemd.generator(7). Some generators
258 require root privileges. Under a normal user, running with
259 generators enabled will generally result in some warnings.
260 --root=PATH
262 With cat-files, show config files underneath the specified root
263 path PATH.
264 -H, --host=
266 Execute the operation remotely. Specify a hostname, or a username
267 and hostname separated by "@", to connect to. The hostname may
268 optionally be suffixed by a port ssh is listening on, seperated by
269 ":", and then a container name, separated by "/", which connects
270 directly to a specific container on the specified host. This will
271 use SSH to talk to the remote machine manager instance. Container
272 names may be enumerated with machinectl -H HOST. Put IPv6 addresses
273 in brackets.
274 -M, --machine=
276 Execute operation on a local container. Specify a container name to
277 connect to.
278 -h, --help
280 Print a short help text and exit.
281 --version
283 Print a short version string and exit.
284 --no-pager
286 Do not pipe output into a pager.
287
289 On success, 0 is returned, a non-zero failure code otherwise.
290
292 Example 2. Plots all dependencies of any unit whose name starts with
293 "avahi-daemon"
294 $ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > avahi.svg
296 $ eog avahi.svg
297 Example 3. Plots the dependencies between all known target units
299 $ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' | dot -Tsvg > targets.svg
301 $ eog targets.svg
302
304 The following errors are currently detected:
305 · unknown sections and directives,
307 · missing dependencies which are required to start the given unit,
309 · man pages listed in Documentation= which are not found in the
311 system,
312 · commands listed in ExecStart= and similar which are not found in
314 the system or not executable.
315 Example 4. Misspelt directives
317 $ cat ./user.slice
319 [Unit]
320 WhatIsThis=11
321 Documentation=man:nosuchfile(1)
322 Requires=different.service
323 [Service]
325 Description=x
326 $ systemd-analyze verify ./user.slice
328 [./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
329 [./user.slice:13] Unknown section 'Service'. Ignoring.
330 Error: org.freedesktop.systemd1.LoadFailed:
331 Unit different.service failed to load:
332 No such file or directory.
333 Failed to create user.slice/start: Invalid argument
334 user.slice: man nosuchfile(1) command failed with code 16
335 Example 5. Missing service units
338 $ tail ./a.socket ./b.socket
340 ==> ./a.socket <==
341 [Socket]
342 ListenStream=100
343 ==> ./b.socket <==
345 [Socket]
346 ListenStream=100
347 Accept=yes
348 $ systemd-analyze verify ./a.socket ./b.socket
350 Service a.service not loaded, a.socket cannot be started.
351 Service b@0.service not loaded, b.socket cannot be started.
352
355 $SYSTEMD_PAGER
356 Pager to use when --no-pager is not given; overrides $PAGER. If
357 neither $SYSTEMD_PAGER nor $PAGER are set, a set of well-known
358 pager implementations are tried in turn, including less(1) and
359 more(1), until one is found. If no pager implementation is
360 discovered no pager is invoked. Setting this environment variable
361 to an empty string or the value "cat" is equivalent to passing
362 --no-pager.
363 $SYSTEMD_LESS
365 Override the options passed to less (by default "FRSXMK").
366 If the value of $SYSTEMD_LESS does not include "K", and the pager
368 that is invoked is less, Ctrl+C will be ignored by the executable.
369 This allows less to handle Ctrl+C itself.
370 $SYSTEMD_LESSCHARSET
372 Override the charset passed to less (by default "utf-8", if the
373 invoking terminal is determined to be UTF-8 compatible).
374
376 systemd(1), systemctl(1)
377systemd 241 SYSTEMD-ANALYZE(1)