Please help me analyze slow boot issues Fedora 24

asked 2016-10-27 03:31:03 -0500

thingummybob gravatar image

updated 2016-11-01 09:08:37 -0500

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 @1min 2.354s
└─ @1min 2.354s
  └─crond.service @38.713s
    └─systemd-user-sessions.service @38.481s +134ms
      └─ @38.480s
        └─ @38.480s
          └─iscsi-shutdown.service @38.479s
            └─ @38.394s
              └─wpa_supplicant.service @48.176s +295ms
                └─dbus.service @26.126s
                  └─ @25.995s
                    └─ @25.995s
                      └─cups.socket @25.995s
                        └─ @25.991s
                          └─sys-fs-fuse-connections.mount @54.056s +5ms

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)

Results of systemd-analyze blame are

$ 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
edit retag flag offensive close merge delete



To give you additional breakdown you can use:

systemd-analyze critical-chain

Have you tried checking your disks health with smartmontools or something like that?

systemd-udev-settle.service takes a long time which could indicate that disks or some other hardware is taking long time to initialize.

masteroman gravatar imagemasteroman ( 2016-10-27 10:30:50 -0500 )edit

got this: @55.662s

└─ @55.662s └─libvirtd.service @27.709s +7.283s └─ @27.679s └─ @27.679s └─iscsi-shutdown.service @27.679s └─ @27.598s └─wpa_supplicant.service @32.854s +493ms └─dbus.service @16.171s └─ @16.142s └─ @16.142s └─iscsid.socket @16.142s └─ @16.120s └─sys-fs-fuse-connections.mount @47.874s +7ms

thingummybob gravatar imagethingummybob ( 2016-10-27 12:03:31 -0500 )edit

and no, I haven't tried running any monitoring tools. I will, because the machine is secondhand. When I can show you the output from the "critical-chain" you'll note a number of red entries

thingummybob gravatar imagethingummybob ( 2016-10-27 12:06:05 -0500 )edit

I'm sorry, it is very hard to read it that way, can you please update the original question to include and "style" it a bit? Thanks.

masteroman gravatar imagemasteroman ( 2016-10-29 14:10:33 -0500 )edit

You might want to try using systemd-analyze blame and adding the top few lines to your original post; anything that takes less than five or ten seconds isn't likely to be a factor.

sideburns gravatar imagesideburns ( 2016-11-01 03:24:54 -0500 )edit