{ "content": [ { "type": "text", "text": "# SYSTEMD-ANALYZE (info)\n\n## NAME\n\nsystemd-analyze - Analyze and debug system manager\n\n## SYNOPSIS\n\nsystemd-analyze [OPTIONS...] [time]\nsystemd-analyze [OPTIONS...] blame\nsystemd-analyze [OPTIONS...] critical-chain [UNIT...]\nsystemd-analyze [OPTIONS...] dump\nsystemd-analyze [OPTIONS...] plot [>file.svg]\nsystemd-analyze [OPTIONS...] dot [PATTERN...] [>file.dot]\nsystemd-analyze [OPTIONS...] unit-paths\nsystemd-analyze [OPTIONS...] exit-status [STATUS...]\nsystemd-analyze [OPTIONS...] capability [CAPABILITY...]\nsystemd-analyze [OPTIONS...] condition CONDITION...\nsystemd-analyze [OPTIONS...] syscall-filter [SET...]\nsystemd-analyze [OPTIONS...] calendar SPEC...\nsystemd-analyze [OPTIONS...] timestamp TIMESTAMP...\nsystemd-analyze [OPTIONS...] timespan SPAN...\nsystemd-analyze [OPTIONS...] cat-config NAME|PATH...\nsystemd-analyze [OPTIONS...] verify [FILE...]\nsystemd-analyze [OPTIONS...] security UNIT...\n\n## DESCRIPTION\n\nsystemd-analyze may be used to determine system boot-up performance\nstatistics and retrieve other state and tracing information from the\nsystem and service manager, and to verify the correctness of unit\nfiles. It is also used to access special functions useful for advanced\nsystem manager debugging.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **OPTIONS** (8 subsections)\n- **EXIT STATUS**\n- **ENVIRONMENT**\n- **SEE ALSO**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "SYSTEMD-ANALYZE", "section": "", "mode": "info", "summary": "systemd-analyze - Analyze and debug system manager", "synopsis": "systemd-analyze [OPTIONS...] [time]\nsystemd-analyze [OPTIONS...] blame\nsystemd-analyze [OPTIONS...] critical-chain [UNIT...]\nsystemd-analyze [OPTIONS...] dump\nsystemd-analyze [OPTIONS...] plot [>file.svg]\nsystemd-analyze [OPTIONS...] dot [PATTERN...] [>file.dot]\nsystemd-analyze [OPTIONS...] unit-paths\nsystemd-analyze [OPTIONS...] exit-status [STATUS...]\nsystemd-analyze [OPTIONS...] capability [CAPABILITY...]\nsystemd-analyze [OPTIONS...] condition CONDITION...\nsystemd-analyze [OPTIONS...] syscall-filter [SET...]\nsystemd-analyze [OPTIONS...] calendar SPEC...\nsystemd-analyze [OPTIONS...] timestamp TIMESTAMP...\nsystemd-analyze [OPTIONS...] timespan SPAN...\nsystemd-analyze [OPTIONS...] cat-config NAME|PATH...\nsystemd-analyze [OPTIONS...] verify [FILE...]\nsystemd-analyze [OPTIONS...] security UNIT...", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [ { "flag": "", "long": "--system", "arg": null, "description": "Operates on the system systemd instance. This is the implied default." }, { "flag": "", "long": "--user", "arg": null, "description": "Operates on the user systemd instance." }, { "flag": "", "long": "--global", "arg": null, "description": "Operates on the system-wide configuration for user systemd instance." }, { "flag": "", "long": "--require", "arg": null, "description": "When used in conjunction with the dot command (see above), selects which dependencies are shown in the dependency graph. If --order is passed, only dependencies of type After= or Before= are shown. If --require is passed, only dependencies of type Requires=, Requisite=, Wants= and Conflicts= are shown. If neither is passed, this shows dependencies of all these types. --from-pattern=, --to-pattern= When used in conjunction with the dot command (see above), this selects which relationships are shown in the dependency graph. Both options require a glob(7) pattern as an argument, which will be matched against the left-hand and the right-hand, respectively, nodes of a relationship. 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. --fuzz=timespan When used in conjunction with the critical-chain command (see above), also show units, which finished timespan earlier, than the latest unit in the same level. The unit of timespan is seconds unless specified with a different unit, e.g. \"50ms\". --man=no Do not invoke man(1) to verify the existence of man pages listed in Documentation=." }, { "flag": "", "long": "--generators", "arg": null, "description": "Invoke unit generators, see systemd.generator(7). Some generators require root privileges. Under a normal user, running with generators enabled will generally result in some warnings. --root=PATH With cat-files, show config files underneath the specified root path PATH. --iterations=NUMBER When used with the calendar command, show the specified number of iterations the specified calendar expression will elapse next. Defaults to 1. --base-time=TIMESTAMP When used with the calendar command, show next iterations relative to the specified point in time. If not specified defaults to the current time. -H, --host= Execute the operation remotely. Specify a hostname, or a username and hostname separated by \"@\", to connect to. The hostname may optionally be suffixed by a port ssh is listening on, separated by \":\", and then a container name, separated by \"/\", which connects directly to a specific container on the specified host. This will use SSH to talk to the remote machine manager instance. Container names may be enumerated with machinectl -H HOST. Put IPv6 addresses in brackets. -M, --machine= Execute operation on a local container. Specify a container name to connect to, optionally prefixed by a user name to connect as and a separating \"@\" character. If the special string \".host\" is used in place of the container name, a connection to the local system is made (which is useful to connect to a specific user's user bus: \"--user --machine=lennart@.host\"). If the \"@\" syntax is not used, the connection is made as root user. If the \"@\" syntax is used either the left hand side or the right hand side may be omitted (but not both) in which case the local user name and \".host\" are implied." }, { "flag": "-h", "long": "--help", "arg": null, "description": "Print a short help text and exit." }, { "flag": "", "long": "--version", "arg": null, "description": "Print a short version string and exit." }, { "flag": "", "long": "--no-pager", "arg": null, "description": "Do not pipe output into a pager." } ], "examples": [], "see_also": [ { "name": "systemd", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/systemd/1/json" }, { "name": "systemctl", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/systemctl/1/json" } ], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 34, "subsections": [] }, { "name": "DESCRIPTION", "lines": 437, "subsections": [] }, { "name": "OPTIONS", "lines": 2, "subsections": [ { "name": "--system", "lines": 3, "long": "--system" }, { "name": "--user", "lines": 2, "long": "--user" }, { "name": "--global", "lines": 3, "long": "--global" }, { "name": "--order, --require", "lines": 33, "long": "--require" }, { "name": "--generators", "lines": 40, "long": "--generators" }, { "name": "-h, --help", "lines": 2, "flag": "-h", "long": "--help" }, { "name": "--version", "lines": 2, "long": "--version" }, { "name": "--no-pager", "lines": 2, "long": "--no-pager" } ] }, { "name": "EXIT STATUS", "lines": 2, "subsections": [] }, { "name": "ENVIRONMENT", "lines": 123, "subsections": [] }, { "name": "SEE ALSO", "lines": 3, "subsections": [] } ], "sections": { "NAME": { "content": "systemd-analyze - Analyze and debug system manager\n", "subsections": [] }, "SYNOPSIS": { "content": "systemd-analyze [OPTIONS...] [time]\n\nsystemd-analyze [OPTIONS...] blame\n\nsystemd-analyze [OPTIONS...] critical-chain [UNIT...]\n\nsystemd-analyze [OPTIONS...] dump\n\nsystemd-analyze [OPTIONS...] plot [>file.svg]\n\nsystemd-analyze [OPTIONS...] dot [PATTERN...] [>file.dot]\n\nsystemd-analyze [OPTIONS...] unit-paths\n\nsystemd-analyze [OPTIONS...] exit-status [STATUS...]\n\nsystemd-analyze [OPTIONS...] capability [CAPABILITY...]\n\nsystemd-analyze [OPTIONS...] condition CONDITION...\n\nsystemd-analyze [OPTIONS...] syscall-filter [SET...]\n\nsystemd-analyze [OPTIONS...] calendar SPEC...\n\nsystemd-analyze [OPTIONS...] timestamp TIMESTAMP...\n\nsystemd-analyze [OPTIONS...] timespan SPAN...\n\nsystemd-analyze [OPTIONS...] cat-config NAME|PATH...\n\nsystemd-analyze [OPTIONS...] verify [FILE...]\n\nsystemd-analyze [OPTIONS...] security UNIT...\n", "subsections": [] }, "DESCRIPTION": { "content": "systemd-analyze may be used to determine system boot-up performance\nstatistics and retrieve other state and tracing information from the\nsystem and service manager, and to verify the correctness of unit\nfiles. It is also used to access special functions useful for advanced\nsystem manager debugging.\n\nIf no command is passed, systemd-analyze time is implied.\n\nsystemd-analyze time\nThis command prints the time spent in the kernel before userspace has\nbeen reached, the time spent in the initial RAM disk (initrd) before\nnormal system userspace has been reached, and the time normal system\nuserspace took to initialize. Note that these measurements simply\nmeasure the time passed up to the point where all system services have\nbeen spawned, but not necessarily until they fully finished\ninitialization or the disk is idle.\n\nExample 1. Show how long the boot took\n\n# in a container\n$ systemd-analyze time\nStartup finished in 296ms (userspace)\nmulti-user.target reached after 275ms in userspace\n\n# on a real machine\n$ systemd-analyze time\nStartup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s\nmulti-user.target reached after 47.820s in userspace\n\nsystemd-analyze blame\nThis command prints a list of all running units, ordered by the time\nthey took to initialize. This information may be used to optimize\nboot-up times. Note that the output might be misleading as the\ninitialization of one service might be slow simply because it waits for\nthe initialization of another service to complete. Also note:\nsystemd-analyze blame doesn't display results for services with\nType=simple, because systemd considers such services to be started\nimmediately, hence no measurement of the initialization delays can be\ndone. Also note that this command only shows the time units took for\nstarting up, it does not show how long unit jobs spent in the execution\nqueue. In particular it shows the time units spent in \"activating\"\nstate, which is not defined for units such as device units that\ntransition directly from \"inactive\" to \"active\". This command hence\ngives an impression of the performance of program code, but cannot\naccurately reflect latency introduced by waiting for hardware and\nsimilar events.\n\nExample 2. Show which units took the most time during boot\n\n$ systemd-analyze blame\n32.875s pmlogger.service\n20.905s systemd-networkd-wait-online.service\n13.299s dev-vda1.device\n...\n23ms sysroot.mount\n11ms initrd-udevadm-cleanup-db.service\n3ms sys-kernel-config.mount\n\nsystemd-analyze critical-chain [UNIT...]\nThis command prints a tree of the time-critical chain of units (for\neach of the specified UNITs or for the default target otherwise). The\ntime after the unit is active or started is printed after the \"@\"\ncharacter. The time the unit takes to start is printed after the \"+\"\ncharacter. Note that the output might be misleading as the\ninitialization of services might depend on socket activation and\nbecause of the parallel execution of units. Also, similar to the blame\ncommand, this only takes into account the time units spent in\n\"activating\" state, and hence does not cover units that never went\nthrough an \"activating\" state (such as device units that transition\ndirectly from \"inactive\" to \"active\"). Moreover it does not show\ninformation on jobs (and in particular not jobs that timed out).\n\nExample 3. systemd-analyze critical-chain\n\n$ systemd-analyze critical-chain\nmulti-user.target @47.820s\npmie.service @35.968s +548ms\npmcd.service @33.715s +2.247s\nnetwork-online.target @33.712s\nsystemd-networkd-wait-online.service @12.804s +20.905s\nsystemd-networkd.service @11.109s +1.690s\nsystemd-udevd.service @9.201s +1.904s\nsystemd-tmpfiles-setup-dev.service @7.306s +1.776s\nkmod-static-nodes.service @6.976s +177ms\nsystemd-journald.socket\nsystem.slice\n-.slice\n\nsystemd-analyze dump\nThis command outputs a (usually very long) human-readable serialization\nof the complete server state. Its format is subject to change without\nnotice and should not be parsed by applications.\n\nExample 4. Show the internal state of user manager\n\n$ systemd-analyze --user dump\nTimestamp userspace: Thu 2019-03-14 23:28:07 CET\nTimestamp finish: Thu 2019-03-14 23:28:07 CET\nTimestamp generators-start: Thu 2019-03-14 23:28:07 CET\nTimestamp generators-finish: Thu 2019-03-14 23:28:07 CET\nTimestamp units-load-start: Thu 2019-03-14 23:28:07 CET\nTimestamp units-load-finish: Thu 2019-03-14 23:28:07 CET\n-> Unit proc-timerlist.mount:\nDescription: /proc/timerlist\n...\n-> Unit default.target:\nDescription: Main user target\n...\n\nsystemd-analyze plot\nThis command prints an SVG graphic detailing which system services have\nbeen started at what time, highlighting the time they spent on\ninitialization.\n\nExample 5. Plot a bootchart\n\n$ systemd-analyze plot >bootup.svg\n$ eog bootup.svg&\n\nsystemd-analyze dot [pattern...]\nThis command generates textual dependency graph description in dot\nformat for further processing with the GraphViz dot(1) tool. Use a\ncommand line like systemd-analyze dot | dot -Tsvg >systemd.svg to\ngenerate a graphical dependency tree. Unless --order or --require is\npassed, the generated graph will show both ordering and requirement\ndependencies. Optional pattern globbing style specifications (e.g.\n*.target) may be given at the end. A unit dependency is included in the\ngraph if any of these patterns match either the origin or destination\nnode.\n\nExample 6. Plot all dependencies of any unit whose name starts with\n\"avahi-daemon\"\n\n$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg\n$ eog avahi.svg\n\nExample 7. Plot the dependencies between all known target units\n\n$ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' \\\n| dot -Tsvg >targets.svg\n$ eog targets.svg\n\nsystemd-analyze unit-paths\nThis command outputs a list of all directories from which unit files,\n.d overrides, and .wants, .requires symlinks may be loaded. Combine\nwith --user to retrieve the list for the user manager instance, and\n--global for the global configuration of user manager instances.\n\nExample 8. Show all paths for generated units\n\n$ systemd-analyze unit-paths | grep '^/run'\n/run/systemd/system.control\n/run/systemd/transient\n/run/systemd/generator.early\n/run/systemd/system\n/run/systemd/system.attached\n/run/systemd/generator\n/run/systemd/generator.late\n\nNote that this verb prints the list that is compiled into\nsystemd-analyze itself, and does not communicate with the running\nmanager. Use\n\nsystemctl [--user] [--global] show -p UnitPath --value\n\nto retrieve the actual list that the manager uses, with any empty\ndirectories omitted.\n\nsystemd-analyze exit-status [STATUS...]\nThis command prints a list of exit statuses along with their \"class\",\ni.e. the source of the definition (one of \"glibc\", \"systemd\", \"LSB\", or\n\"BSD\"), see the Process Exit Codes section in systemd.exec(5). If no\nadditional arguments are specified, all known statuses are shown.\nOtherwise, only the definitions for the specified codes are shown.\n\nExample 9. Show some example exit status names\n\n$ systemd-analyze exit-status 0 1 {63..65}\nNAME STATUS CLASS\nSUCCESS 0 glibc\nFAILURE 1 glibc\n- 63 -\nUSAGE 64 BSD\nDATAERR 65 BSD\n\nsystemd-analyze capability [CAPABILITY...]\nThis command prints a list of Linux capabilities along with their\nnumeric IDs. See capabilities(7) for details. If no argument is\nspecified the full list of capabilities known to the service manager\nand the kernel is shown. Capabilities defined by the kernel but not\nknown to the service manager are shown as \"cap???\". Optionally, if\narguments are specified they may refer to specific cabilities by name\nor numeric ID, in which case only the indicated capabilities are shown\nin the table.\n\nExample 10. Show some example capability names\n\n$ systemd-analyze capability 0 1 {30..32}\nNAME NUMBER\ncapchown 0\ncapdacoverride 1\ncapauditcontrol 30\ncapsetfcap 31\ncapmacoverride 32\n\nsystemd-analyze condition CONDITION...\nThis command will evaluate Condition*=... and Assert*=...\nassignments, and print their values, and the resulting value of the\ncombined condition set. See systemd.unit(5) for a list of available\nconditions and asserts.\n\nExample 11. Evaluate conditions that check kernel versions\n\n$ systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \\\n'ConditionKernelVersion = >=5.1' \\\n'ConditionACPower=|false' \\\n'ConditionArchitecture=|!arm' \\\n'AssertPathExists=/etc/os-release'\ntest.service: AssertPathExists=/etc/os-release succeeded.\nAsserts succeeded.\ntest.service: ConditionArchitecture=|!arm succeeded.\ntest.service: ConditionACPower=|false failed.\ntest.service: ConditionKernelVersion=>=5.1 succeeded.\ntest.service: ConditionKernelVersion=!<4.0 succeeded.\nConditions succeeded.\n\nsystemd-analyze syscall-filter [SET...]\nThis command will list system calls contained in the specified system\ncall set SET, or all known sets if no sets are specified. Argument SET\nmust include the \"@\" prefix.\n\nsystemd-analyze calendar EXPRESSION...\nThis command will parse and normalize repetitive calendar time events,\nand will calculate when they elapse next. This takes the same input as\nthe OnCalendar= setting in systemd.timer(5), following the syntax\ndescribed in systemd.time(7). By default, only the next time the\ncalendar expression will elapse is shown; use --iterations= to show the\nspecified number of next times the expression elapses. Each time the\nexpression elapses forms a timestamp, see the timestamp verb below.\n\nExample 12. Show leap days in the near future\n\n$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'\nOriginal form: *-2-29 0:0:0\nNormalized form: *-02-29 00:00:00\nNext elapse: Sat 2020-02-29 00:00:00 UTC\nFrom now: 11 months 15 days left\nIter. #2: Thu 2024-02-29 00:00:00 UTC\nFrom now: 4 years 11 months left\nIter. #3: Tue 2028-02-29 00:00:00 UTC\nFrom now: 8 years 11 months left\nIter. #4: Sun 2032-02-29 00:00:00 UTC\nFrom now: 12 years 11 months left\nIter. #5: Fri 2036-02-29 00:00:00 UTC\nFrom now: 16 years 11 months left\n\nsystemd-analyze timestamp TIMESTAMP...\nThis command parses a timestamp (i.e. a single point in time) and\noutputs the normalized form and the difference between this timestamp\nand now. The timestamp should adhere to the syntax documented in\nsystemd.time(7), section \"PARSING TIMESTAMPS\".\n\nExample 13. Show parsing of timestamps\n\n$ systemd-analyze timestamp yesterday now tomorrow\nOriginal form: yesterday\nNormalized form: Mon 2019-05-20 00:00:00 CEST\n(in UTC): Sun 2019-05-19 22:00:00 UTC\nUNIX seconds: @15583032000\nFrom now: 1 day 9h ago\n\nOriginal form: now\nNormalized form: Tue 2019-05-21 09:48:39 CEST\n(in UTC): Tue 2019-05-21 07:48:39 UTC\nUNIX seconds: @1558424919.659757\nFrom now: 43us ago\n\nOriginal form: tomorrow\nNormalized form: Wed 2019-05-22 00:00:00 CEST\n(in UTC): Tue 2019-05-21 22:00:00 UTC\nUNIX seconds: @15584760000\nFrom now: 14h left\n\nsystemd-analyze timespan EXPRESSION...\nThis command parses a time span (i.e. a difference between two\ntimestamps) and outputs the normalized form and the equivalent value in\nmicroseconds. The time span should adhere to the syntax documented in\nsystemd.time(7), section \"PARSING TIME SPANS\". Values without units are\nparsed as seconds.\n\nExample 14. Show parsing of timespans\n\n$ systemd-analyze timespan 1s 300s '1year 0.000001s'\nOriginal: 1s\ns: 1000000\nHuman: 1s\n\nOriginal: 300s\ns: 300000000\nHuman: 5min\n\nOriginal: 1year 0.000001s\ns: 31557600000001\nHuman: 1y 1us\n\nsystemd-analyze cat-config NAME|PATH...\nThis command is similar to systemctl cat, but operates on config files.\nIt will copy the contents of a config file and any drop-ins to standard\noutput, using the usual systemd set of directories and rules for\nprecedence. Each argument must be either an absolute path including the\nprefix (such as /etc/systemd/logind.conf or\n/usr/lib/systemd/logind.conf), or a name relative to the prefix (such\nas systemd/logind.conf).\n\nExample 15. Showing logind configuration\n\n$ systemd-analyze cat-config systemd/logind.conf\n# /etc/systemd/logind.conf\n...\n[Login]\nNAutoVTs=8\n...\n\n# /usr/lib/systemd/logind.conf.d/20-test.conf\n... some override from another package\n\n# /etc/systemd/logind.conf.d/50-override.conf\n... some administrator override\n\nsystemd-analyze verify FILE...\nThis command will load unit files and print warnings if any errors are\ndetected. Files specified on the command line will be loaded, but also\nany other units referenced by them. The full unit search path is formed\nby combining the directories for all command line arguments, and the\nusual unit load paths. The variable $SYSTEMDUNITPATH is supported,\nand may be used to replace or augment the compiled in set of unit load\npaths; see systemd.unit(5). All units files present in the directories\ncontaining the command line arguments will be used in preference to the\nother paths.\n\nThe following errors are currently detected:\n\no unknown sections and directives,\n\no missing dependencies which are required to start the given unit,\n\no man pages listed in Documentation= which are not found in the\nsystem,\n\no commands listed in ExecStart= and similar which are not found in\nthe system or not executable.\n\nExample 16. Misspelt directives\n\n$ cat ./user.slice\n[Unit]\nWhatIsThis=11\nDocumentation=man:nosuchfile(1)\nRequires=different.service\n\n[Service]\nDescription=x\n\n$ systemd-analyze verify ./user.slice\n[./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'\n[./user.slice:13] Unknown section 'Service'. Ignoring.\nError: org.freedesktop.systemd1.LoadFailed:\nUnit different.service failed to load:\nNo such file or directory.\nFailed to create user.slice/start: Invalid argument\nuser.slice: man nosuchfile(1) command failed with code 16\n\nExample 17. Missing service units\n\n$ tail ./a.socket ./b.socket\n==> ./a.socket <==\n[Socket]\nListenStream=100\n\n==> ./b.socket <==\n[Socket]\nListenStream=100\nAccept=yes\n\n$ systemd-analyze verify ./a.socket ./b.socket\nService a.service not loaded, a.socket cannot be started.\nService b@0.service not loaded, b.socket cannot be started.\n\nsystemd-analyze security [UNIT...]\nThis command analyzes the security and sandboxing settings of one or\nmore specified service units. If at least one unit name is specified\nthe security settings of the specified service units are inspected and\na detailed analysis is shown. If no unit name is specified, all\ncurrently loaded, long-running service units are inspected and a terse\ntable with results shown. The command checks for various\nsecurity-related service settings, assigning each a numeric \"exposure\nlevel\" value, depending on how important a setting is. It then\ncalculates an overall exposure level for the whole unit, which is an\nestimation in the range 0.0...10.0 indicating how exposed a service is\nsecurity-wise. High exposure levels indicate very little applied\nsandboxing. Low exposure levels indicate tight sandboxing and strongest\nsecurity restrictions. Note that this only analyzes the per-service\nsecurity features systemd itself implements. This means that any\nadditional security mechanisms applied by the service code itself are\nnot accounted for. The exposure level determined this way should not be\nmisunderstood: a high exposure level neither means that there is no\neffective sandboxing applied by the service code itself, nor that the\nservice is actually vulnerable to remote or local attacks. High\nexposure levels do indicate however that most likely the service might\nbenefit from additional settings applied to them.\n\nPlease note that many of the security and sandboxing settings\nindividually can be circumvented -- unless combined with others. For\nexample, if a service retains the privilege to establish or undo mount\npoints many of the sandboxing options can be undone by the service code\nitself. Due to that is essential that each service uses the most\ncomprehensive and strict sandboxing and security settings possible. The\ntool will take into account some of these combinations and\nrelationships between the settings, but not all. Also note that the\nsecurity and sandboxing settings analyzed here only apply to the\noperations executed by the service code itself. If a service has access\nto an IPC system (such as D-Bus) it might request operations from other\nservices that are not subject to the same restrictions. Any\ncomprehensive security and sandboxing analysis is hence incomplete if\nthe IPC access policy is not validated too.\n\nExample 18. Analyze systemd-logind.service\n\n$ systemd-analyze security --no-pager systemd-logind.service\nNAME DESCRIPTION EXPOSURE\nPrivateNetwork= Service has access to the host's network 0.5\nUser=/DynamicUser= Service runs as root user 0.4\nDeviceAllow= Service has no device ACL 0.2\nIPAddressDeny= Service blocks all IP address ranges\n...\n-> Overall exposure level for systemd-logind.service: 4.1 OK\n", "subsections": [] }, "OPTIONS": { "content": "The following options are understood:\n", "subsections": [ { "name": "--system", "content": "Operates on the system systemd instance. This is the implied\ndefault.\n", "long": "--system" }, { "name": "--user", "content": "Operates on the user systemd instance.\n", "long": "--user" }, { "name": "--global", "content": "Operates on the system-wide configuration for user systemd\ninstance.\n", "long": "--global" }, { "name": "--order, --require", "content": "When used in conjunction with the dot command (see above), selects\nwhich dependencies are shown in the dependency graph. If --order is\npassed, only dependencies of type After= or Before= are shown. If\n--require is passed, only dependencies of type Requires=,\nRequisite=, Wants= and Conflicts= are shown. If neither is passed,\nthis shows dependencies of all these types.\n\n--from-pattern=, --to-pattern=\nWhen used in conjunction with the dot command (see above), this\nselects which relationships are shown in the dependency graph. Both\noptions require a glob(7) pattern as an argument, which will be\nmatched against the left-hand and the right-hand, respectively,\nnodes of a relationship.\n\nEach of these can be used more than once, in which case the unit\nname must match one of the values. When tests for both sides of the\nrelation are present, a relation must pass both tests to be shown.\nWhen patterns are also specified as positional arguments, they must\nmatch at least one side of the relation. In other words, patterns\nspecified with those two options will trim the list of edges\nmatched by the positional arguments, if any are given, and fully\ndetermine the list of edges shown otherwise.\n\n--fuzz=timespan\nWhen used in conjunction with the critical-chain command (see\nabove), also show units, which finished timespan earlier, than the\nlatest unit in the same level. The unit of timespan is seconds\nunless specified with a different unit, e.g. \"50ms\".\n\n--man=no\nDo not invoke man(1) to verify the existence of man pages listed in\nDocumentation=.\n", "long": "--require" }, { "name": "--generators", "content": "Invoke unit generators, see systemd.generator(7). Some generators\nrequire root privileges. Under a normal user, running with\ngenerators enabled will generally result in some warnings.\n\n--root=PATH\nWith cat-files, show config files underneath the specified root\npath PATH.\n\n--iterations=NUMBER\nWhen used with the calendar command, show the specified number of\niterations the specified calendar expression will elapse next.\nDefaults to 1.\n\n--base-time=TIMESTAMP\nWhen used with the calendar command, show next iterations relative\nto the specified point in time. If not specified defaults to the\ncurrent time.\n\n-H, --host=\nExecute the operation remotely. Specify a hostname, or a username\nand hostname separated by \"@\", to connect to. The hostname may\noptionally be suffixed by a port ssh is listening on, separated by\n\":\", and then a container name, separated by \"/\", which connects\ndirectly to a specific container on the specified host. This will\nuse SSH to talk to the remote machine manager instance. Container\nnames may be enumerated with machinectl -H HOST. Put IPv6 addresses\nin brackets.\n\n-M, --machine=\nExecute operation on a local container. Specify a container name to\nconnect to, optionally prefixed by a user name to connect as and a\nseparating \"@\" character. If the special string \".host\" is used in\nplace of the container name, a connection to the local system is\nmade (which is useful to connect to a specific user's user bus:\n\"--user --machine=lennart@.host\"). If the \"@\" syntax is not used,\nthe connection is made as root user. If the \"@\" syntax is used\neither the left hand side or the right hand side may be omitted\n(but not both) in which case the local user name and \".host\" are\nimplied.\n", "long": "--generators" }, { "name": "-h, --help", "content": "Print a short help text and exit.\n", "flag": "-h", "long": "--help" }, { "name": "--version", "content": "Print a short version string and exit.\n", "long": "--version" }, { "name": "--no-pager", "content": "Do not pipe output into a pager.\n", "long": "--no-pager" } ] }, "EXIT STATUS": { "content": "On success, 0 is returned, a non-zero failure code otherwise.\n", "subsections": [] }, "ENVIRONMENT": { "content": "$SYSTEMDLOGLEVEL\nThe maximum log level of emitted messages (messages with a higher\nlog level, i.e. less important ones, will be suppressed). Either\none of (in order of decreasing importance) emerg, alert, crit, err,\nwarning, notice, info, debug, or an integer in the range 0...7. See\nsyslog(3) for more information.\n\n$SYSTEMDLOGCOLOR\nA boolean. If true, messages written to the tty will be colored\naccording to priority.\n\nThis setting is only useful when messages are written directly to\nthe terminal, because journalctl(1) and other tools that display\nlogs will color messages based on the log level on their own.\n\n$SYSTEMDLOGTIME\nA boolean. If true, console log messages will be prefixed with a\ntimestamp.\n\nThis setting is only useful when messages are written directly to\nthe terminal or a file, because journalctl(1) and other tools that\ndisplay logs will attach timestamps based on the entry metadata on\ntheir own.\n\n$SYSTEMDLOGLOCATION\nA boolean. If true, messages will be prefixed with a filename and\nline number in the source code where the message originates.\n\nNote that the log location is often attached as metadata to journal\nentries anyway. Including it directly in the message text can\nnevertheless be convenient when debugging programs.\n\n$SYSTEMDLOGTID\nA boolean. If true, messages will be prefixed with the current\nnumerical thread ID (TID).\n\nNote that the this information is attached as metadata to journal\nentries anyway. Including it directly in the message text can\nnevertheless be convenient when debugging programs.\n\n$SYSTEMDLOGTARGET\nThe destination for log messages. One of console (log to the\nattached tty), console-prefixed (log to the attached tty but with\nprefixes encoding the log level and \"facility\", see syslog(3), kmsg\n(log to the kernel circular log buffer), journal (log to the\njournal), journal-or-kmsg (log to the journal if available, and to\nkmsg otherwise), auto (determine the appropriate log target\nautomatically, the default), null (disable log output).\n\n$SYSTEMDPAGER\nPager to use when --no-pager is not given; overrides $PAGER. If\nneither $SYSTEMDPAGER nor $PAGER are set, a set of well-known\npager implementations are tried in turn, including less(1) and\nmore(1), until one is found. If no pager implementation is\ndiscovered no pager is invoked. Setting this environment variable\nto an empty string or the value \"cat\" is equivalent to passing\n--no-pager.\n\n$SYSTEMDLESS\nOverride the options passed to less (by default \"FRSXMK\").\n\nUsers might want to change two options in particular:\n\nK\nThis option instructs the pager to exit immediately when Ctrl+C\nis pressed. To allow less to handle Ctrl+C itself to switch\nback to the pager command prompt, unset this option.\n\nIf the value of $SYSTEMDLESS does not include \"K\", and the\npager that is invoked is less, Ctrl+C will be ignored by the\nexecutable, and needs to be handled by the pager.\n\nX\nThis option instructs the pager to not send termcap\ninitialization and deinitialization strings to the terminal. It\nis set by default to allow command output to remain visible in\nthe terminal even after the pager exits. Nevertheless, this\nprevents some pager functionality from working, in particular\npaged output cannot be scrolled with the mouse.\n\nSee less(1) for more discussion.\n\n$SYSTEMDLESSCHARSET\nOverride the charset passed to less (by default \"utf-8\", if the\ninvoking terminal is determined to be UTF-8 compatible).\n\n$SYSTEMDPAGERSECURE\nTakes a boolean argument. When true, the \"secure\" mode of the pager\nis enabled; if false, disabled. If $SYSTEMDPAGERSECURE is not set\nat all, secure mode is enabled if the effective UID is not the same\nas the owner of the login session, see geteuid(2) and\nsdpidgetowneruid(3). In secure mode, LESSSECURE=1 will be set\nwhen invoking the pager, and the pager shall disable commands that\nopen or create new files or start new subprocesses. When\n$SYSTEMDPAGERSECURE is not set at all, pagers which are not known\nto implement secure mode will not be used. (Currently only less(1)\nimplements secure mode.)\n\nNote: when commands are invoked with elevated privileges, for\nexample under sudo(8) or pkexec(1), care must be taken to ensure\nthat unintended interactive features are not enabled. \"Secure\" mode\nfor the pager may be enabled automatically as describe above.\nSetting SYSTEMDPAGERSECURE=0 or not removing it from the inherited\nenvironment allows the user to invoke arbitrary commands. Note that\nif the $SYSTEMDPAGER or $PAGER variables are to be honoured,\n$SYSTEMDPAGERSECURE must be set too. It might be reasonable to\ncompletely disable the pager using --no-pager instead.\n\n$SYSTEMDCOLORS\nTakes a boolean argument. When true, systemd and related utilities\nwill use colors in their output, otherwise the output will be\nmonochrome. Additionally, the variable can take one of the\nfollowing special values: \"16\", \"256\" to restrict the use of colors\nto the base 16 or 256 ANSI colors, respectively. This can be\nspecified to override the automatic decision based on $TERM and\nwhat the console is connected to.\n\n$SYSTEMDURLIFY\nThe value must be a boolean. Controls whether clickable links\nshould be generated in the output for terminal emulators supporting\nthis. This can be specified to override the decision that systemd\nmakes based on $TERM and other conditions.\n", "subsections": [] }, "SEE ALSO": { "content": "systemd(1), systemctl(1)\n\nsystemd 249 SYSTEMD-ANALYZE(1)", "subsections": [] } } } }