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...] dump
16 systemd-analyze [OPTIONS...] plot [>file.svg]
18 systemd-analyze [OPTIONS...] dot [PATTERN...] [>file.dot]
20 systemd-analyze [OPTIONS...] unit-paths
22 systemd-analyze [OPTIONS...] exit-status [STATUS...]
24 systemd-analyze [OPTIONS...] capability [CAPABILITY...]
26 systemd-analyze [OPTIONS...] condition CONDITION...
28 systemd-analyze [OPTIONS...] syscall-filter [SET...]
30 systemd-analyze [OPTIONS...] calendar SPEC...
32 systemd-analyze [OPTIONS...] timestamp TIMESTAMP...
34 systemd-analyze [OPTIONS...] timespan SPAN...
36 systemd-analyze [OPTIONS...] cat-config NAME|PATH...
38 systemd-analyze [OPTIONS...] verify [FILE...]
40 systemd-analyze [OPTIONS...] security UNIT...
42
44 systemd-analyze may be used to determine system boot-up performance
45 statistics and retrieve other state and tracing information from the
46 system and service manager, and to verify the correctness of unit
47 files. It is also used to access special functions useful for advanced
48 system manager debugging.
49 If no command is passed, systemd-analyze time is implied.
51 systemd-analyze time
53 This command prints the time spent in the kernel before userspace has
54 been reached, the time spent in the initial RAM disk (initrd) before
55 normal system userspace has been reached, and the time normal system
56 userspace took to initialize. Note that these measurements simply
57 measure the time passed up to the point where all system services have
58 been spawned, but not necessarily until they fully finished
59 initialization or the disk is idle.
60 Example 1. Show how long the boot took
62 # in a container
64 $ systemd-analyze time
65 Startup finished in 296ms (userspace)
66 multi-user.target reached after 275ms in userspace
67 # on a real machine
69 $ systemd-analyze time
70 Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s
71 multi-user.target reached after 47.820s in userspace
72 systemd-analyze blame
74 This command prints a list of all running units, ordered by the time
75 they took to initialize. This information may be used to optimize
76 boot-up times. Note that the output might be misleading as the
77 initialization of one service might be slow simply because it waits for
78 the initialization of another service to complete. Also note:
79 systemd-analyze blame doesn't display results for services with
80 Type=simple, because systemd considers such services to be started
81 immediately, hence no measurement of the initialization delays can be
82 done. Also note that this command only shows the time units took for
83 starting up, it does not show how long unit jobs spent in the execution
84 queue. In particular it shows the time units spent in "activating"
85 state, which is not defined for units such as device units that
86 transition directly from "inactive" to "active". This command hence
87 gives an impression of the performance of program code, but cannot
88 accurately reflect latency introduced by waiting for hardware and
89 similar events.
90 Example 2. Show which units took the most time during boot
92 $ systemd-analyze blame
94 32.875s pmlogger.service
95 20.905s systemd-networkd-wait-online.service
96 13.299s dev-vda1.device
97 ...
98 23ms sysroot.mount
99 11ms initrd-udevadm-cleanup-db.service
100 3ms sys-kernel-config.mount
101 systemd-analyze critical-chain [UNIT...]
104 This command prints a tree of the time-critical chain of units (for
105 each of the specified UNITs or for the default target otherwise). The
106 time after the unit is active or started is printed after the "@"
107 character. The time the unit takes to start is printed after the "+"
108 character. Note that the output might be misleading as the
109 initialization of services might depend on socket activation and
110 because of the parallel execution of units. Also, similar to the blame
111 command, this only takes into account the time units spent in
112 "activating" state, and hence does not cover units that never went
113 through an "activating" state (such as device units that transition
114 directly from "inactive" to "active"). Moreover it does not show
115 information on jobs (and in particular not jobs that timed out).
116 Example 3. systemd-analyze critical-chain
118 $ systemd-analyze critical-chain
120 multi-user.target @47.820s
121 └─pmie.service @35.968s +548ms
122 └─pmcd.service @33.715s +2.247s
123 └─network-online.target @33.712s
124 └─systemd-networkd-wait-online.service @12.804s +20.905s
125 └─systemd-networkd.service @11.109s +1.690s
126 └─systemd-udevd.service @9.201s +1.904s
127 └─systemd-tmpfiles-setup-dev.service @7.306s +1.776s
128 └─kmod-static-nodes.service @6.976s +177ms
129 └─systemd-journald.socket
130 └─system.slice
131 └─-.slice
132 systemd-analyze dump
134 This command outputs a (usually very long) human-readable serialization
135 of the complete server state. Its format is subject to change without
136 notice and should not be parsed by applications.
137 Example 4. Show the internal state of user manager
139 $ systemd-analyze --user dump
141 Timestamp userspace: Thu 2019-03-14 23:28:07 CET
142 Timestamp finish: Thu 2019-03-14 23:28:07 CET
143 Timestamp generators-start: Thu 2019-03-14 23:28:07 CET
144 Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET
145 Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET
146 Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET
147 -> Unit proc-timer_list.mount:
148 Description: /proc/timer_list
149 ...
150 -> Unit default.target:
151 Description: Main user target
152 ...
153 systemd-analyze plot
155 This command prints an SVG graphic detailing which system services have
156 been started at what time, highlighting the time they spent on
157 initialization.
158 Example 5. Plot a bootchart
160 $ systemd-analyze plot >bootup.svg
162 $ eog bootup.svg&
163 systemd-analyze dot [pattern...]
165 This command generates textual dependency graph description in dot
166 format for further processing with the GraphViz dot(1) tool. Use a
167 command line like systemd-analyze dot | dot -Tsvg >systemd.svg to
168 generate a graphical dependency tree. Unless --order or --require is
169 passed, the generated graph will show both ordering and requirement
170 dependencies. Optional pattern globbing style specifications (e.g.
171 *.target) may be given at the end. A unit dependency is included in the
172 graph if any of these patterns match either the origin or destination
173 node.
174 Example 6. Plot all dependencies of any unit whose name starts with
176 "avahi-daemon"
177 $ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg
179 $ eog avahi.svg
180 Example 7. Plot the dependencies between all known target units
182 $ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' \
184 | dot -Tsvg >targets.svg
185 $ eog targets.svg
186 systemd-analyze unit-paths
188 This command outputs a list of all directories from which unit files,
189 .d overrides, and .wants, .requires symlinks may be loaded. Combine
190 with --user to retrieve the list for the user manager instance, and
191 --global for the global configuration of user manager instances.
192 Example 8. Show all paths for generated units
194 $ systemd-analyze unit-paths | grep '^/run'
196 /run/systemd/system.control
197 /run/systemd/transient
198 /run/systemd/generator.early
199 /run/systemd/system
200 /run/systemd/system.attached
201 /run/systemd/generator
202 /run/systemd/generator.late
203 Note that this verb prints the list that is compiled into
205 systemd-analyze itself, and does not communicate with the running
206 manager. Use
207 systemctl [--user] [--global] show -p UnitPath --value
209 to retrieve the actual list that the manager uses, with any empty
211 directories omitted.
212 systemd-analyze exit-status [STATUS...]
214 This command prints a list of exit statuses along with their "class",
215 i.e. the source of the definition (one of "glibc", "systemd", "LSB", or
216 "BSD"), see the Process Exit Codes section in systemd.exec(5). If no
217 additional arguments are specified, all known statuses are shown.
218 Otherwise, only the definitions for the specified codes are shown.
219 Example 9. Show some example exit status names
221 $ systemd-analyze exit-status 0 1 {63..65}
223 NAME STATUS CLASS
224 SUCCESS 0 glibc
225 FAILURE 1 glibc
226 - 63 -
227 USAGE 64 BSD
228 DATAERR 65 BSD
229 systemd-analyze capability [CAPABILITY...]
231 This command prints a list of Linux capabilities along with their
232 numeric IDs. See capabilities(7) for details. If no argument is
233 specified the full list of capabilities known to the service manager
234 and the kernel is shown. Capabilities defined by the kernel but not
235 known to the service manager are shown as "cap_???". Optionally, if
236 arguments are specified they may refer to specific cabilities by name
237 or numeric ID, in which case only the indicated capabilities are shown
238 in the table.
239 Example 10. Show some example capability names
241 $ systemd-analyze capability 0 1 {30..32}
243 NAME NUMBER
244 cap_chown 0
245 cap_dac_override 1
246 cap_audit_control 30
247 cap_setfcap 31
248 cap_mac_override 32
249 systemd-analyze condition CONDITION...
251 This command will evaluate Condition*=... and Assert*=...
252 assignments, and print their values, and the resulting value of the
253 combined condition set. See systemd.unit(5) for a list of available
254 conditions and asserts.
255 Example 11. Evaluate conditions that check kernel versions
257 $ systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
259 'ConditionKernelVersion = >=5.1' \
260 'ConditionACPower=|false' \
261 'ConditionArchitecture=|!arm' \
262 'AssertPathExists=/etc/os-release'
263 test.service: AssertPathExists=/etc/os-release succeeded.
264 Asserts succeeded.
265 test.service: ConditionArchitecture=|!arm succeeded.
266 test.service: ConditionACPower=|false failed.
267 test.service: ConditionKernelVersion=>=5.1 succeeded.
268 test.service: ConditionKernelVersion=!<4.0 succeeded.
269 Conditions succeeded.
270 systemd-analyze syscall-filter [SET...]
272 This command will list system calls contained in the specified system
273 call set SET, or all known sets if no sets are specified. Argument SET
274 must include the "@" prefix.
275 systemd-analyze calendar EXPRESSION...
277 This command will parse and normalize repetitive calendar time events,
278 and will calculate when they elapse next. This takes the same input as
279 the OnCalendar= setting in systemd.timer(5), following the syntax
280 described in systemd.time(7). By default, only the next time the
281 calendar expression will elapse is shown; use --iterations= to show the
282 specified number of next times the expression elapses. Each time the
283 expression elapses forms a timestamp, see the timestamp verb below.
284 Example 12. Show leap days in the near future
286 $ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'
288 Original form: *-2-29 0:0:0
289 Normalized form: *-02-29 00:00:00
290 Next elapse: Sat 2020-02-29 00:00:00 UTC
291 From now: 11 months 15 days left
292 Iter. #2: Thu 2024-02-29 00:00:00 UTC
293 From now: 4 years 11 months left
294 Iter. #3: Tue 2028-02-29 00:00:00 UTC
295 From now: 8 years 11 months left
296 Iter. #4: Sun 2032-02-29 00:00:00 UTC
297 From now: 12 years 11 months left
298 Iter. #5: Fri 2036-02-29 00:00:00 UTC
299 From now: 16 years 11 months left
300 systemd-analyze timestamp TIMESTAMP...
302 This command parses a timestamp (i.e. a single point in time) and
303 outputs the normalized form and the difference between this timestamp
304 and now. The timestamp should adhere to the syntax documented in
305 systemd.time(7), section "PARSING TIMESTAMPS".
306 Example 13. Show parsing of timestamps
308 $ systemd-analyze timestamp yesterday now tomorrow
310 Original form: yesterday
311 Normalized form: Mon 2019-05-20 00:00:00 CEST
312 (in UTC): Sun 2019-05-19 22:00:00 UTC
313 UNIX seconds: @15583032000
314 From now: 1 day 9h ago
315 Original form: now
317 Normalized form: Tue 2019-05-21 09:48:39 CEST
318 (in UTC): Tue 2019-05-21 07:48:39 UTC
319 UNIX seconds: @1558424919.659757
320 From now: 43us ago
321 Original form: tomorrow
323 Normalized form: Wed 2019-05-22 00:00:00 CEST
324 (in UTC): Tue 2019-05-21 22:00:00 UTC
325 UNIX seconds: @15584760000
326 From now: 14h left
327 systemd-analyze timespan EXPRESSION...
329 This command parses a time span (i.e. a difference between two
330 timestamps) and outputs the normalized form and the equivalent value in
331 microseconds. The time span should adhere to the syntax documented in
332 systemd.time(7), section "PARSING TIME SPANS". Values without units are
333 parsed as seconds.
334 Example 14. Show parsing of timespans
336 $ systemd-analyze timespan 1s 300s '1year 0.000001s'
338 Original: 1s
339 μs: 1000000
340 Human: 1s
341 Original: 300s
343 μs: 300000000
344 Human: 5min
345 Original: 1year 0.000001s
347 μs: 31557600000001
348 Human: 1y 1us
349 systemd-analyze cat-config NAME|PATH...
351 This command is similar to systemctl cat, but operates on config files.
352 It will copy the contents of a config file and any drop-ins to standard
353 output, using the usual systemd set of directories and rules for
354 precedence. Each argument must be either an absolute path including the
355 prefix (such as /etc/systemd/logind.conf or
356 /usr/lib/systemd/logind.conf), or a name relative to the prefix (such
357 as systemd/logind.conf).
358 Example 15. Showing logind configuration
360 $ systemd-analyze cat-config systemd/logind.conf
362 # /etc/systemd/logind.conf
363 ...
364 [Login]
365 NAutoVTs=8
366 ...
367 # /usr/lib/systemd/logind.conf.d/20-test.conf
369 ... some override from another package
370 # /etc/systemd/logind.conf.d/50-override.conf
372 ... some administrator override
373 systemd-analyze verify FILE...
376 This command will load unit files and print warnings if any errors are
377 detected. Files specified on the command line will be loaded, but also
378 any other units referenced by them. The full unit search path is formed
379 by combining the directories for all command line arguments, and the
380 usual unit load paths. The variable $SYSTEMD_UNIT_PATH is supported,
381 and may be used to replace or augment the compiled in set of unit load
382 paths; see systemd.unit(5). All units files present in the directories
383 containing the command line arguments will be used in preference to the
384 other paths.
385 The following errors are currently detected:
387 • unknown sections and directives,
389 • missing dependencies which are required to start the given unit,
391 • man pages listed in Documentation= which are not found in the
393 system,
394 • commands listed in ExecStart= and similar which are not found in
396 the system or not executable.
397 Example 16. Misspelt directives
399 $ cat ./user.slice
401 [Unit]
402 WhatIsThis=11
403 Documentation=man:nosuchfile(1)
404 Requires=different.service
405 [Service]
407 Description=x
408 $ systemd-analyze verify ./user.slice
410 [./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
411 [./user.slice:13] Unknown section 'Service'. Ignoring.
412 Error: org.freedesktop.systemd1.LoadFailed:
413 Unit different.service failed to load:
414 No such file or directory.
415 Failed to create user.slice/start: Invalid argument
416 user.slice: man nosuchfile(1) command failed with code 16
417 Example 17. Missing service units
420 $ tail ./a.socket ./b.socket
422 ==> ./a.socket <==
423 [Socket]
424 ListenStream=100
425 ==> ./b.socket <==
427 [Socket]
428 ListenStream=100
429 Accept=yes
430 $ systemd-analyze verify ./a.socket ./b.socket
432 Service a.service not loaded, a.socket cannot be started.
433 Service b@0.service not loaded, b.socket cannot be started.
434 systemd-analyze security [UNIT...]
437 This command analyzes the security and sandboxing settings of one or
438 more specified service units. If at least one unit name is specified
439 the security settings of the specified service units are inspected and
440 a detailed analysis is shown. If no unit name is specified, all
441 currently loaded, long-running service units are inspected and a terse
442 table with results shown. The command checks for various
443 security-related service settings, assigning each a numeric "exposure
444 level" value, depending on how important a setting is. It then
445 calculates an overall exposure level for the whole unit, which is an
446 estimation in the range 0.0...10.0 indicating how exposed a service is
447 security-wise. High exposure levels indicate very little applied
448 sandboxing. Low exposure levels indicate tight sandboxing and strongest
449 security restrictions. Note that this only analyzes the per-service
450 security features systemd itself implements. This means that any
451 additional security mechanisms applied by the service code itself are
452 not accounted for. The exposure level determined this way should not be
453 misunderstood: a high exposure level neither means that there is no
454 effective sandboxing applied by the service code itself, nor that the
455 service is actually vulnerable to remote or local attacks. High
456 exposure levels do indicate however that most likely the service might
457 benefit from additional settings applied to them.
458 Please note that many of the security and sandboxing settings
460 individually can be circumvented — unless combined with others. For
461 example, if a service retains the privilege to establish or undo mount
462 points many of the sandboxing options can be undone by the service code
463 itself. Due to that is essential that each service uses the most
464 comprehensive and strict sandboxing and security settings possible. The
465 tool will take into account some of these combinations and
466 relationships between the settings, but not all. Also note that the
467 security and sandboxing settings analyzed here only apply to the
468 operations executed by the service code itself. If a service has access
469 to an IPC system (such as D-Bus) it might request operations from other
470 services that are not subject to the same restrictions. Any
471 comprehensive security and sandboxing analysis is hence incomplete if
472 the IPC access policy is not validated too.
473 Example 18. Analyze systemd-logind.service
475 $ systemd-analyze security --no-pager systemd-logind.service
477 NAME DESCRIPTION EXPOSURE
478 ✗ PrivateNetwork= Service has access to the host's network 0.5
479 ✗ User=/DynamicUser= Service runs as root user 0.4
480 ✗ DeviceAllow= Service has no device ACL 0.2
481 ✓ IPAddressDeny= Service blocks all IP address ranges
482 ...
483 → Overall exposure level for systemd-logind.service: 4.1 OK 🙂
484
486 The following options are understood:
487 --system
489 Operates on the system systemd instance. This is the implied
490 default.
491 --user
493 Operates on the user systemd instance.
494 --global
496 Operates on the system-wide configuration for user systemd
497 instance.
498 --order, --require
500 When used in conjunction with the dot command (see above), selects
501 which dependencies are shown in the dependency graph. If --order is
502 passed, only dependencies of type After= or Before= are shown. If
503 --require is passed, only dependencies of type Requires=,
504 Requisite=, Wants= and Conflicts= are shown. If neither is passed,
505 this shows dependencies of all these types.
506 --from-pattern=, --to-pattern=
508 When used in conjunction with the dot command (see above), this
509 selects which relationships are shown in the dependency graph. Both
510 options require a glob(7) pattern as an argument, which will be
511 matched against the left-hand and the right-hand, respectively,
512 nodes of a relationship.
513 Each of these can be used more than once, in which case the unit
515 name must match one of the values. When tests for both sides of the
516 relation are present, a relation must pass both tests to be shown.
517 When patterns are also specified as positional arguments, they must
518 match at least one side of the relation. In other words, patterns
519 specified with those two options will trim the list of edges
520 matched by the positional arguments, if any are given, and fully
521 determine the list of edges shown otherwise.
522 --fuzz=timespan
524 When used in conjunction with the critical-chain command (see
525 above), also show units, which finished timespan earlier, than the
526 latest unit in the same level. The unit of timespan is seconds
527 unless specified with a different unit, e.g. "50ms".
528 --man=no
530 Do not invoke man(1) to verify the existence of man pages listed in
531 Documentation=.
532 --generators
534 Invoke unit generators, see systemd.generator(7). Some generators
535 require root privileges. Under a normal user, running with
536 generators enabled will generally result in some warnings.
537 --root=PATH
539 With cat-files, show config files underneath the specified root
540 path PATH.
541 --iterations=NUMBER
543 When used with the calendar command, show the specified number of
544 iterations the specified calendar expression will elapse next.
545 Defaults to 1.
546 --base-time=TIMESTAMP
548 When used with the calendar command, show next iterations relative
549 to the specified point in time. If not specified defaults to the
550 current time.
551 -H, --host=
553 Execute the operation remotely. Specify a hostname, or a username
554 and hostname separated by "@", to connect to. The hostname may
555 optionally be suffixed by a port ssh is listening on, separated by
556 ":", and then a container name, separated by "/", which connects
557 directly to a specific container on the specified host. This will
558 use SSH to talk to the remote machine manager instance. Container
559 names may be enumerated with machinectl -H HOST. Put IPv6 addresses
560 in brackets.
561 -M, --machine=
563 Execute operation on a local container. Specify a container name to
564 connect to, optionally prefixed by a user name to connect as and a
565 separating "@" character. If the special string ".host" is used in
566 place of the container name, a connection to the local system is
567 made (which is useful to connect to a specific user's user bus:
568 "--user --machine=lennart@.host"). If the "@" syntax is not used,
569 the connection is made as root user. If the "@" syntax is used
570 either the left hand side or the right hand side may be omitted
571 (but not both) in which case the local user name and ".host" are
572 implied.
573 -h, --help
575 Print a short help text and exit.
576 --version
578 Print a short version string and exit.
579 --no-pager
581 Do not pipe output into a pager.
582
584 On success, 0 is returned, a non-zero failure code otherwise.
585
587 $SYSTEMD_LOG_LEVEL
588 The maximum log level of emitted messages (messages with a higher
589 log level, i.e. less important ones, will be suppressed). Either
590 one of (in order of decreasing importance) emerg, alert, crit, err,
591 warning, notice, info, debug, or an integer in the range 0...7. See
592 syslog(3) for more information.
593 $SYSTEMD_LOG_COLOR
595 A boolean. If true, messages written to the tty will be colored
596 according to priority.
597 This setting is only useful when messages are written directly to
599 the terminal, because journalctl(1) and other tools that display
600 logs will color messages based on the log level on their own.
601 $SYSTEMD_LOG_TIME
603 A boolean. If true, console log messages will be prefixed with a
604 timestamp.
605 This setting is only useful when messages are written directly to
607 the terminal or a file, because journalctl(1) and other tools that
608 display logs will attach timestamps based on the entry metadata on
609 their own.
610 $SYSTEMD_LOG_LOCATION
612 A boolean. If true, messages will be prefixed with a filename and
613 line number in the source code where the message originates.
614 Note that the log location is often attached as metadata to journal
616 entries anyway. Including it directly in the message text can
617 nevertheless be convenient when debugging programs.
618 $SYSTEMD_LOG_TID
620 A boolean. If true, messages will be prefixed with the current
621 numerical thread ID (TID).
622 Note that the this information is attached as metadata to journal
624 entries anyway. Including it directly in the message text can
625 nevertheless be convenient when debugging programs.
626 $SYSTEMD_LOG_TARGET
628 The destination for log messages. One of console (log to the
629 attached tty), console-prefixed (log to the attached tty but with
630 prefixes encoding the log level and "facility", see syslog(3), kmsg
631 (log to the kernel circular log buffer), journal (log to the
632 journal), journal-or-kmsg (log to the journal if available, and to
633 kmsg otherwise), auto (determine the appropriate log target
634 automatically, the default), null (disable log output).
635 $SYSTEMD_PAGER
637 Pager to use when --no-pager is not given; overrides $PAGER. If
638 neither $SYSTEMD_PAGER nor $PAGER are set, a set of well-known
639 pager implementations are tried in turn, including less(1) and
640 more(1), until one is found. If no pager implementation is
641 discovered no pager is invoked. Setting this environment variable
642 to an empty string or the value "cat" is equivalent to passing
643 --no-pager.
644 $SYSTEMD_LESS
646 Override the options passed to less (by default "FRSXMK").
647 Users might want to change two options in particular:
649 K
651 This option instructs the pager to exit immediately when Ctrl+C
652 is pressed. To allow less to handle Ctrl+C itself to switch
653 back to the pager command prompt, unset this option.
654 If the value of $SYSTEMD_LESS does not include "K", and the
656 pager that is invoked is less, Ctrl+C will be ignored by the
657 executable, and needs to be handled by the pager.
658 X
660 This option instructs the pager to not send termcap
661 initialization and deinitialization strings to the terminal. It
662 is set by default to allow command output to remain visible in
663 the terminal even after the pager exits. Nevertheless, this
664 prevents some pager functionality from working, in particular
665 paged output cannot be scrolled with the mouse.
666 See less(1) for more discussion.
668 $SYSTEMD_LESSCHARSET
670 Override the charset passed to less (by default "utf-8", if the
671 invoking terminal is determined to be UTF-8 compatible).
672 $SYSTEMD_PAGERSECURE
674 Takes a boolean argument. When true, the "secure" mode of the pager
675 is enabled; if false, disabled. If $SYSTEMD_PAGERSECURE is not set
676 at all, secure mode is enabled if the effective UID is not the same
677 as the owner of the login session, see geteuid(2) and
678 sd_pid_get_owner_uid(3). In secure mode, LESSSECURE=1 will be set
679 when invoking the pager, and the pager shall disable commands that
680 open or create new files or start new subprocesses. When
681 $SYSTEMD_PAGERSECURE is not set at all, pagers which are not known
682 to implement secure mode will not be used. (Currently only less(1)
683 implements secure mode.)
684 Note: when commands are invoked with elevated privileges, for
686 example under sudo(8) or pkexec(1), care must be taken to ensure
687 that unintended interactive features are not enabled. "Secure" mode
688 for the pager may be enabled automatically as describe above.
689 Setting SYSTEMD_PAGERSECURE=0 or not removing it from the inherited
690 environment allows the user to invoke arbitrary commands. Note that
691 if the $SYSTEMD_PAGER or $PAGER variables are to be honoured,
692 $SYSTEMD_PAGERSECURE must be set too. It might be reasonable to
693 completely disable the pager using --no-pager instead.
694 $SYSTEMD_COLORS
696 Takes a boolean argument. When true, systemd and related utilities
697 will use colors in their output, otherwise the output will be
698 monochrome. Additionally, the variable can take one of the
699 following special values: "16", "256" to restrict the use of colors
700 to the base 16 or 256 ANSI colors, respectively. This can be
701 specified to override the automatic decision based on $TERM and
702 what the console is connected to.
703 $SYSTEMD_URLIFY
705 The value must be a boolean. Controls whether clickable links
706 should be generated in the output for terminal emulators supporting
707 this. This can be specified to override the decision that systemd
708 makes based on $TERM and other conditions.
709
711 systemd(1), systemctl(1)
712systemd 249 SYSTEMD-ANALYZE(1)