Revision history [back]

Using information learned here I recently upgraded in place to Fedora 24. Am very happy with it, but have finally decided to try to get on top of rather slow boot times. While waiting more than a minute is hardly problematic, the last time my machine became slow to boot it was because one of the HDDs was due to fail! I'd prefer to know if that sort of thing is imminent ;0)

Reading around a bit, I ran

$ systemd-analyze
Startup finished in 3.368s (kernel) + 3.115s (initrd) + 1min 6.070s (userspace) = 1min 12.555s

Which seems a fairly long time to me for the (userspace). I then went with (complete output for clarity/help)

$ systemd-analyze blame
     29.079s plymouth-quit-wait.service
     18.972s systemd-udev-settle.service
     13.109s systemd-journald.service
     12.823s dev-mapper-fedora\x2droot.device
      9.828s libvirtd.service
      8.399s firewalld.service
      7.283s lvm2-pvscan@8:3.service
      7.068s systemd-journal-flush.service
      6.172s systemd-rfkill.service
      5.103s accounts-daemon.service
      5.059s packagekit.service
      4.475s ModemManager.service
      3.308s abrtd.service
      2.699s udisks2.service
      2.582s cups.service
      2.569s systemd-udevd.service
      1.942s systemd-logind.service
      1.929s iio-sensor-proxy.service
      1.929s netcf-transaction.service
      1.928s livesys.service
      1.928s gssproxy.service
      1.880s avahi-daemon.service
      1.828s fedora-readonly.service
      1.817s lvm2-monitor.service
      1.506s chronyd.service
      1.462s polkit.service
      1.390s proc-fs-nfsd.mount
      1.325s plymouth-start.service
      1.283s systemd-tmpfiles-setup-dev.service
      1.227s user@1000.service
      1.203s wpa_supplicant.service
      1.096s gdm.service
      1.000s dev-mapper-fedora\x2dswap.swap
       965ms colord.service
       608ms dmraid-activation.service
       595ms systemd-fsck@dev-disk-by\x2duuid-80b939ef\x2d08c9\x2d47b0\x2da2
       587ms systemd-fsck@dev-mapper-fedora\x2dhome.service
       556ms auditd.service
       538ms kmod-static-nodes.service
       510ms dev-hugepages.mount
       509ms systemd-remount-fs.service
       497ms mnt-Data.mount
       489ms NetworkManager.service
       472ms systemd-sysctl.service
       353ms abrt-ccpp.service
       327ms systemd-udev-trigger.service
       325ms rtkit-daemon.service
       227ms systemd-tmpfiles-setup.service
       211ms fedora-import-state.service
       190ms rpc-statd-notify.service
       164ms systemd-random-seed.service
       161ms systemd-fsck-root.service
       158ms upower.service
       132ms systemd-user-sessions.service
       125ms plymouth-read-write.service
       116ms home-alan-Music.mount
       113ms boot.mount
       109ms home.mount
        76ms dracut-shutdown.service
        70ms tmp.mount
        69ms sys-kernel-debug.mount
        66ms systemd-vconsole-setup.service
        65ms nfs-config.service
        40ms systemd-update-utmp.service
         9ms blk-availability.service
         9ms livesys-late.service
         7ms systemd-update-utmp-runlevel.service
         5ms var-lib-nfs-rpc_pipefs.mount
         4ms sys-fs-fuse-connections.mount
         4ms dev-mqueue.mount
         1ms sys-kernel-config.mount

I understand that some services are simply waiting for others to complete, and I'm not looking for lightning fast boot times, but surely I must be able to improve this?

Using information learned here I recently upgraded in place to Fedora 24. Am very happy with it, but have finally decided to try to get on top of rather slow boot times. While waiting more than a minute is hardly problematic, the last time my machine became slow to boot it was because one of the HDDs was due to fail! I'd prefer to know if that sort of thing is imminent ;0)

Reading around a bit, I ran

$ systemd-analyze
Startup finished in 3.368s (kernel) + 3.115s (initrd) + 1min 6.070s (userspace) = 1min 12.555s

Which seems a fairly long time to me for the (userspace). I then went with (complete output for clarity/help)

$ systemd-analyze blame
     29.079s plymouth-quit-wait.service
     18.972s systemd-udev-settle.service
     13.109s systemd-journald.service
     12.823s dev-mapper-fedora\x2droot.device
      9.828s libvirtd.service
      8.399s firewalld.service
      7.283s lvm2-pvscan@8:3.service
      7.068s systemd-journal-flush.service
      6.172s systemd-rfkill.service
      5.103s accounts-daemon.service
      5.059s packagekit.service
      4.475s ModemManager.service
      3.308s abrtd.service
      2.699s udisks2.service
      2.582s cups.service
      2.569s systemd-udevd.service
      1.942s systemd-logind.service
      1.929s iio-sensor-proxy.service
      1.929s netcf-transaction.service
      1.928s livesys.service
      1.928s gssproxy.service
      1.880s avahi-daemon.service
      1.828s fedora-readonly.service
      1.817s lvm2-monitor.service
      1.506s chronyd.service
      1.462s polkit.service
      1.390s proc-fs-nfsd.mount
      1.325s plymouth-start.service
      1.283s systemd-tmpfiles-setup-dev.service
      1.227s user@1000.service
      1.203s wpa_supplicant.service
      1.096s gdm.service
      1.000s dev-mapper-fedora\x2dswap.swap
       965ms colord.service
       608ms dmraid-activation.service
       595ms systemd-fsck@dev-disk-by\x2duuid-80b939ef\x2d08c9\x2d47b0\x2da2
       587ms systemd-fsck@dev-mapper-fedora\x2dhome.service
       556ms auditd.service
       538ms kmod-static-nodes.service
       510ms dev-hugepages.mount
       509ms systemd-remount-fs.service
       497ms mnt-Data.mount
       489ms NetworkManager.service
       472ms systemd-sysctl.service
       353ms abrt-ccpp.service
       327ms systemd-udev-trigger.service
       325ms rtkit-daemon.service
       227ms systemd-tmpfiles-setup.service
       211ms fedora-import-state.service
       190ms rpc-statd-notify.service
       164ms systemd-random-seed.service
       161ms systemd-fsck-root.service
       158ms upower.service
       132ms systemd-user-sessions.service
       125ms plymouth-read-write.service
       116ms home-alan-Music.mount
       113ms boot.mount
       109ms home.mount
        76ms dracut-shutdown.service
        70ms tmp.mount
        69ms sys-kernel-debug.mount
        66ms systemd-vconsole-setup.service
        65ms nfs-config.service
        40ms systemd-update-utmp.service
         9ms blk-availability.service
         9ms livesys-late.service
         7ms systemd-update-utmp-runlevel.service
         5ms var-lib-nfs-rpc_pipefs.mount
         4ms sys-fs-fuse-connections.mount
         4ms dev-mqueue.mount
         1ms sys-kernel-config.mount

I understand that some services are simply waiting for others to complete, and I'm not looking for lightning fast boot times, but surely I must be able to improve this?

systemd-analyze critical-chain

graphical.target @1min 26.707s
└─multi-user.target @1min 26.707s
  └─libvirtd.service @48.849s +6.700s
    └─remote-fs.target @48.728s
      └─remote-fs-pre.target @48.728s
        └─iscsi-shutdown.service @48.728s
          └─network.target @48.664s
            └─wpa_supplicant.service @52.943s +290ms
              └─dbus.service @28.131s
                └─basic.target @28.108s
                  └─sockets.target @28.108s
                    └─rpcbind.socket @28.108s
                      └─sysinit.target @28.092s
                        └─systemd-update-utmp.service @28.062s +30ms
                          └─auditd.service @27.463s +589ms
                            └─systemd-tmpfiles-setup.service @27.187s +252ms
                              └─fedora-import-state.service @26.802s +376ms
                                └─local-fs.target @26.800s
                                  └─run-user-1000.mount @1min 574ms
                                    └─local-fs-pre.target @25.221s
                                      └─lvm2-monitor.service @3.438s +3.122s
                                        └─lvm2-lvmetad.service @4.217s
                                          └─lvm2-lvmetad.socket @3.433s
                                            └─-.slice

└─libvirtd.service @48.849s +6.700s

└─wpa_supplicant.service @52.943s +290ms

└─systemd-update-utmp.service @28.062s +30ms
     └─auditd.service @27.463s +589ms
         └─systemd-tmpfiles-setup.service @27.187s +252ms
               └─fedora-import-state.service @26.802s +376ms

Using information learned here I recently upgraded in place to Fedora 24. Am very happy with it, but have finally decided to try to get on top of rather slow boot times. While waiting more than a minute is hardly problematic, the last time my machine became slow to boot it was because one of the HDDs was due to fail! I'd prefer to know if that sort of thing is imminent ;0)

Reading around a bit, I ran

$ systemd-analyze
Startup finished in 3.368s (kernel) + 3.115s (initrd) + 1min 6.070s (userspace) = 1min 12.555s

Which seems a fairly long time to me editing this question for the (userspace). I then went with (complete output for clarity/help)

$ systemd-analyze blame
     29.079s plymouth-quit-wait.service
     18.972s systemd-udev-settle.service
     13.109s systemd-journald.service
     12.823s dev-mapper-fedora\x2droot.device
      9.828s libvirtd.service
      8.399s firewalld.service
      7.283s lvm2-pvscan@8:3.service
      7.068s systemd-journal-flush.service
      6.172s systemd-rfkill.service
      5.103s accounts-daemon.service
      5.059s packagekit.service
      4.475s ModemManager.service
      3.308s abrtd.service
      2.699s udisks2.service
      2.582s cups.service
      2.569s systemd-udevd.service
      1.942s systemd-logind.service
      1.929s iio-sensor-proxy.service
      1.929s netcf-transaction.service
      1.928s livesys.service
      1.928s gssproxy.service
      1.880s avahi-daemon.service
      1.828s fedora-readonly.service
      1.817s lvm2-monitor.service
      1.506s chronyd.service
      1.462s polkit.service
      1.390s proc-fs-nfsd.mount
      1.325s plymouth-start.service
      1.283s systemd-tmpfiles-setup-dev.service
      1.227s user@1000.service
      1.203s wpa_supplicant.service
      1.096s gdm.service
      1.000s dev-mapper-fedora\x2dswap.swap
       965ms colord.service
       608ms dmraid-activation.service
       595ms systemd-fsck@dev-disk-by\x2duuid-80b939ef\x2d08c9\x2d47b0\x2da2
       587ms systemd-fsck@dev-mapper-fedora\x2dhome.service
       556ms auditd.service
       538ms kmod-static-nodes.service
       510ms dev-hugepages.mount
       509ms systemd-remount-fs.service
       497ms mnt-Data.mount
       489ms NetworkManager.service
       472ms systemd-sysctl.service
       353ms abrt-ccpp.service
       327ms systemd-udev-trigger.service
       325ms rtkit-daemon.service
       227ms systemd-tmpfiles-setup.service
       211ms fedora-import-state.service
       190ms rpc-statd-notify.service
       164ms systemd-random-seed.service
       161ms systemd-fsck-root.service
       158ms upower.service
       132ms systemd-user-sessions.service
       125ms plymouth-read-write.service
       116ms home-alan-Music.mount
       113ms boot.mount
       109ms home.mount
        76ms dracut-shutdown.service
        70ms tmp.mount
        69ms sys-kernel-debug.mount
        66ms systemd-vconsole-setup.service
        65ms nfs-config.service
        40ms systemd-update-utmp.service
         9ms blk-availability.service
         9ms livesys-late.service
         7ms systemd-update-utmp-runlevel.service
         5ms var-lib-nfs-rpc_pipefs.mount
         4ms sys-fs-fuse-connections.mount
         4ms dev-mqueue.mount
         1ms sys-kernel-config.mount

I understand that some services are simply waiting for others to complete, and I'm not looking for lightning fast boot times, but surely I must be able to improve this?

Apologies for awful formatting in my comments below. Here are length/clarity:

After thinking about the results of runninga previous

systemd-analyze critical-chain
 

I realised it was showing slow times for libvirtd and checking my bios settings, I disabled "intel virtualization technology" as I don't need/use it. Now my system doesn't load those libraries.

Boot time is still slow, and a new 'candidate has shown up when I re-run the above command. Now, my wait times appear to be influenced by

graphical.target @1min 26.707s
2.354s
└─multi-user.target @1min 26.707s
  └─libvirtd.service @48.849s +6.700s
2.354s
  └─crond.service @38.713s
    └─systemd-user-sessions.service @38.481s +134ms
      └─remote-fs.target @48.728s
@38.480s
        └─remote-fs-pre.target @48.728s
@38.480s
          └─iscsi-shutdown.service @48.728s
@38.479s
            └─network.target @48.664s
@38.394s
              └─wpa_supplicant.service @52.943s +290ms
@48.176s +295ms
                └─dbus.service @28.131s
@26.126s
                  └─basic.target @28.108s
@25.995s
                    └─sockets.target @28.108s
                    └─rpcbind.socket @28.108s
@25.995s
                      └─cups.socket @25.995s
                        └─sysinit.target @28.092s
                        └─systemd-update-utmp.service @28.062s +30ms
                          └─auditd.service @27.463s +589ms
                            └─systemd-tmpfiles-setup.service @27.187s +252ms
                              └─fedora-import-state.service @26.802s +376ms
                                └─local-fs.target @26.800s
                                  └─run-user-1000.mount @1min 574ms
                                    └─local-fs-pre.target @25.221s
                                      └─lvm2-monitor.service @3.438s +3.122s
                                        └─lvm2-lvmetad.service @4.217s
                                          └─lvm2-lvmetad.socket @3.433s
              @25.991s
                          └─sys-fs-fuse-connections.mount @54.056s +5ms
                            └─systemd-journald.socket
                              └─-.slice

In my terminal there are lines highlighted sys-fs-fuse-connections.mount @54.056s +5ms

Am I correct in bold red from thinking this is a normal service, but that it shouldn't take this long?

My machine has two hard discs in it - one containing Fedora boot and system partition plus swap space, the above output, which are

└─libvirtd.service @48.849s +6.700s

└─wpa_supplicant.service @52.943s +290ms

└─systemd-update-utmp.service @28.062s +30ms
     └─auditd.service @27.463s +589ms
         └─systemd-tmpfiles-setup.service @27.187s +252ms
               └─fedora-import-state.service @26.802s +376ms

I ran second disk being a 1Tb internal drive that houses a music library.

Could the disc monitoring tools and it passed the basic tests and didn't detect problems. I'm not sure what the libvirtd.service is but am happy mount options in fstab for this second drive have anything to do my own work if anyone can point out what or where I should be looking - ditto with the other lengthy services (which wait times for sys-fs-fuse ? I've gone back to default options in fstab for this drive (the system disc is why I presume they're highlighted in red)left untouched, entirely as created by Fedora install disc)

editing this question for length/clarity:

After thinking about the results of a previous

systemd-analyze critical-chain

I realised it was showing slow times for libvirtd and checking my bios settings, I disabled "intel virtualization technology" as I don't need/use it. Now my system doesn't load those libraries.

Boot time is still slow, and a new 'candidate has shown up when I re-run the above command. Now, my wait times appear to be influenced by

graphical.target @1min 2.354s
└─multi-user.target @1min 2.354s
  └─crond.service @38.713s
    └─systemd-user-sessions.service @38.481s +134ms
      └─remote-fs.target @38.480s
        └─remote-fs-pre.target @38.480s
          └─iscsi-shutdown.service @38.479s
            └─network.target @38.394s
              └─wpa_supplicant.service @48.176s +295ms
                └─dbus.service @26.126s
                  └─basic.target @25.995s
                    └─sockets.target @25.995s
                      └─cups.socket @25.995s
                        └─sysinit.target @25.991s
                          └─sys-fs-fuse-connections.mount @54.056s +5ms
                            └─systemd-journald.socket
                              └─-.slice

sys-fs-fuse-connections.mount @54.056s +5ms

Am I correct in thinking this is a normal service, but that it shouldn't take this long?

My machine has two hard discs in it - one containing Fedora boot and system partition plus swap space, the second disk being a 1Tb internal drive that houses a music library.

Could the mount options in fstab for this second drive have anything to do with the wait times for sys-fs-fuse ? I've gone back to default options in fstab for this drive (the system disc is left untouched, entirely as created by Fedora install disc)

$ systemd-analyze blame
     22.955s plymouth-quit-wait.service
     16.751s firewalld.service
     11.630s dev-mapper-fedora\x2droot.device
     11.533s systemd-udev-settle.service
      8.231s NetworkManager.service
      7.489s accounts-daemon.service
      6.728s systemd-udevd.service
      5.017s systemd-journal-flush.service
      4.301s ModemManager.service