Fedora 24: systemd-analyze (solved)

Odd Results

I read an article about systemd-analyze and tried it on my Dell XPS 13 9343.

Startup finished in 6.363s (firmware) + 6.029s (loader) + 1.020s (kernel) + 2.756s (initrd) + 1min 30.405s (userspace) = 1min 46.575s

Running this on my Lenovo T530 still running Fedora 23 resulted in the following:

Startup finished in 4.625s (firmware) + 6.467s (loader) + 1.898s (kernel) + 2.153s (initrd) + 7.929s (userspace) = 23.073s

So, to ensure that this is an issue with Fedora 24 and not my Dell I booted the T530 up to Fedora 24 and re-ran the systemd-analyze on it and got the following results:

Startup finished in 6.127s (firmware) + 15.969s (loader) + 4.068s (kernel) + 3.066s (initrd) + 1min 31.377s (userspace) = 2min 610ms

When the boot first completed and I was able to open a terminal window on the desktop to run the systemd-analyze command I got a message that boot was not finished.

Bootup is not yet finished. Please try again later.

This result was duplicated on the Dell XPS 13 as well. I then tried troubleshooting the issue with systemd-analyze blame and got the following:

          3.850s plymouth-quit-wait.service
1.872s dnf-makecache.service
1.613s plymouth-start.service
674ms systemd-udev-settle.service
598ms firewalld.service
591ms dev-mapper-fedora\x2droot.device
430ms lvm2-monitor.service
273ms lvm2-pvscan@8:3.service
231ms libvirtd.service
216ms accounts-daemon.service
205ms cups.service
177ms udisks2.service
147ms systemd-logind.service
116ms ModemManager.service
112ms user@42.service
111ms upower.service
98ms user@1000.service
97ms proc-fs-nfsd.mount
88ms abrtd.service
87ms systemd-udev-trigger.service
87ms packagekit.service
86ms polkit.service
82ms systemd-journald.service
76ms iio-sensor-proxy.service
68ms systemd-udevd.service
65ms systemd-journal-flush.service
64ms gdm.service
63ms systemd-vconsole-setup.service
61ms unbound-anchor.service
56ms NetworkManager.service
48ms abrt-ccpp.service
48ms bluetooth.service
48ms systemd-fsck@dev-disk-by\x2duuid-63a65c9c\x2dff2d\x2d4e27\x2dac05\x2dae7b80c0fb3b.service
47ms systemd-fsck@dev-disk-by\x2duuid-880D\x2dE9AE.service
47ms systemd-tmpfiles-setup-dev.service
46ms colord.service
43ms avahi-daemon.service
41ms fedora-readonly.service
40ms gssproxy.service
37ms rtkit-daemon.service
33ms systemd-fsck@dev-mapper-fedora\x2dhome.service
30ms chronyd.service
28ms systemd-fsck-root.service
24ms systemd-tmpfiles-setup.service
24ms systemd-rfkill.service
21ms dmraid-activation.service
21ms systemd-remount-fs.service
20ms livesys-late.service
20ms kmod-static-nodes.service
19ms home.mount
19ms livesys.service
19ms fedora-import-state.service
18ms dev-mapper-fedora\x2dswap.swap
18ms dev-hugepages.mount
17ms wpa_supplicant.service
16ms systemd-sysctl.service
16ms auditd.service
15ms systemd-tmpfiles-clean.service
14ms boot-efi.mount
13ms plymouth-read-write.service
12ms rpc-statd-notify.service
10ms systemd-user-sessions.service
10ms dev-mqueue.mount
9ms blk-availability.service
8ms sys-kernel-debug.mount
6ms systemd-random-seed.service
6ms sys-fs-fuse-connections.mount
6ms boot.mount
6ms systemd-backlight@leds:dell::kbd_backlight.service
5ms nfs-config.service
5ms tmp.mount
4ms systemd-update-utmp-runlevel.service
4ms systemd-update-utmp.service
4ms var-lib-nfs-rpc_pipefs.mount
4ms dracut-shutdown.service
3ms systemd-backlight@backlight:intel_backlight.service
2ms sys-kernel-config.mount

I am still searching for an explanation, but Google searches are not turning up much that is useful. In the end it is curiosity more than something that is actually impacting me as I am able to start working long before systemd-analyze is capable of giving me results and certainly it is not taking 1 minute and 30 seconds for the computer to boot. In fact, when I timed the boot it only took 18.5 seconds for me to get to the desktop.

Update:

thanks to the comment from Michal Schmidt I ran systemctl list-jobs after confirming that systemd analyze thought that the system was still booting up and the results are:

[cprofitt@tardis-xps ~]$ systemd-analyze
Bootup is not yet finished. Please try again later.
[cprofitt@tardis-xps ~]$ systemctl list-jobs
JOB UNIT                                              TYPE  STATE
243 hypervkvpd.service                                start waiting
246 sys-devices-virtual-misc-vmbus\x21hv_vss.device   start running
247 systemd-update-utmp-runlevel.service              start waiting
111 multi-user.target                                 start waiting
234 sys-devices-virtual-misc-vmbus\x21hv_fcopy.device start running
110 graphical.target                                  start waiting
244 sys-devices-virtual-misc-vmbus\x21hv_kvp.device   start running
245 hypervvssd.service                                start waiting
233 hypervfcopyd.service                              start waiting

9 jobs listed.

I have more items to go on now and will start doing more research.

Update 2:

I found a bug for Fedora regarding these services and further research found a blog post recommending to disable the following services:

systemctl disable hypervkvpd.service
systemctl disable hypervfcopyd.service
systemctl disable hypervvssd.service

With these services disabled I rebooted the laptop and was immediately able to get results from systemd-analyze:

Startup finished in 6.104s (firmware) + 5.973s (loader) + 1.025s (kernel) + 2.728s (initrd) + 5.969s (userspace) = 21.801s

A huge reduction in the time. While the services were not causing any ‘real’ impact they also appear to provide no functionality unless running on a hyper-v system.

This entry was posted in fedora-planet, Linux and tagged . Bookmark the permalink.

6 Responses to Fedora 24: systemd-analyze (solved)

  1. I have the same results with my laptop(Sony vaio Pro 13), it took 1:30 mins.

  2. Michal Schmidt says:

    Check “systemctl list-jobs” while it thinks it’s still booting.

  3. tod says:

    Thanks for this. Systemd is quite contentious among the penguinistas for its un-UNIX like behavior and the perceived arrogance and insularity of systemd’s developers. This has led to forking distros and users switching to BSD, confusing less technical Linux users-such as me. Please stay on this issue.

  4. Michal Schmidt says:

    The three services services related to Hyper-V pull in the vmbus device units. Since your system is not a Hyper-V guest, the devices never appear and the respective units time out after 90 seconds. Just disable the Hyper-V services. Or even uninstall them with “dnf remove hyperv\*”.

    • Charles Profitt says:

      Was just doing that when you commented. Thanks for the tip. As you see from the update that worked.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s