systemd-analyze
systemd-analyze is an analyzer and toolkit to help with tuning the system for performance and securityInstallation
When systemd-analyze is not installed by default, it can be added to the system using the relevant software package.
Package information for systemd-analyze
| Operating system | Package name | Installation |
|---|---|---|
| AlmaLinux | systemd | |
| Arch Linux | systemd | |
| Debian | systemd | |
| Fedora | systemd | |
| Red Hat Enterprise Linux | systemd | |
| Rocky Linux | systemd | |
| Ubuntu | systemd | |
Your Linux distribution using a different package? Share your feedback.
Usage
Available options
| Short option | Long option | Description |
|---|---|---|
| --no-pager | Disable the pager, making it easier to parse the information |
Missing an option in this overview? Share your feedback.
Subcommands
| Command | Description | Extra information |
|---|---|---|
| architectures | Show information about supported architecture, including the native architecture of the system | |
| blame | Show unit timing information ordered by duration | |
| calendar | Test calendar entry | |
| capability [NAME or NUMBER] | Show available capabilities | |
| cat-config | Show parsed configuration files | |
| compare-versions | Compare two versions strings and show result | |
| condition | Evaluate a condition | |
| critical-chain | Provide a tree with timing information | |
| dot | Gather information for dot utility to show a dependency graph | |
| dump [PATTERN] | Output state of service manager | |
| exit-status | Shows available exit status codes and their mapped name | |
| filesystems [NAME] | Show filesystems | |
| fdstore SERVICE | Show file descriptor information for a service | |
| image-policy POLICY | Analyze an image policy string | |
| inspect-elf FILE | Parse and print ELF package information | |
| malloc [D-BUS SERVICE] | Dump malloc statistics for D-Bus services | |
| plot | Create SVG graphic for service initialization | |
| pcrs [PCR] | Show platform counter registers (PCR) for TPM2 devices, including their names | |
| security [UNIT] | Perform analysis on unit to determine possible security improvements | |
| srk [>FILE] | Read Storage Root Key (SRK) from TPM2 device and writes it (TPM2B_PUBLIC format) to stdout | |
| syscall-filter [NAME] | List available syscalls in a seccomp filter | |
| time | Shows time spent in the different stages of the boot cycle | |
| timespan | Parse a duration (in time) and show the normalized form | |
| timestamp | Parse a timestamp and show the normalized form | |
| unit-files | Show all files and symlinks for units | |
| unit-paths | Show directories used for units | |
| verify FILE | Validator function for unit files |
Missing a command? Share your feedback.
architectures
Usage
systemd-analyze architectures
Purpose
architectures shows available CPU architecture support and the native architecture of the system.
Notes:
- The native architecture can also be displayed with
hostnamectl
blame
Usage
systemd-analyze blame
Purpose
blame shows unit timing information ordered by duration (longest first). It helps finding out why the boot sequence takes a specific amount of time.
Notes:
- Due to parallelism timing information might not be reliable
- Latency introduced by events such as waiting for hardware might influence timings
- Time is measured in the ACTIVATING state of the unit, not all units have this particular state
The subcommand blame can be used without any parameters.
# systemd-analyze blame
1.990s apt-daily-upgrade.service
1.729s dev-mapper-ubuntu\x2d\x2dvg\x2dubuntu\x2d\x2dlv.device
1.664s snap.lxd.activate.service
1.589s snapd.seeded.service
1.184s systemd-random-seed.service
1.005s dev-loop3.device
993ms dev-loop4.device
992ms dev-loop5.device
987ms dev-loop0.device
986ms dev-loop1.device
942ms networkd-dispatcher.service
755ms snapd.service
750ms cloud-init-local.service
685ms cloud-config.service
572ms apt-daily.service
557ms cloud-final.service
551ms systemd-logind.service
527ms systemd-udev-trigger.service
481ms keyboard-setup.service
481ms systemd-timesyncd.service
476ms cloud-init.service
431ms motd-news.service
406ms udisks2.service
404ms upower.service
<snip>
calendar
systemd-analyze calendar STRING
Purpose
calendar tests an expression, transforms it into a normalized form, and then shows it. Useful for testing timers and see if they will be triggered at the right time.
Examples
# systemd-analyze calendar "Mon *-*-* 00:00:00"
Normalized form: Mon *-*-* 00:00:00
Next elapse: Mon 2024-07-01 00:00:00 UTC
From now: 3 days left
capability
The subcommand capability can be used to show the available Linux capabilities. While most Linux systems will have a very similar list, it may change a little between them depending on the kernel version and compilation options. Just running the subcommand will shown the available capabilities. When providing also the name or number of the capability, the output will just show that capability.
Capability examples
- systemd-analyze capability
- systemd-analyze capability CAPABILITY
# systemd-analyze capability
NAME NUMBER
cap_chown 0
cap_dac_override 1
cap_dac_read_search 2
cap_fowner 3
cap_fsetid 4
cap_kill 5
cap_setgid 6
cap_setuid 7
cap_setpcap 8
cap_linux_immutable 9
cap_net_bind_service 10
cap_net_broadcast 11
cap_net_admin 12
cap_net_raw 13
cap_ipc_lock 14
cap_ipc_owner 15
cap_sys_module 16
cap_sys_rawio 17
cap_sys_chroot 18
cap_sys_ptrace 19
cap_sys_pacct 20
cap_sys_admin 21
cap_sys_boot 22
cap_sys_nice 23
cap_sys_resource 24
cap_sys_time 25
cap_sys_tty_config 26
cap_mknod 27
cap_lease 28
cap_audit_write 29
cap_audit_control 30
cap_setfcap 31
cap_mac_override 32
cap_mac_admin 33
cap_syslog 34
cap_wake_alarm 35
cap_block_suspend 36
cap_audit_read 37
cap_perfmon 38
cap_bpf 39
cap_checkpoint_restore 40
cat-config
Usage
systemd-analyze cat-config CONFIGFILE
Purpose
cat-config shows a parsed configuration file. It aims to replicate the behavior of ‘systemctl cat UNIT’, but for configuration files.
Examples
# systemd-analyze cat-config /etc/systemd/coredump.conf
# /etc/systemd/coredump.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it under the
# terms of the GNU Lesser General Public License as published by the Free
# Software Foundation; either version 2.1 of the License, or (at your option)
# any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file (or a copy of it placed in
# /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
# the /etc/systemd/coredump.conf.d/ directory. The latter is generally
# recommended. Defaults can be restored by simply deleting the main
# configuration file and all drop-ins located in /etc/.
#
# Use 'systemd-analyze cat-config systemd/coredump.conf' to display the full config.
#
# See coredump.conf(5) for details.
[Coredump]
#Storage=external
#Compress=yes
# On 32-bit, the default is 1G instead of 32G.
#ProcessSizeMax=32G
#ExternalSizeMax=32G
#JournalSizeMax=767M
#MaxUse=
#KeepFree=
compare-versions
Usage
- systemd-analyze compare-versions string1 string2
- systemd-analyze compare-versions string1 OPERATOR string2
Purpose
compare-versions compares two strings, optionally with an operator. Based on the outcome, it provides an exit code of 0, 1, 11, or 12.
Operators
- lt (less than)
- gt (greater than)
- le (less or equal)
- ge (greater or equal)
- eq (equal)
- ne (not equal)
Examples
Compare two package versions to see which is the oldest or newest package
# systemd-analyze compare-versions lynis-3.0.3 lynis-3.0.4
lynis-3.0.3 < lynis-3.0.4
The exit code is 11 if the first is greater, otherwise exit code 12. In the example about $? shows 12.
# systemd-analyze compare-versions lynis-3.0.3 gt lynis-3.0.4; echo $?
1
In this case it not true, so exit code of 1. If it is true, then exit 0 will be displayed.
condition
Usage
systemd-analyze condition STRING
Purpose
condition checks an assert or condition and shows the outcome.
# systemd-analyze condition 'AssertPathExists=/var/log'
test.service: AssertPathExists=/var/log succeeded.
Asserts succeeded.
# systemd-analyze condition 'AssertPathExists=/var/log2'
test.service: AssertPathExists=/var/log2 failed.
Asserts failed.
critical-chain
Usage
- systemd-analyze critical-chain
- systemd-analyze critical-chain UNIT
Purpose
critical-chain provides a tree with timing information for units. This may help to find the reason why a service or generic unit may take a long time starting.
Notes:
- Similar behavior as blame
Examples
# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @6.948s
└─multi-user.target @6.947s
└─snapd.seeded.service @5.286s +1.589s
└─basic.target @5.237s
└─sockets.target @5.236s
└─snapd.socket @5.231s +4ms
└─sysinit.target @5.203s
└─cloud-init.service @4.725s +476ms
└─cloud-init-local.service @2.350s +750ms
└─systemd-remount-fs.service @454ms +59ms
└─systemd-journald.socket @385ms
└─system.slice @354ms
└─-.slice @354ms
dot
Usage
- systemd-analyze dot
- systemd-analyze dot UNIT
Options
- --order
- --require
Purpose
dot creates input for GraphViz’ dot utility to showing a dependency graph
Notes:
- Install graphviz package to pipe information to dot command
Examples
systemd-analyze dot | dot -Tsvg > systemd.svg
exit-status
Usage
- systemd-analyze exit-status
- systemd-analyze exit-status STATUS
Purpose
exit-status shows available exit status codes and their names.
Examples
# systemd-analyze exit-status
NAME STATUS CLASS
SUCCESS 0 libc
FAILURE 1 libc
INVALIDARGUMENT 2 LSB
NOTIMPLEMENTED 3 LSB
NOPERMISSION 4 LSB
NOTINSTALLED 5 LSB
NOTCONFIGURED 6 LSB
NOTRUNNING 7 LSB
USAGE 64 BSD
DATAERR 65 BSD
NOINPUT 66 BSD
NOUSER 67 BSD
NOHOST 68 BSD
UNAVAILABLE 69 BSD
SOFTWARE 70 BSD
OSERR 71 BSD
OSFILE 72 BSD
CANTCREAT 73 BSD
IOERR 74 BSD
TEMPFAIL 75 BSD
PROTOCOL 76 BSD
NOPERM 77 BSD
CONFIG 78 BSD
CHDIR 200 systemd
NICE 201 systemd
FDS 202 systemd
EXEC 203 systemd
MEMORY 204 systemd
LIMITS 205 systemd
<snip>
To find out the name of a specific exit status code, define the name or status.
# systemd-analyze exit-status 0
NAME STATUS CLASS
SUCCESS 0 libc
filesystems
Usage
- systemd-analyze filessystems
- systemd-analyze filessystems GROUP
Purpose
filesystems shows available filesystems grouped per category.
Example
# systemd-analyze filesystems @common-block
@common-block
# Common block device filesystems
btrfs (magic: 0x9123683e)
erofs (magic: 0xe0f5e1e2)
exfat (magic: 0x2011bab0)
ext4 (magic: 0xef53)
f2fs (magic: 0xf2f52010)
iso9660 (magic: 0x9660)
ntfs3 (magic: 0x7366746e)
squashfs (magic: 0x73717368)
udf (magic: 0x15013346)
vfat (magic: 0x4d44)
xfs (magic: 0x58465342)
security
Usage
systemd-analyze security UNIT
Purpose
security performs an audit on a service unit to see what can be done to improve its security level. It defines what settings can be activated to sandbox or restrict a service. Most items are scored and at the end a total risk score is displayed, where a lower score is better.
Suggested articles:
Example
Running security scan on nginx service.
# systemd-analyze security nginx.service
NAME DESCRIPTION EXPOSURE
✓ SystemCallFilter=~@swap System call allow list defined for service, and @swap is not included
✗ SystemCallFilter=~@resources System call allow list defined for service, and @resources is included (e.g. ioprio_set is allowed) 0.2
✓ SystemCallFilter=~@reboot System call allow list defined for service, and @reboot is not included
✓ SystemCallFilter=~@raw-io System call allow list defined for service, and @raw-io is not included
✗ SystemCallFilter=~@privileged System call allow list defined for service, and @privileged is included (e.g. chown is allowed) 0.2
✓ SystemCallFilter=~@obsolete System call allow list defined for service, and @obsolete is not included
✓ SystemCallFilter=~@mount System call allow list defined for service, and @mount is not included
✓ SystemCallFilter=~@module System call allow list defined for service, and @module is not included
✓ SystemCallFilter=~@debug System call allow list defined for service, and @debug is not included
✓ SystemCallFilter=~@cpu-emulation System call allow list defined for service, and @cpu-emulation is not included
✓ SystemCallFilter=~@clock System call allow list defined for service, and @clock is not included
✗ RootDirectory=/RootImage= Service runs within the host's root directory 0.1
SupplementaryGroups= Service runs as root, option does not matter
RemoveIPC= Service runs as root, option does not apply
✗ User=/DynamicUser= Service runs as root user 0.4
<snip>
syscall-filter
Usage
- systemd-analyze syscall-filter
- systemd-analyze syscall-filter FILTERSET
Purpose
syscall-filter shows which syscalls are part of a filter set, or a group of syscalls.
Suggested articles:
Examples
# systemd-analyze syscall-filter @network-io
@network-io
# Network or Unix socket IO, should not be needed if not network facing
accept
accept4
bind
connect
getpeername
getsockname
getsockopt
listen
recv
recvfrom
recvmmsg
recvmmsg_time64
recvmsg
send
sendmmsg
sendmsg
sendto
setsockopt
shutdown
socket
socketcall
socketpair
time
Usage
systemd-analyze time
Purpose
time shows how much time is spent in the kernel, the initrd, and the initialization time for userspace itself.
Notes:
- The times do not consider full initialization, as background tasks might still be running, including disk activity to complete the boot process
Examples
# systemd-analyze time
Startup finished in 3.357s (kernel) + 8.125s (userspace) = 11.482s
graphical.target reached after 6.948s in userspace
timespan
Usage
systemd-analyze timespan STRING
Purpose
timestamp tests an expression, transforms it into a normalized form, and then shows it.
Examples
# systemd-analyze timespan "7 years"
Original: 7 years
μs: 220903200000000
Human: 7y
timestamp
Usage
systemd-analyze timestamp STRING
Purpose
timestamp tests an expression, transforms it into a normalized form, and then shows when the timestamp was or will be.
Examples
- today (when day started)
- tomorrow (day in future)
- 22:00 (hour and minutes)
- @1888123123 (Unix timestamp)
- 2024-12-31T23:59:59Z
# systemd-analyze timestamp "tomorrow"
Original form: tomorrow
Normalized form: Fri 2024-06-28 00:00:00 UTC
UNIX seconds: @1719532800
From now: 10h left
Specific moment in time:
systemd-analyze timestamp "2024-12-31T23:59:59Z"
Original form: 2024-12-31T23:59:59Z
Normalized form: Wed 2025-01-01 00:59:59 CET
(in UTC): Tue 2024-12-31 23:59:59 UTC
UNIX seconds: @1735689599
From now: 6 months 4 days left
Unix timestamp:
# systemd-analyze timestamp @1888123123
Original form: @1888123123
Normalized form: Wed 2029-10-31 06:38:43 UTC
UNIX seconds: @1888123123
From now: 5 years 4 months left
unit-files
Usage
systemd-analyze unit-files
Purpose
unit-files shows all known unit names and aliases. This is useful for discovering what is available to the system, including where specific services are being referred.
Examples
# systemd-analyze unit-files | grep ssh
ids: sshd-generated@.service → /run/systemd/generator/sshd-generated@.service
ids: sshd-vsock.socket → /run/systemd/generator/sshd-vsock.socket
ids: sshd.service → /usr/lib/systemd/system/sshd.service
ids: ssh-access.target → /usr/lib/systemd/system/ssh-access.target
ids: sshd-unix-local@.service → sshd-generated@.service
ids: sshdgenkeys.service → /usr/lib/systemd/system/sshdgenkeys.service
ids: gpg-agent-ssh@.socket → /usr/lib/systemd/system/gpg-agent-ssh@.socket
ids: sshd-unix-local.socket → /run/systemd/generator/sshd-unix-local.socket
ids: sshd-vsock@.service → sshd-generated@.service
aliases: sshd-unix-local.socket ← sshd-unix-local.socket
aliases: ssh-access.target ← ssh-access.target
aliases: sshd-generated@.service ← sshd-generated@.service, sshd-unix-local@.service, sshd-vsock@.service
aliases: sshdgenkeys.service ← sshdgenkeys.service
aliases: sshd.service ← sshd.service
aliases: gpg-agent-ssh@.socket ← gpg-agent-ssh@.socket
aliases: sshd-vsock.socket ← sshd-vsock.socket
unit-paths
Usage
systemd-analyze unit-paths
Purpose
unit-paths shows all paths to look for units.
Examples
# systemd-analyze unit-paths
/etc/systemd/system.control
/run/systemd/system.control
/run/systemd/transient
/run/systemd/generator.early
/etc/systemd/system
/etc/systemd/system.attached
/run/systemd/system
/run/systemd/system.attached
/run/systemd/generator
/usr/local/lib/systemd/system
/usr/lib/systemd/system
/run/systemd/generator.late
verify
Usage
systemd-analyze verify UNIT
Purpose
verify tests a unit file, like a linting tool. Any issues with incorrect assignments will be displayed.
Examples
# systemd-analyze verify nginx.service
/etc/systemd/system/nginx.service.d/override.conf:7: Unknown section 'Units'. Ignoring.
Examples using systemd-analyze
Security analysis for services
Analyze nginx unit file for possible improvements to secure the service
systemd-analyze security nginx.serviceRelevant articles using the systemd-analyze command
The following articles include an example on how to use systemd-analyze and might be worth further exploring.