Por que a inicialização está lenta?

Question

Estou usando o Fedora 23, edição MATE. O computador parece lento para arrancar. Como posso acelerar isso?

Detalhes completos link

$ 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

É um problema conhecido, descrito em 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

Solução alternativa :

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

Em vez disso, sugiro a seguinte solução alternativa: atrasar a inicialização do mlocate-updatedb.service por alguns minutos (por exemplo, 10 minutos) para que, se precisar ser executado na inicialização do sistema, ele seja iniciado depois de algum tempo.

O seguinte fará isso, e não será substituído se o pacote mlocate for atualizado:

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

Isso tem a vantagem de evitar boot lento (não testado ainda, mas deve fazê-lo, e também atualizará o banco de dados de localização todos os dias.

Para o Fedora 23 com systemd-222-14.fc23.x86_64 (e acima): Os timers systemd agora têm uma nova opção: RandomizedDelaySec, que parece fornecer a solução para este problema. Portanto, adicionar uma linha como essa também deve corrigir o problema: RandomizedDelaySec = 30m

(Observe que o atraso ainda é aleatório, então às vezes pode ser muito pequeno e causar um arranque lento.)

Atualização: Uma atualização é enviada ao repositório de testes do Fedora, que parece ter mudado o tipo de serviço de oneshot para simple . Isso fará com que o systemd não espere por updatedb termination antes de continuar. Isso resolve um pouco o problema também. No entanto, sugiro ainda usar um sleep ou RandomizedDelaySec para que ele não seja executado durante a inicialização; porque seu IO pesado ainda desaceleraria o processo de inicialização.