How to investigate Ubuntu slow boot

Investigating why Ubuntu boots slowly can be difficult. There are a lot of things that can go wrong: a lingering service, a bad config file, a wrong disk uuid in fstab and others.

In my opinion the easiest way to start is by using “systemd-analyze” which is part of systemd.
Since version 15.04, Ubuntu has switched from upstart to systemd as the default system and service manager. Systemd is not something specific to Ubuntu, but rather an industry standard that other major distributions have adopted as well: Debian, Fedora and CentOS to name a few.
“systemd-analyze” gives us information about what programs are run on startup and how much time they need to start.

There are around a dozen options that we can use from systemd-analyze to see where the startup bottleneck is. But from a time perspective we’re only interested in a few of them (to see the rest of the options available you can run “man systemd-analyze” in a terminal):

The options that we are interested in are:


Outputs the svg code with all the started services, their dependencies and how long it took for them to start.

For a better visualization you can pipe the output to an svg file and then open it with an image viewer:

$ systemd-analyze plot > init.svg

You should be looking for long red bars. These bars represent the time it took for that process to start.

When opening the generated svg, you should see something similiar to

systemd-analyze plot


Shows the amount of time spent after the bootloader has given control to the kernel up until the userspace finished initialization.

$ systemd-analyze time
Startup finished in 7.541s (firmware) + 5.696s (loader) + 4.053s (kernel) + 8.206s (userspace) = reached after 8.068s in userspace

The values in this example are for my laptop which has an i7 processor, 16GB of RAM and a 512GB SSD.
If you use an older system, you may not see the firmware data as this is available only for EFI/UEFI systems.
If a lot of time is spent in firmware, there might be an hardware issue.
Time in loader is the time needed by your bootloader, typically Grub. If a considerable amount of time is spent here it might mean that the bootloader can’t find some disks or maybe some kernel boot parameters are wrong.
Kernel time is used for loading drivers and other initializations. After the kernel finished its startup it will launch the init process (which usually has the id 1).
The init process, in our case is systemd and represents time spent in userspace.


Displays an ordered list of services, from slowest to fastest.

$ systemd-analyze blame
6.272s NetworkManager-wait-online.service
          2.998s plymouth-quit-wait.service
           930ms dev-sda6.device
           795ms fwupd.service
           632ms snapd.service
           547ms motd-news.service
           449ms plymouth-start.service
           396ms NetworkManager.service
           325ms upower.service
           274ms systemd-logind.service


Similar to blame, but it takes into account dependencies between services. The slow starting services will be highlighted in red.

$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character. @8.068s
└─ @8.068s
  └─kerneloops.service @8.058s +10ms
    └─ @8.056s
      └─NetworkManager-wait-online.service @1.783s +6.272s
        └─NetworkManager.service @1.385s +396ms
          └─dbus.service @1.359s
            └─ @1.356s
              └─ @1.356s
                └─snapd.socket @1.354s +2ms
                  └─ @1.354s
                    └─systemd-timesyncd.service @1.137s +215ms
                      └─systemd-tmpfiles-setup.service @1.125s +9ms
                        └─ @1.123s
                          └─run-snapd-ns-docker.mnt.mount @2.093s
                            └─run-snapd-ns.mount @1.818s
                              └─ @262ms
                                └─swapfile.swap @157ms +104ms
                                  └─systemd-remount-fs.service @147ms +7ms
                                    └─systemd-journald.socket @140ms
                                      └─system.slice @139ms
                                        └─-.slice @137ms

By using all this information from systemd-analyze we can find out what is slowing the startup process. Once we know that, we can dig deeper and get to the root of the problem.


    1. Hi Chan,
      I would look in the log files to see exactly what is happening.
      You can look at sudo dmesg and /var/log/syslog
      I would also check /etc/fstab. I once had an entry for a partition which was no longer available and this delayed my boot time by ~1 minute because Ubuntu kept waiting for the partition to appear.

Leave a Comment

Your email address will not be published. Required fields are marked *

11 − seven =

This site uses Akismet to reduce spam. Learn how your comment data is processed.