3

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

Full details http://i.imgur.com/vrLGXDp.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
  • Probably best to look at dmesg as it'll give you a more in depth breakdown of the boot process and how long each task takes. Once you find the task that's slowing you boot you'd need to address that more specifically – Centimane Mar 15 '16 at 18:28
  • @Dave dmesg if it helps pastebin.com/raw/P4GZHyfE – Colonel Panic Mar 16 '16 at 7:00
5

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.

  • 2
    In my server farms I just do away with it and we stick with find – Rui F Ribeiro Mar 16 '16 at 6:57
  • Can you suggest a workaround? I use locate so would rather not break it, but updatedb needn't run at boot. – Colonel Panic Mar 16 '16 at 7:01
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.