martes, 7 de agosto de 2018

Demasiado tiempo en el arranque gráfico de Fedora 28

Tarda demasiado tiempo en arrancar el entorno gráfico GNOME 3. Desde que aparece el menú de opciones de Grub2 hasta que aparece el login screen pasan más de dos minutos. Para comprobar cuánto tiempo consume el proceso de arranque utilizamos el comando:

# systemd-analyze

que devuelve el resultado:

Startup finished in 1.461s (kernel) + 1.592s (initrd) + 2min 10.568s (userspace) = 2min 13.622s
graphical.target reached after 2min 5.083s in userspace

Para saber que proceso es responsable del arranque lento, se puede ejecutar:

# systemd-analyze blame

y muestra el resultado siguiente:

        2min 1.010s lvm2-monitor.service
   2min 493ms systemd-udev-settle.service
       6.875s NetworkManager-wait-online.service
       1.551s dmraid-activation.service
       1.374s plymouth-quit-wait.service
        793ms udisks2.service
        735ms fwupd.service
        654ms dkms.service
        650ms initrd-switch-root.service
        631ms firewalld.service
        508ms dev-md126p1.device
        455ms dracut-pre-pivot.service
        451ms upower.service
        350ms dnf-makecache.service
        340ms systemd-logind.service
        228ms libvirtd.service
        181ms accounts-daemon.service
        149ms dracut-initqueue.service
        134ms dracut-pre-trigger.service
        117ms user@1000.service
        115ms systemd-udev-trigger.service
        114ms sysroot.mount
        108ms polkit.service
        106ms user@42.service
       96ms home.mount
        96ms geoclue.service

Parece que la mayor parte del retraso proviene del proceso lvm2-monitor.service. Este proceso se encarga de monitorizar el uso del LVM.

Si no utilizas LVM se puede deshabilitar sin problemas. Para identificar que el servicio lvm2-monitor está habilitado y en uso puedes usar el comando:

 
# systemctl status lvm2-monitor

Este comando devuelve la siguiente información si el servicio está activado:

● lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling
Loaded: loaded (/usr/lib/systemd/system/lvm2-monitor.service; enabled; vendor preset: enabled)
Active: active (exited)  since Mon 2018-08-06 22:12:47 CEST; 41min ago

Process: 710 ExecStart=/usr/sbin/lvm vgchange --monitor y --ignoreskippedcluster (code=exited, status=0/SUCCESS)
Main PID: 710 (code=exited, status=0/SUCCESS)

En mi caso, el servicio systemd-udev-settle también causa buena parte del retraso en el arranque. Para comprobar su estado ejecuto:
 
# systemctl status systemd-udev-settle.service

y devuelve la siguiente información:

 
● systemd-udev-settle.service - udev Wait for Complete Device Initialization
   Loaded: loaded (/usr/lib/systemd/system/systemd-udev-settle.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Mon 2018-08-06 22:12:46 CEST; 41min ago
  Docs: man:udev(7)
        man:systemd-udevd.service(8)
  Process: 759 ExecStart=/usr/bin/udevadm settle (code=exited, status=1/FAILURE)
  Main PID: 759 (code=exited, status=1/FAILURE)
Aug 06 22:10:46 systemd[1]: Starting udev Wait for Complete Device Initialization...
Aug 06 22:12:46 systemd[1]: systemd-udev-settle.service: Main process exited, code=exited, status=1/FAILURE
Aug 06 22:12:46 systemd[1]: systemd-udev-settle.service: Failed with result 'exit-code'.
Aug 06 22:12:46 systemd[1]: Failed to start udev Wait for Complete Device Initialization.


Desactivo ambos servicios con los comandos:

# systemctl mask systemd-udev-settle.service
Created symlink /etc/systemd/system/systemd-udev-settle.service → /dev/null.
systemctl mask lvm2-activation-net.service

#systemctl mask lvm2-activation-net.service
Unit lvm2-activation-net.service does not exist, proceeding anyway.
Created symlink /etc/systemd/system/lvm2-activation-net.service → /dev/null.

Y ahora reiniciamos el sistema y comprobamos nuevamente los tiempos de arranque.

# systemd-analyze
Startup finished in 1.465s (kernel) + 1.602s (initrd) + 10.034s (userspace) = 13.102s
graphical.target reached after 4.211s in userspace

Y para determinar el proceso que más tarda en responder hacemos:

# systemd-analyze blame

Y ahora devuelve el siguiente resultado:

         21.856s dnf-makecache.service
          6.830s NetworkManager-wait-online.service
          1.160s udisks2.service
           996ms plymouth-quit-wait.service
           741ms fwupd.service
           652ms initrd-switch-root.service
           564ms dkms.service
           560ms firewalld.service
           536ms dev-md126p1.device
           442ms dracut-pre-pivot.service
           390ms home.mount
           376ms systemd-logind.service
           306ms upower.service
           264ms systemd-fsck@dev-disk-by\x2duuid-1576514b\x2d25a2\x2d446e\x2d867f\x2de15bef848cff.service
           171ms accounts-daemon.service
           163ms dracut-initqueue.service
           155ms libvirtd.service
           138ms dracut-pre-trigger.service
           137ms auditd.service
           119ms user@1000.service
           117ms systemd-journal-flush.service

Aquí hay una buena explicación de porqué se puede deshabilitar el servicio udev-settle sin que el sistema lo note.