Why is boot slow?

Question

I'm using Fedora 23, MATE edition. The computer feels slow to boot. How can I speed it up?

Full details https://i.stack.imgur.com/vpJEG.jpg

$ systemd-analyze 
Startup finished in 16.571s (firmware) + 2.605s (loader) + 824ms (kernel) + 1.997s (initrd) + 48.466s (userspace) = 1min 10.464s

$ systemd-analyze blame
         31.448s mlocate-updatedb.service
         18.211s akmods.service
         16.019s firewalld.service
          9.127s systemd-journald.service
          7.709s accounts-daemon.service
          7.368s dev-sdd3.device
          7.037s systemd-udev-settle.service
          5.219s abrtd.service
          4.854s chronyd.service
          4.629s ModemManager.service
          4.081s livesys.service
          3.958s unbound-anchor.service
          3.920s systemd-logind.service
          3.823s rsyslog.service
          3.781s gssproxy.service
          3.780s akmods-shutdown.service
          3.698s avahi-daemon.service
          3.651s mcelog.service
          3.636s rtkit-daemon.service
          2.735s polkit.service
          2.163s systemd-udevd.service
          2.150s lvm2-monitor.service
          1.569s proc-fs-nfsd.mount

$ 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.

graphical.target @35.395s
└─lightdm.service @34.563s +830ms
  └─systemd-user-sessions.service @34.146s +129ms
    └─remote-fs.target @34.143s
      └─remote-fs-pre.target @34.143s
        └─iscsi-shutdown.service @34.128s
          └─network.target @34.019s
            └─NetworkManager.service @33.009s +1.009s
              └─firewalld.service @16.979s +16.019s
                └─polkit.service @17.870s +2.735s
                  └─basic.target @12.883s
                    └─sockets.target @12.864s
                      └─dbus.socket @12.844s
                        └─sysinit.target @12.704s
                          └─sys-fs-fuse-connections.mount @48.351s +3ms
                            └─system.slice
                              └─-.slice

Answer 1

It is known issue, described in Red Hat Bugzilla:

systemd's lack of random delay functionality of cron is hitting us. I've seen that there is a feature request for that. But till then, it seems that manually putting a random sleep before running updatedb is the workaround. I'd suggest either reverting to using cron for running updatedb for now, or to put a random or specific sleep before running updatedb: e.g. sleep 1h

Workaround:

sed 's/daily/weekly/' /usr/lib/systemd/system/mlocate-updatedb.timer >/etc/systemd/system/mlocate-updatedb.timer

Now I only have to tolerate the slow boot on Monday.

Answer 2

I'd suggest the following workaround instead: delay mlocate-updatedb.service startup for a few minutes (e.g. 10 minutes) so that if it need to run at system boot, it is started after awhile.

The following will do this, and it won't be replaced if mlocate package is updated:

mkdir /etc/systemd/system/mlocate-updatedb.service.d
cat <<EOF > /etc/systemd/system/mlocate-updatedb.service.d/mlocate-updatedb.conf
[Service]
ExecStart=
ExecStart=/bin/sleep 10m
ExecStart=/usr/libexec/mlocate-run-updatedb
EOF

This has the advantage that it should prevent slow boot (Not tested yet, but it should do so, and also will still update locate database everyday.

For Fedora 23 with systemd-222-14.fc23.x86_64 (and above): systemd timers now have a new option: RandomizedDelaySec, which seems to provide the solution for this problem.So, adding a line like this should fix the problem too: RandomizedDelaySec=30m

(Notice that the delay is still random, so sometimes it might be very small and cause slow boots.)

Update: An update is pushed to Fedora testing repository, which seems to have changed service type from oneshot to simple. This will cause systemd to not wait for updatedb termination before continuing. This somewhat solves the problem too. However, I'd still suggest using a sleep or RandomizedDelaySec so that it'll not run during boot at all; because its heavy IO would still slow-down the boot process.