Introduction to systemd-analyze

systemd-analyze is a tool that comes with Linux to analyze system boot performance.

Commands available for systemd-analyze.

  • systemd-analyze [OPTIONS…] [time]
  • systemd-analyze [OPTIONS…] blame
  • systemd-analyze [OPTIONS…] critical-chain [UNIT…] * systemd-analyze [OPTIONS…] critical-chain [UNIT…
  • systemd-analyze [OPTIONS…] plot [> file.svg]
  • systemd-analyze [OPTIONS…] dot [PATTERN…] [> file.dot]
  • systemd-analyze [OPTIONS…] dump
  • systemd-analyze [OPTIONS…] set-log-level LEVEL
  • systemd-analyze [OPTIONS…] set-log-target TARGET
  • systemd-analyze [OPTIONS…] get-log-level
  • systemd-analyze [OPTIONS…] get-log-target
  • systemd-analyze [OPTIONS…] syscall-filter [SET…]
  • systemd-analyze [OPTIONS…] verify [FILES…]

The systemd-analyze command means.

  • systemd-analyze displays performance statistics during system startup, obtains systemd system manager status and trace information, and verifies the correctness of unit files.
  • systemd-analyze time displays the following times: (1) how long the kernel ran before starting the first user-state process (init); (2) how long initrd (initial RAM disk) ran before switching to the actual root file system; (3) how long it took for the user space to finish booting after entering the actual root file system. (3) how long it took for the user space boot to complete after entering the actual root filesystem. Note that the above times simply calculate the time it took to reach the different markers during the boot process, and do not take into account the time it took for each unit to actually finish booting and the time the disk was idle.
  • systemd-analyze blame lists all units that are currently active, in descending order of how long each unit took to boot. This information helps users to optimize system startup speed. Note, however, that this information can also be misleading, as a unit that takes longer to boot may be waiting for another dependent unit to finish booting.
  • systemd-analyze critical-chain [UNIT…] Displays the time-critical chain in a tree for the specified unit (omitting the parameter indicates the default boot target unit). The moment after the “@” indicates the start time of the unit; the length after the “+” indicates the total time it took for the unit to finish starting. Note, however, that this information can also be misleading, since a unit that takes longer to start may be just waiting for another dependent unit to finish starting.
  • systemd-analyze plot outputs an SVG image detailing when each unit started and highlighting how long it took for each unit to finish starting.
  • systemd-analyze dot outputs a graph of dependencies between units in GraphViz dot(1) format. In practice, the systemd-analyze dot | dot -Tsvg > systemd.svg command is usually used to generate the final SVG image depicting the inter-unit dependencies. All dependencies will be displayed unless the -order or -require option is used to restrict the display to specific types of dependencies. If at least one PATTERN parameter is specified (e.g., a shell matching pattern like *.target), then only direct dependencies for all units matching those patterns will be displayed.
  • systemd-analyze dump outputs the state of all units in a human-readable format (typically thousands of lines). Do not use this output for program analysis because its format often changes unannounced.
  • systemd-analyze set-log-level LEVEL Changes the log level of the systemd daemon to LEVEL (see the -log-level= option in systemd(1) for available values)
  • systemd-analyze set-log-target TARGET Changes the logging target of the systemd daemon to TARGET (see the -log-target= option of systemd(1) for available values)
  • systemd-analyze get-log-level Print out the current log level of the systemd daemon.
  • systemd-analyze get-log-target Print out the current log target of the systemd daemon.
  • systemd-analyze syscall-filter [SET…] If at least one SET argument is specified, then only the list of syscalls contained in the specified set is displayed; otherwise, the details of the full set of syscalls are displayed. Note that the “@” prefix must be included in the SET parameter.
  • systemd-analyze verify verifies the correctness of the specified unit file and other unit files referenced by the specified unit file, and displays the errors found. The FILES argument can be the exact path to the unit file (with parent directory) or just the name of the unit file (without the directory prefix). For those units for which only the filename (without directory prefix) is given, the search will take precedence over the directories of other units for which the exact path has been given, and if not found, the search will continue in the regular unit directory (see the unit(5) manual for details). You can use the $SYSTEMD_UNIT_PATH environment variable to change the default unit search directory.
  • If no command is specified, then it is equivalent to using the systemd-analyze time command.

systemd-analyze hands-on

1
2
3

➜~ systemd-analyze
Startup finished in 3.220s (kernel) + 23.420s (userspace) = 26.641s 
graphical.target reached after 23.111s in userspace

You can see that it took more than 23 seconds to turn on the computer. Next, inquire who should take the blame for this.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

➜~ systemd-analyze blame
21.594s NetworkManager-wait-online.service
680ms systemd-logind.service
587ms lvm2-monitor.service
570ms lightdm.service
534ms dev-sdc2.device
371ms upower.service
309ms tlp.service
292ms systemd-timesyncd.service
260ms systemd-udevd.service
252ms ModemManager.service
217ms systemd-journald.service
131ms systemd-journal-flush.service
121ms boot-efi.mount
117ms avahi-daemon.service
115ms bluetooth.service
111ms polkit.service
111ms NetworkManager.service
110ms udisks2.service
102ms systemd-modules-load.service

You can see that NetworkManager-wait-online.service takes the longest time, 21 seconds. It is possible that the time taken here is waiting for other servers to start, so let’s look at the start time of its associated services.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

➜ ~ systemd-analyze critical-chain NetworkManager-wait-online.service
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.

NetworkManager-wait-online.service +21.594s
└─NetworkManager.service @1.398s +111ms
└─dbus.service @1.390s
└─basic.target @1.389s
└─sockets.target @1.389s
└─dbus.socket @1.389s
└─sysinit.target @1.384s
└─systemd-backlight@backlight:intel_backlight.service @1.313s +71ms
└─system-systemd\x2dbacklight.slice @1.312s
└─system.slice @207ms
└─-.slice @207ms

But this one saw that here it was waiting for other services, but it did not take 21 seconds how much more.

Having found the service that affects the startup, the easiest way to disable this service is.

1

➜ ~ sudo systemctl disable NetworkManager-wait-online.service

Option 2: Edit the /lib/systemd/system/NetworkManager-wait-online.service file and set the

1

[Service] Type=oneshot ExecStart=/usr/bin/nm-online -s -q --timeout=30

Timeout time changed from 30 to 10

In addition, let’s look at what other bootable services could be optimized.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

➜ ~ systemctl list-unit-files --type=service | grep enabled
autovt@.service enabled 
avahi-daemon.service enabled 
bluetooth.service enabled 
bumblebeed.service enabled 
cronie.service enabled 
dbus-org.bluez.service enabled 
dbus-org.freedesktop.Avahi.service enabled 
dbus-org.freedesktop.ModemManager1.service enabled 
dbus-org.freedesktop.NetworkManager.service enabled 
dbus-org.freedesktop.nm-dispatcher.service enabled 
dbus-org.freedesktop.timesync1.service enabled 
display-manager.service enabled 
getty@.service enabled 
lightdm.service enabled 
ModemManager.service enabled 
NetworkManager-dispatcher.service enabled 
NetworkManager.service enabled 
org.cups.cupsd.service enabled 
systemd-fsck-root.service enabled-runtime
systemd-remount-fs.service enabled-runtime
systemd-timesyncd.service enabled 
tlp-sleep.service enabled 
tlp.service enabled 
ufw.service enabled

Corresponding functions of related services.

  • NetworkManager-wait-online.service: network service manager, disable it without affecting normal network usage
  • autovt@.service: Login-related Reserved
  • avahi-daemon.service: let the program discover local network services automatically. It should be disabled unless you have a compatible device or a service that uses the zeroconf protocol.
  • service: Bluetooth service, you can also disable it if used
  • service: graphics card driver, keep it
  • service: daemon for scheduled schedule and time triggered events. Reserved
  • dbus-org.bluez.service: Bluetooth daemon, can be disabled
  • dbus-org.freedesktop.Avahi.service: let the program discover local network services automatically. It should be disabled unless you have a compatible device or a service using the zeroconf protocol.
  • dbus-org.freedesktop.ModemManager1.service: Used to provide mobile broadband broadband (2G/3G/4G) interface. Can be disabled
  • dbus-org.freedesktop.NetworkManager.service：Desktop NIC management can be disabled
  • dbus-org.freedesktop.nm-dispatcher.service: NIC daemon, can be disabled
  • dbus-org.freedesktop.timesync1.service: time synchronization, can be disabled
  • display-manager.service: used to manage the life cycle of the display, it determines how to control its logical display based on the currently connected physical display device, reserved
  • getty@.service enabled: tty console related, reserved
  • service enabled: graphical interface display, reserved
  • service: daemon activated by dbus to provide mobile broadband broadband (2G/3G/4G) interface. Can be disabled
  • NetworkManager-dispatcher.service: NIC daemon, can be disabled
  • service: program that detects the network and automatically connects to the network. Recommended to keep
  • cups.cupsd.service: generic UNIX printing system daemon. It can be disabled.
  • systemd-fsck-root.service: responsible for checking the root file system.
  • systemd-remount-fs.service: service that starts early in the boot process and remounts the root and /usr directories, as well as the virtual filesystem, according to the mount options set in fstab(5). This is necessary because these filesystems are pre-mounted before the /etc/fstab file can be read, for example in the initial RAM disk, or before entering the container environment. Reserved
  • systemd-timesyncd.service: daemon service for synchronizing the system clock across the network, can be disabled
  • tlp-sleep.service: battery optimization, power management, recommended to keep
  • service：battery optimization, power management, recommended to keep
  • service: firewall service, recommended to keep